WordPress Structure and Best Practices

WordPress Structureand Best Practices
Mark Parolisi
04-05-2010

Directory Structure
Application Directory
core files (wp-settings.php, wp-config.php, etc)
/wp-admin
Operates as a micro-site to control the app with its own css, js, includes directories
/wp-includes
classes, libraries, scripts for entire app, JS libraries, images
/wp-content
/plugins
Can either be directories for large plugins, or just single files
/themes
Directories of themes
/uploads
Typically organized by year/month of upload
/upgrade

Core
The only files that need to be edited are:
wp-config.php
database connection
define constants to override DB values
wp-settings.php
memory limit (32M default)
debug mode
DO NOT EDIT OTHER FILES!
When we do core updates, these files may be overwritten and your changes would be lost.
I have yet to find a ‘core-hack’ that I cannot reproduce through acceptable WordPressplugin conventions.

Database Structure
wp_comments
wp_commentmeta
wp_links
Not what you think. It’s just a place for WP to store the links defined by the user in the admin panel
wp_options
Kitchen sink table that holds everything from site-url to date/time formats, to timestamps for app core/plugin updates
Gets very abused bloated with plugin settings due to the ease of CRUD operatios on this table
wp_postmeta
Holds all extra (custom) data about a post/page.
wp_posts
Holds all necessary* data about a post/page
wp_terms
Defines categories, tags, link categories and custom taxonomies. Depends on terms_relationships and term_taxonomy.
wp_term_relationships
wp_term_taxonomy
Defines type of taxonomy and contains data about the term(post count, description, etc)
wp_usermeta
wp_users

Credit to @xentek

Anatomy of a Plugin
Files in the /wp-content/plugins directory are scanned for this comment at the start of the document:
/*
Plugin Name: GMaps Widget
Plugin URI: http://wordpress.org/extend/plugins/
Description: Adds a static Google map with text and a link to full Google Map.
Version: 1.0
*/
Plugins work by creating our custom functions to do the work, then calling them to fire through native WP functions.
We can make a new DB table when the plugin is activated in the admin menu
register_activation_hook(__FILE__, ‘myplugin_activation');
function myplugin_activation() {
global $wpdb;
$table_name = 'wp_myplguin_table';
if($wpdb->get_var("SHOW TABLES LIKE '$table_name'") != $table_name) {
$sql = "CREATE TABLE " . $table_name . " (
alt_title VARCHAR(255) NULL,
alt_text TEXT NULL
);";
require(ABSPATH . 'wp-admin/includes/upgrade.php');
dbDelta($sql);
}
}

Actionsadd_action(‘wp_footer’, ‘our_custom_function’)
When WP loads pages (client or admin), it sets action hooks which we can use to load our scripts. Currently 30 for front-end, 11 for admin.
set_current_user
template_redirect
wp_head
loop_start
Use these hooks to prevent conflicts and set dependencies.
By calling the wp_enqueue_script method (for JS) at the wp_enqueue_scripts action, we make sure that we aren’t loading scripts twice and the script is loaded in the right order (very important for JS)
WordPress also allows us to create our own actions hooks.
http://codex.wordpress.org/Plugin_API/Action_Reference

Filtersadd_filter(‘the_content’,‘our_function_name’)
Filters are very similar to actions in that WP sets them for various elements in the application. But rather than just setting hooks for our functions, they allow us to alter (filter) the original data.
the_content
wp_list_pages
Example: Adding to original post content
functionaddContent($content = ''){ $content .= "<p>My plugin text</p>"; return $content;}
add_filter(‘the_content’, ‘addContent’);
Filters can be used not only to append content but also remove, organize and modify it (parental-filters, custom sort for navigation menus, etc)
http://codex.wordpress.org/Plugin_API/Filter_Reference

HackingModding other Plugins
Open Source plugins are free to use and modify in your own environment. But do it with care.
Sometimes you can actually create a new plugin that alters another plugin (very case-by-case)
Decide whether your mod is worth losing support from the native plugin.
Change the plugin name or version number to prevent accidentally update and overwriting of your changes.
Document/Comment all of your changes.
If the mod could be used by others, try to contact the original author and share your patch.

Widgets
Widgets are small bits of functionality that run in special areas of a template called ‘widgetized areas’ (formerly ‘sidebars’)
Widgets can be created in plugin files or the theme’s functions.php file.
Widget structure is pretty basic
Class SampleWidget extends WP_Widget{
function SampleWidget(){
parent::WP_Widget(false, $name = ‘SampleWidget');
}
function widget($args, $instance){
//what the widget will output
}
function update($new_instance, $old_instance){
//updating the values of the widget from the form function
}
function form($instance){
//make the form that appears in the /wp-admin widgets section
}
} //end class
add_action('widgets_init', create_function('', 'return register_widget(" SampleWidget");'));
http://codex.wordpress.org/Widgets_API

Theme Templates
A standard WP theme contains the following views
Header.php
Index.php
Sidebar.php
Archive.php
Single.php
Page.php
Search.php
Footer.php
Comments.php
Functions.php
Some of these files are optional -- e.g. If you omit single.php the index.php will render the content.

Functions.php
This is the first file loaded and acts just like a plugin file.
Anything you can do with a plugin, you can localize to a theme with functions.php
This file typically defines widget areas, loading of custom JS and CSS, and the creation of custom admin menus and logic for the theme.
If you find yourself writing functions into a template view, STOP! Write the logic in the functions.php file and just call it in the template.
If your functions.php file becomes unmanageably large, don’t be afraid to break apart the logic with includes.

Content Templates
Index.php
The initial ‘home page’ content. Default loads the most recent posts.
Page.php
Loads content classified as ‘pages’
?page_id=2
Archive.php
Loads posts from a specific group/taxonomy.
Categories
Tags
Authors
Dates
Single.php
Loads content from a single ‘post’

The Loop
When a content page loads a query based on what kind of template it is (archive, single, page) run.
This primary query is accessed by “The Loop”
if ( have_posts() ) : while ( have_posts() ) : the_post();
//call our different template tags to retrieve data (title, date, post_content)
endwhile; else:
//default if we have no posts in the loop
endif;
You can alter this main query by pre-pending the loop with the query_posts() function.
query_posts(‘orderby=title&order=ASC');
query_posts() accepts many parameters.
http://codex.wordpress.org/Function_Reference/query_posts

Retrieving Data about our Post(s)
Template tags are functions that run within ‘The Loop’ and echo back data.
the_title()
the_content()
the_permalink()
There are also value-returning equivalents to most of these functions.
get_title()
get_permalink()
The $wp_query object (outside the loop or extra data)
All of the data about the loop is stored in this object
Within this object there are many arrays within this object
query_vars, request, comments, post, etc
The $post object
All of the data about the post is stored in this object
$post->comment_count , $post->post_modified, etc
http://codex.wordpress.org/Function_Reference/WP_Query

Running Multiple Queries
Sometime we need to run additional queries on our pages (to get related posts perhaps).
<?php $related_posts = new WP_Query(‘cat=3&showposts=5');
while ($related_posts->have_posts()) : $related_posts->the_post(); ?>
<div class=“related_post">
<h2><?phpthe_title(); ?></h2>
<?phpthe_excerpt(); ?>
<a href="<?phpthe_permalink(); ?>”>Learn More</a>
</div>
<?phpendwhile; wp_reset_query(); ?>
WP_Query accepts the same arguments as query_posts()
http://codex.wordpress.org/Function_Reference/query_posts
Note that you can query posts from post/page name or category name but I generally resist this approach due to the possibility of error.
Use wp_reset_query() to return back to the original query

What NOT to do in Templates
Get, don’t build URL’s
<a href="'.get_bloginfo('url').'/category/'.$ctBX->category_nicename.‘”>
get_category_link($id) or get_permalink($id)
Not checking if plugin function exists
if(function_exists(‘plugin_function’)):
plugin_function();
endif;
Don’t use URL to find location
if(isset($_GET[‘s’]) || $_SERVER[‘REQUEST_URI’] == ‘/index.php’)
if(is_search() || is_home())
Calling JS or CSS from template
ex. Loading jQuery from the template will NOT ensure that another plugin doesn’t load jQuery too. Sometimes different versions lead to conflicts and errors.
Should use the wp_enqueue_script and wp_enqueue_style in functions.php

Things to Remember
Having modular plugins that can work with any theme pays off in the long run. Never write a plugin to be site-specific. Build it to be flexible and scalable, or let that feature exist only in the functions.php file of the parent theme.
Treat your theme files as views. That’s what they are so don’t make them more than that. Always add classes and/or id’s to elements to ensure that front-end styling is easy and effective.
If you find yourself copying/pasting snippets of code into theme files (like RSS feeds, videos, etc) turn that snippet into a widget and maintain only one piece of code.
Keeping core WordPress files and DB schema current is easy when following WP standards. Running the latest versions not only adds new features, but fixes bugs and security holes.
Remember that WordPress was not built for developers; it was built for users. The easy learning curve allows for most people to quickly start adding content to a website, but it is the responsibility of the developer to be the guardian of the output.
Remove all functional-level options from the user and let them access only what they are interested in—the content.
If aplugin requires multiple user-selected conditions to be fulfilled or code to be written into a template for it to even work, then it doesn’t work for WordPress.
Ultimately, WordPress is a platform that encourages its developers to innovate by creating an open system than can easily be manipulated, but we can’t do it at the cost of stability, scalability, and usability of our products.

WordPress Structure and Best Practices

by markparolisi on Apr 17, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 60

Statistics

WordPress Structure and Best Practices — Presentation Transcript

http://markparolisi.com	56
http://www.slideshare.net	4