Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I'm looking for a bit of advice on structuring the classes within a plugin I'm writing for my charity website.

At the moment the plugin is OOP based with a single class. However, its becoming quite ungainly with a lot of functions in a single file. I'm wondering if it would be better to split out separate aspects into different classes, so for example one class for front end, one for back end and one for when validating options.

The difficulty I get into is the best way to call each class and how to handle helper functions. My initial thinking was to have a 'parent' class which would then 'require' the appropriate class depending on a number of checks (such as is_admin). My difficulty is what to do with the helper methods and variables. If I put them in the parent class, how would I access them in the child class?

Any thoughts would be appreciated.

share|improve this question
add comment

1 Answer

You should limit your helper functions. In a rather big plugin I am writing currently (~50 classes) I have just three helper functions, placed in the plugin main file:

 * Delete plugin option on deactivation.
 * @return boolean
function t5_delete_option() {
    return delete_site_option( 'plugin_t5' );

 * Load a class from /inc/ directory.
 * @since  2012.10.26
 * @param  string  $class         Class name
 * @param  boolean $create_object Return an object or nothing
 * @return bool|$class
function t5_load_class( $class, $create_object = FALSE ) {

    $path = plugin_dir_path( __FILE__ ) . "inc/class-$class.php";

    if ( ! file_exists( $path ) )
        return FALSE;

    class_exists( $class ) || require_once $path;

    if ( $create_object )
        return new $class;

    return TRUE;

if ( ! function_exists( 'pre_print' ) ) {

     * Print debug output
     * @since  2012.11.03
     * @param  mixed
     * @return void
    function pre_print( $var, $before = '' ) {

        $export = var_export( $var, TRUE );
        $escape = htmlspecialchars( $export, ENT_QUOTES, 'utf-8', FALSE );
        print "$before<pre>$escape</pre>";

All other classes are placed in a directory /inc/ (not my choice, I have to work within existing rules for that).

The file structure should reflect what the files are for, not where they are used, because that can change any time.

Implement a main controller class that loads the files you need in your current situation. So have to look at one place only to see what is going on.

The main controller collect some data (plugin URL, current user’s IP address, an instance of the custom database class …) and passes these data as a property list object to the called classes. So there is never a need for global access to anything besides the class loader (I don’t use an autoloader) and the tiny debug function.

share|improve this answer
Thanks @toscho, really useful - although it leads me to more questions... - why should I limit the number of helper function? I thought the idea was to minimise code replication? Or am I misunderstanding? - I tried reading the link you included regarding property list objects. I think I get the gist (although a lot went over my head!) - effectively am I passing an object with all of my 'core' variables in it? Why wouldn't I also pass my helper functions in this object? –  Jamie Wright Feb 11 '13 at 18:34
A property list object should stay simple … I’ll see if I can publish my version later. I bet most of your helper functions are not needed in most classes. If they are, they belong to their own class(es). –  toscho Feb 11 '13 at 18:44
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.