vendredi 30 janvier 2015

Potential problems with building a plugin having sub modules?


I'm in the process of organizing a lot of different functionality that I had historically written as parts of themes so that I can break the various utilities into plugins.


At this point, I have my list of distinct sets of functionality with each broken down into categories.


Initially, I was planning on writing individual plugins for each distinct set of functionality. However, looking them over, I'm considering building things out by doing the following:




  • Creating a swiss army knife type plugin that houses sub-plugins for most of the generic smaller plugins and providing an admin interface to let the user choose which functionality they want to make use of on their site.




  • Creating a plugin skeleton designed to be used for adding custom taxonomies and post types to a theme which has all of the core code for registering them, adding meta boxes, etc. pre-written and ready to have specifics added.




That being said, I'm looking for input from others on any pitfalls or other things to be aware of about doing this kind of thing.


The swiss army knife style plugin:



  • This will handle initialization, activation, deactivation, and uninstall processes.

  • It will use a namespace so that the code within each plugin can use cleaner names and access other plugins if applicable without having to use the namespace in calls. (obviously the plugin will require at least PHP 5.3, maybe 5.4 if I use traits)


The primary reasons that I'm considering doing this rather than building out separate plugins:



  1. Shared utility code - I tend to use exceptions for all error handling and try to account for various available wordpress debugging tools (WP_DEBUG, etc.) ... and building things out this way should enable me to make improvements in one place rather than having to go through a ton of plugins to change such utility code when I make an optimization.

  2. Ease of Upgrades - I build a reasonable number of sites out each year and it would be nice to be able to offer new functionality by simply updating a single plugin.

  3. Reduced Overhead - If I build out a site that needs 23 different distinct bits of functionality, this would prevent 23 plugins from showing in the dashboard, 23 plugin initializations, etc.


The Custom Taxonomy and Post Type Skeleton Plugin



  • This would be separate as many sites require very distinct capabilities that no other site is likely to want (at least not exactly).

  • The point of the skeleton plugin would be to have all commonly used related code pre-written so that I could create such custom work in a much faster manner.


Thoughts and advice?


I haven't previously went this route with a plugin ( and the swiss army knife style plugin will hopefully be my first plugin to go up on the public repository ) before.


I am looking for any information from others on any concerns with building out something like this so that I can consider them (and hopefully address them) before figuring them out the hard way.


I cannot think of any real drawbacks at this point but realize that I lack experience as a public plugin author and so my question.





Aucun commentaire:

Enregistrer un commentaire