DevinVinson / WordPress-Plugin-Boilerplate

[WordPress] A foundation for WordPress Plugin Development that aims to provide a clear and consistent guide for building your plugins.
http://wppb.io
7.67k stars 2.25k forks source link

How to handle plugin activation/deactivation on a network with version 3.x.x of the boilerplate? #288

Open schiavassa opened 9 years ago

schiavassa commented 9 years ago

Thanks for the great resource!

I should mention that I'm new to WP plugin development, and I'm studying this boilerplate in order to get familiar with its philosophy and some OOP concepts.

I want to build a plugin to provide extended functionality to themes—custom post types and taxonomies, shortcodes, and some widgets. I still have a long way to go, but right now I'm a bit confused regarding activation/deactivation on a multisite network.

For CPTs for example, how should the flushing of rewrite rules be handled when the plugin is activated across a network?

I've read a few related issues but they date way back and I'm not sure if the advice still applies to version 3.x.x of the boilerplate https://github.com/DevinVinson/WordPress-Plugin-Boilerplate/pull/58

I'm also studying how the Portfolio Post Type plugin handles activation/deactivation, but I'm not sure if that applies to a WP 4.x.x network installation?

Any pointers will be appreciated,

Cheers!

DevinVinson commented 9 years ago

Check out https://codex.wordpress.org/Function_Reference/register_activation_hook if you have not already.

The way I've been doing it within the setup of the boilerplate is to have an option triggered in the activation/deactivation and the rest of the code back in the admin class.

The static activation method in a class setup is on my todo list to look at so don't feel like its the only option or that everything regarding activation must go inside of it.

schiavassa commented 9 years ago

Hi Devin,

Thanks for the tips :)

I managed to refactor some of the code on this commit https://github.com/thuijssoon/WordPress-Plugin-Boilerplate/commit/2a2050d7fb4cfc050e02093afec25a35b0f76df9 to fit into the current state of the boilerplate. I think Portfolio Post Type handles it in a similar way. I have a separate class to handle post types and its initialization method is called both on activation and attached to the 'init' hook, so the code is sort of modular. It works, but being a rookie I always wonder if there's a better or more correct way to do things.

The method you mention--triggering an activation option--sounds interesting. Was reading this article where they discuss cleaning up after your plugin and they mention something similar. The only drawback would be checking for the activation option on each page load, but performance-wise that shouldn't be a problem.