2

I need to know how to write function for registering activation_hook and deactivation_hook following OOP fashion with best practices.

I know there are some tasks we can do inside plugin activation/deactivation which is really essential in some cases like to create professional plugins.

Thanks.

  • 1
    Best practice is not to use "OOP" in wordpress plugins. Use namespaces instead. OOP means that there might be more than one object, each with its own activation handling.... scenario that do not make much sense. – Mark Kaplun Jun 3 '17 at 16:37
  • 1
    Good Point about namespace and OOP. Thanks! Just a quick thought, what if I use static keyword before the methods so that the static methods would be callable without an instance of the object. While I still found many places of codex.wordpress and developer.wordpress where OOP is being used in plugins too. – magento_psycho Jun 3 '17 at 17:30
  • :) you can write code however you want and it will even work and will be stable and secure etc, it will just not be OOP ;). Wordpress is mostly functional, especially the hook system, and it just do not translate in any trivial way into OOP style of development. The biggest problem with using "OOP" is that many times, when the hook is not a a static function, it is hard or just impossible to remove the hook when needed, and too many themes and plugins do that. – Mark Kaplun Jun 3 '17 at 17:38
  • 1
    @MarkKaplun Wow, Excellent Point you stated. but I wonder why does wordpress recommend sample boiler plate of plugin which is OOP oriented!! :) – perfectionist1 Jun 3 '17 at 17:51
  • 1
    because of history, (and again it uses classes which is not the same as being OOP ;) ). PHP got namespaces only with version 5.3, and officially wordpress core still supports PHP 5.2. Now before 5.3 the only way to avoid collisions between the same function name in different plugins and themes was by either prefixing it with some string, usually based on the plugin name, or author, and the other way was to group the functions in a class. Obviously grouping them in a class seems to be more structured and requires less mental thinking about prefixes, and less typing. – Mark Kaplun Jun 3 '17 at 18:07
2

It can be demonstrated like this way:

Step-1: Create a folder named includes (or any name you like) inside the plugin root folder. Create two new files named class-responsive-slider-activator.php and class-responsive-slider-deactivator.php
Now, in class-responsive-slider-activator.php create a class -

class Responsive_Slider_Activator {

    public static function activate(){
         //do your codes to execute upon activation

    }
}

and in class-responsive-slider-deactivator.php create another class-

class Responsive_Slider_Deactivator {

    public static function deactivate(){
         //do your codes to execute upon deactivation

    }
}

Step-2: In main plugin file create functions and register the two hooks -

// this code runs during plugin activation
function activate_responsive_slider(){

   require_once plugin_dir_path( __FILE__ ).'includes/class-responsive-slider-activator.php';

   Responsive_Slider_Activator::activate();
}

register_activation_hook( __FILE__, 'activate_responsive_slider');


// this code runs during plugin deactivation
function deactivate_responsive_slider(){

   require_once plugin_dir_path( __FILE__ ).'includes/class-responsive-slider-deactivator.php';

   Responsive_Slider_Deactivator::activate();
}

register_deactivation_hook('__FILE__', 'deactivate_responsive_slider');

That's it.

N.B. - As per your interest, I would like to denote that there are some essential tasks which can be accomplished through activation and deactivation hooks like:

  1. Validating other dependent plugin on activation.
  2. Creating custom database tables on activation to store data and removing tables on deactivation.
  3. Creating custom options for plugins in activation and reset in deactivation.
  4. Any other necessary task need to execute in activation. etc
  • This is what like I implemented. And usefull points at bottom-line. Thanks much. – magento_psycho Jun 3 '17 at 17:32
1

Well there I got the below ways better-

// in the main plugin file
define( 'PLUGIN_BASE_FILE', __FILE__ );

class MainClass {
    public static function init() {
        register_activation_hook( PLUGIN_BASE_FILE, array( 'MainClass', 'install' ) );
    }

    public static function install() {
        // Do what ever you like here.
    }
}

MainClass::init();

Another way would be defining a class and on instantiating the class through __construct method create a property with the value of __FILE__. The call the register_activation_hook in the init function. Like below-

class MainClass {

    public $file;

    public function __construct( $file ) {
        $this->file = $file;
    }

    public function init() {
        register_activation_hook( $this->file, array( $this, 'install' ) );
    }

    public function install() {
        // Do what ever you like here.
    }
}

// This part must have to be done in main plugin file.
$class = new MainClass(__FILE__);
$class->init();

But, this instantiation must be done in the plugin main file.

Hope that helps.

  • Thanks much. Though I am trying to define the activation/deactivation class in different file and then call it to the plugin main file. – magento_psycho Jun 3 '17 at 14:11
  • You can do that. For the first method define the constant in main plugin file and call and define the class somewhere other. And for second method you can define the class anywhere but you need instantiate it in the main plugin file. – CodeMascot Jun 3 '17 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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