My Story

Category Archives: WordPress

I saw VisualPHPUnit and was immediately interested. This provided a very nice visual wrapper to PHPUnit without full blown continuous integration, and kept a history of your test passes / fails.

VisualPHPUnit is a wrapper for PHPUnit. It expects that your tests are compatible with PHPUnit’s command line test runner already.

Could this work with WordPress’ Unit Tests? After some investigation, I’m sad to report that, no, it can’t. VisualPHPUnit makes several assumptions that are incompatible with WordPress’ test suite. These are not bad assumptions, just incompatible ones.

Include the bootstrap before the PHPUnit library. This causes problems because the bootstrap cannot reference PHPUnit (e.g. extending PHPUnit_Framework_TestCase).

Always include the PHPUnit library. This causes problems because the bootstrap may have already included PHPUnit (to solve the above problem). Code like this would solve the issue:if( !function_exists( 'phpunit_autoload' ) ) {
require_once( 'PHPUnit/Autoload.php' );
}

Running a WordPress site on your local machine is a great way to do development. I’ve taken advantage of this to do development while on flights (and yes, I realize that in about 5 years it’s going to seem positively quaint that there used to be flights without Internet access).

Today, I’d like to tackle two common issues when running a WordPress site locally:

Handling differing database connection details

Handling plugins that can’t or shouldn’t run on a localhost

My assumptions:

You have your site in a Git repository

You have a working LAMP/MAMP/WAMP/whatever setup.

You already know how to do a mysqldump and import that dump to your local machine

Database connection details

Your database user and password are (or should) be different on your localhost than they are on your production environment. One way to handle this is to have wp-config.php not be in version control and have…

This filter applied to the list of columns to print on the manage posts screen for a custom post type. Filter function argument/return value is an associative array where the element key is the name of the column, and the value is the header text for that column.

Add Columns

Suppose you have a ‘books’ custom post type and you want to add the publisher and book author in the edit page but remove the post author.

function set_edit_book_columns($columns) {

unset($columns['author']);

return array_merge($columns,

array('publisher' => __('Publisher'),

'book_author' =>__( 'Book Author')));

}

add_filter('manage_edit-books_columns' , 'set_edit_book_columns');

Replace Columns

Here’s another example that completely replaces the columns, rather than adding and removing specific ones.

function set_edit_book_columns($columns) {

return array(

'cb' => '',

'title' => __('Title'),

'date' => __('Date'),

'publisher' => __('Publisher'),

'book_author' =>__( 'Book Author')

);

}

add_filter('manage_edit-books_columns' , 'set_edit_book_columns');

Note the header for the ‘cb’ column is a checkbox, so that the checked posts can be toggled between all and none.

Files should be named descriptively using lowercase letters. Hyphens should separate words.

my-plugin-name.php

Class file names should be based on the class name with class- prepended and the underscores in the class name replaced with hyphens, for example WP_Error becomes:

class-wp-error.php

This file-naming standard is for all current and new files with classes. There is one exception for three files that contain code that got ported into BackPress: class.wp-dependencies.php, class.wp-scripts.php, class.wp-styles.php. Those files are prepended with class., a dot after the word class instead of a hyphen.

Files containing template tags in wp-includes should have -template appended to the end of the name so that they are obvious.

I have just edited this WordPress codex page for WordPress version 3.4.

The Network Admin Link has moved with each major release of WordPress, as this is still a work in progress. Depending on which version of WordPress you are using, the link can be found in the following locations:

If you are a plugin/theme developer and you are planning to use custom fields to store parameters related to your plugin or template, it is interesting to note that WordPress won’t show keys starting with an “_” (underscore) in the custom fields list at the page/post editing page or when using the template the_meta() function. Depending on how you plan to use the meta data, you may want to hide the values from the the admin UI by prefixing their names with an underscore.

The following example:

add_post_meta(68, '_color', 'red', true);

will add a unique custom field with the key name “_color” and the value “red” but this custom field will not display in the page/post editing page.

In addition, when $meta_value is an array, it will not be display on the page/post editing page.