I have been pleasantly surprised by the uptake and popularity of the plugin so far, so I have decided to do some quick customer research into what features people would like to have added to it and to see whether or not there is a market for releasing a premium version of the plugin with some of these new features. I put together a quick survey asking some open questions about this, so if you have enjoyed the plugin and you have a spare minute please go ahead and fill it out – the more responses I receive the better!

Download the plugin Fill out the survey

So here is a .gitignore file that will exclude all WordPress core files from your repo so that only your themes and plugins will be uploaded – this works recursively, so that it will ignore all the copies of WordPress you have in the sub-folders of the repo.

.htaccess
wp-admin/
wp-includes/
wp-config.php
*/wp-content/uploads/
*/wp-content/blogs.dir/
*/wp-content/upgrade/
*/wp-content/backup-db/
*/wp-content/advanced-cache.php
*/wp-content/wp-cache-config.php
*/wp-content/index.php
*/wp-content/themes/index.php
*/wp-content/plugins/index.php
*/index.php
*.log
wp-content/cache/
wp-content/backups/
sitemap.xml
sitemap.xml.gz
wp-activate.php
wp-app.php
wp-blog-header.php
wp-comments-post.php
wp-config-sample.php
wp-config.php
wp-cron.php
wp-links-opml.php
wp-load.php
wp-login.php
wp-mail.php
wp-pass.php
wp-register.php
wp-settings.php
wp-signup.php
wp-trackback.php
xmlrpc.php
license.txt
readme.html

The template includes built-in support for:

• Custom post type with custom fields and custom taxonomies
• Plugin settings page
• WPML i18n

The code is entirely object-oriented and is written according to the WordPress coding standards – all it requires is editing in order to remove the demonstration data and add new, more functional, data. The plugin is obviously not meant to be used in its current form, but if you activate it without changing anything it will create a new post type (identified as ‘*Posts’ in your dashboard menu) and a new settings page (found at Settings > Plugin Settings). These pages are entirely functional, so you can see a working demonstration of how a plugin built using this template will work. You can get the code from GitHub below – feel free to change it to make it more practical for your own use.

function scrollToElement( target ) {
    var topoffset = 30;
    var speed = 800;
    var destination = jQuery( target ).offset().top - topoffset;
    jQuery( 'html:not(:animated),body:not(:animated)' ).animate( { scrollTop: destination}, speed, function() {
        window.location.hash = target;
    });
    return false;
}

As you can see you can also specify the speed and a top offset for the scroll (I find this top offset very useful as default behaviour puts the target element flush with the top of the browser, which can make things feel a bit cramped). An added bonus is that it appends the target string to the current URL, so if you are using a standard anchor reference (such as #element) then users will be able to grab the URL and it will point to the correct location on the page. If you are using other selectors to target an element then I would recommend removing the function inside the animate call.

You can see this function in action as the top navigation on the home page of my site.

$( '.selectall' ).click( function () {
    $( this ).closest( 'form' ).find( ':checkbox' ).attr( 'checked' , this.checked );
});

You can replace the form identifier with whatever container you choose (fieldset can be useful if your form is split up like that). This code will cause all the checkboxes in the form to be toggled when you toggle any checkbox that has the selectall class.

Simple.

UPDATE: Modified code to be slightly more efficient as suggested by Jamy Golden.

function register_widget_area() {
    if( function_exists( 'register_sidebar' ) ) {
        register_sidebar( array(
            'name' => 'Widget Area Name',
            'id' => 'new_widget_area',
            'before_widget' => '<div class="widget">',
            'after_widget' => '</div>',
            'before_title' => '<h1 class="title">',
            'after_title' => '</h1>',
        ) );
    }
}
add_action( 'widgets_init', 'register_widget_area' );

After pasting that code the new area will become available in the Appearance > Widgets section of your dashboard. The options available in the snippet are pretty self-explanatory, so I won’t go through each of them – just rename the items to whatever your use case requires them to be.

Once you have added widgets to the new widget area, you can display them on your site easily by adding this line of code in the location that you want the widgets to appear:

dynamic_sidebar( 'new_widget_area' );

function plugin_add_settings_link( $links ) {
    $settings_link = '<a href="options-general.php?page=plugin_name">Settings</a>';
  	array_push( $links, $settings_link );
  	return $links;
}
$plugin = plugin_basename( __FILE__ );
add_filter( "plugin_action_links_$plugin", 'plugin_add_settings_link' );

Simply replace the href attribute with the link to the plugin settings page and rename the function to something slightly more unique (preferably all wrapped in an if(!function_exists()) conditional).

Turn debug mode on

This pretty much goes without saying – it’s the first thing you need to do as soon as something goes wrong and your WordPress site no longer loads any pages (in fact, you should always have it switched on when developing so you can be aware of PHP notices that could affect performance). When you switch debug mode on, all PHP errors, warnings and notices will be displayed in your browser. To switch it on simply open up wp-config.php in your site’s root folder, head down to line 81 and change the WP_DEBUG value to true:

define( 'WP_DEBUG', true );

This should be set back to false in a live environment.

Increase WordPress memory limit

Often a plugin will require more memory than your default server settings allow for – with debug mode on this will result in an error that reads along the lines of “Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 7680 bytes)”. To fix this you can assign WordPress more memory by adding this line to wp-config.php just below the WP_DEBUG line:

define( 'WP_MEMORY_LIMIT', '64M' );

Just set the memory limit value to whatever you need it to be – the 64 used in this case should be more than sufficient for most of your needs.

Prevent core script minification

Core WordPress scripts and styles are minified and concatenated by default in order to get the lowest page load speed possible. This makes debugging them incredibly difficult in the case of a Javascript conflict or something similar. You can switch off this minification by enabling script debugging – just add this line to your wp-config.php file just below the WP_DEBUG line:

define( 'SCRIPT_DEBUG', true );

While you can use this in a live environment, it is not recommended as it increases page load times quite a bit.

Store database query data

Every WordPress site makes loads of MySQL queries on each page load – most often these queries are dynamically generated and cannot easily be printed out. To remedy this you can save your queries along with backtrace data and execution time – simply add this line to your wp-config.php file just below the WP_DEBUG line:

define( 'SAVEQUERIES', true );

This will store your queries (along with their relevant data) inside the $wpdb->queries object for easy access. This setting is not to be used inside a live environment as it can increase page load time and will potentially give people access to your database structure and data.

Check if your code is actually running

If you’ve added an action and for some reason it’s just not doing what it’s supposed to be doing, it’s worth doing a quick check to see if the function is actually being called – simply add a die command to the top of the function like this:

die();

You’ll then find out very quickly if it’s working or not. This will help you work out if you’re using the wrong hook entirely or maybe just spelling the hook you want incorrectly.

Deactivate all plugins

If you can’t work out where the problem is coming in exactly, the best bet is to deactivate all your site’s plugins. Unless the problem is in the theme this will usually fix any issue temporarily. The process from there is to switch the plugins back on one-by-one until you find the culprit. There is a handy section on the plugins page that allows you to see a list of plugins that were recently active – this can be useful when dealing with a site that has many active and non-active plugins. To access this list just click the ‘Recently Active’ link at the top of your plugins page.

Switch to the default theme

If all else fails, switching back to the default WordPress theme will show you if there are any errors in your current theme. Matt Cohen wrote a handy plugin that adds a menu to your WordPress toolbar allowing you to quickly switch between themes without having to go to the Appearance > Themes page every time – you can get it here.

Use basic PHP functions

PHP has plenty of functions that are designed to help you debug your code more effectively – print_r(), var_dump() and die() being good examples. Get to know your PHP debugging functions as these will help you immeasurably in your development. As a side note, I find this little function is a handy replacement for print_r() as it shows the array in a more readable format:

function printr( $arr ) {
    echo "<pre>";
    print_r( $arr );
    echo "<pre>";
}

Google

Ultimately, if you can’t find a solution to your problem them simply Google it. WordPress has such an active community that you are almost guaranteed to find a solution to your problem from a quick search of the web.

If you have any other quick tips for debugging WordPress please post them in the comments.

It turns out that WordPress has a number of query variable names that are reserved for specific functions and cannot be used by any custom form on the site. In my case, I had a field called ‘name’ that was the culprit and simply changing it to ‘clientname’ fixed my problem entirely. The problem is that instead of giving a helpful error, WordPress just returns a 404 with no explanation about what went wrong or why it happened – even with debug mode on there is nothing helpful. This, as you can imagine, is particularly frustrating.

I haven’t found any official documentation listing the reserved variables, but there is this user-created page in the WordPress Codex that has a list of them (based on the variables used by WP_Query). I’m not sure how complete it is, but it seems fairly comprehensive.

Seeing as though I struggled with this for a few days, I thought I would share the solution here to help anyone else who might be having a similar issue.

This simple query looked something like this:

SELECT email_address, COUNT(email_address) AS occurrences
FROM users
GROUP BY email_address
HAVING occurrences > 1

I find this to be a particularly helpful SQL snippet as this kind of clean up process is fairly common. It uses MySQL’s HAVING clause because WHERE cannot handle aggregate functions – COUNT() in this case.