public
Last active

Plugin Class Demo

  • Download Gist
plugin-class-demo.php
PHP
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122
<?php # -*- coding: utf-8 -*-
/**
* Plugin Name: Plugin Class Demo
* Description: How I am using the base class in plugins.
* Plugin URI:
* Version: 2012.09.29
* Author: Thomas Scholz
* Author URI: http://toscho.de
* License: GPL
* Text Domain: plugin_unique_name
* Domain Path: /languages
*/
 
/*
* I prefer the empty-constructor-approach showed here.
*
* Advantages:
* - Unit tests can create new instances without activating any hooks
* automatically. No Singleton.
*
* - No global variable needed.
*
* - Whoever wants to work with the plugin instance can just call
* T5_Plugin_Class_Demo::get_instance().
*
* - Easy to deactivate.
*
* - Still real OOP: no working methods are static.
*
* Disadvantage:
* - Maybe harder to read?
*
*/
 
add_action(
'plugins_loaded',
array ( T5_Plugin_Class_Demo::get_instance(), 'plugin_setup' )
);
 
class T5_Plugin_Class_Demo
{
/**
* Plugin instance.
*
* @see get_instance()
* @type object
*/
protected static $instance = NULL;
 
/**
* URL to this plugin's directory.
*
* @type string
*/
public $plugin_url = '';
 
/**
* Path to this plugin's directory.
*
* @type string
*/
public $plugin_path = '';
 
/**
* Access this plugin’s working instance
*
* @wp-hook plugins_loaded
* @since 2012.09.13
* @return object of this class
*/
public static function get_instance()
{
NULL === self::$instance and self::$instance = new self;
 
return self::$instance;
}
 
/**
* Used for regular plugin work.
*
* @wp-hook plugins_loaded
* @since 2012.09.10
* @return void
*/
public function plugin_setup()
{
 
$this->plugin_url = plugins_url( '/', __FILE__ );
$this->plugin_path = plugin_dir_path( __FILE__ );
$this->load_language( 'plugin_unique_name' );
 
// more stuff: register actions and filters
}
 
/**
* Constructor. Intentionally left empty and public.
*
* @see plugin_setup()
* @since 2012.09.12
*/
public function __construct() {}
 
/**
* Loads translation file.
*
* Accessible to other classes to load different language files (admin and
* front-end for example).
*
* @wp-hook init
* @param string $domain
* @since 2012.09.11
* @return void
*/
public function load_language( $domain )
{
load_plugin_textdomain(
$domain,
FALSE,
$this->plugin_path . '/languages'
);
}
}

The following should be changed because $this->plugin_path already ends in a slash thanks to plugin_dir_path always returning the path with the trailing slash

Change from:

    load_plugin_textdomain(
        $domain,
        FALSE,
        $this->plugin_path . '/languages'
    );

To:

    load_plugin_textdomain(
        $domain,
        FALSE,
        $this->plugin_path . 'languages'
    );

Quick question about this, sorry if it seems obvious or is really basic – but is there a reason to even have an empty __construct() for the Constructor, if plugin_setup() here is setting things up and doing all the plugin actions?

I'm just starting to learn about OOP and see information about __construct() methods in places like this StackOverlow answer that say it should be used for setting class properties – or is this true only if the properties as passed as arguments to the class, like in that answer I linked to above?

To clarify:
1. Is __construct() needed for defining a class's properties?
2. If it's wholly not needed, then why leave an empty version of it in the class at all, instead of just leaving property definitions, hooks, actions, etc. in a custom init method like this demo's plugin_setup() method?

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.