Common functionality between my own plugins

1 comment

1. 1.

   First of all functions.php is for themes, that are different things than plugins.

   In WordPress themes should be used for presentation only, plugin for functionality.

   If you want you can use themes for functionality, but you shouldn’t. In fact, themes and plugins are just php files that at a specific moment of a WordPress request are loaded.
   (WordPress load just one file, that is functions.php for themes and the main plugin file for plugins, load all the other files you need is up to you).

   The problem is that in WordPress you can have a non limited number of plugins, but only one theme. So, if you want to change the theme and you have functionality on functions.php you’ll lose it: in few words this is why is better put functionality on plugins and use theme for presentation only.

   2.

   Yes, everything in WordPress core is in global namespace and there is a large use of global variables, but that is core, no one force you to follow same rules, you can use namespaces (if your PHP version is 5.3+) and also don’t use any global variable: when WordPress load your plugin it loads a PHP file, so you can do anything that you version of PHP can do: if you want you can write yourself all the functionality, but that make no sense: you use WordPress because of all the features it has, so try to use core function/classes when what you need is covered by core, but feel free to write the PHP code that does what WordPress does not. And to do that, feel free to use all the PHP techniques you know.

   3.

   I read in your question

   An example of this would be the function which saves to the database

   I don’t know what you are saving to database and why, but if you have to save WordPress entities: post, taxonomy terms, meta, options, users, transient… WordPress already have functions to save and retrieve from database all them, so there is no need to write custom functions for that.
   If you mean some custom tables, yes, if you want you can write some code that abstract and ease the creation and manipulation of custom tables, but in that case:

   • using custom tables in WordPress sometimes is useful, but if your application need too much custom tables, probably WordPress is not the right foundation, there are very nice frameworks overthere (Symphony, Laravel, Sylex and more)
   • before write a custom functionality, look at the huge WordPress plugins available, probably there’s one that already does what you need
   • when write a custom WordPress feature, keep in mind that it is not a standalone application, it will be used inside WordPress with other themes and plugins, so to preserve application sanity you need to follow some rules of coexistence, e.g. use the right hook for specic tasks. Or, just to says something on the specific task, if you need to create a custom table use db_delta
   • Create a plugin just for one function I don’t think it’s a good idea: to use a plugin from another it needs some little efforts, and don’t worth it for just one function. If there are some generic functions that you use in your plugins you can mind to create a plugin that contains them all…

   4.

   Now talk about extract common feature from a plugin to another. Yes it is doable and, imho, it’s perfecly fair.
   There are different way to do it:

   4.1: just create different plugins and install them all

   Just like already said, plugin are just php files that at a specific time during WordPress bootstrap are loaded using require_once, so really, when 2 plugins are installed, there is no difference of 2 files being in same plugin and loaded by yourself, or two files are loaded by WordPress. Sure you can’t say which file is loaded first and which later, but thanks to to WordPress hooks, you can know when all plugin are loaded, and start to do thing since that moment. Of course before to use a feature placed in another plugin just be sure that plugin/feature is available. A proof of concept code:

   // plugin-one.php
   
   namespace PluginOne
   
   class Foo {
     function do_something () {
       return 'Foo!';
     }
   }
   
   // plugin-two.php
   
   namespace PluginTwo
   
   class Bar {
     function do_something ( PluginOneFoo $foo ) {
        echo $foo->do_something();
     }
   }
   
   add_action('plugins_loaded', function() { 
     // when WordPress fires 'plugins_loaded' all plugin files are required
     // so we can check if the class PluginOneFoo exists and use it
     if ( class_exists( 'PluginOneFoo' ) ) {
       $bar = new Bar;
       $bar->do_something( new PluginOneFoo );
     }
   });
   

   4.2: Composer

   I don’t know if you ever used/heard about Composer. It is a dependency managment tool.

   When you need to write a plugin that require another plugin, if both supports Composer, than all the thing is done just adding a line in the composer.json file.

   How to use Composer for plugins is not complex, but too complex for an answer here.

   In latest months interest in Composer grew up in the WordPress community (in PHP community it grew up some time ago), and now you can find some useful resources.
   Start having a look composer.rarst.net, it’s a resource shared by Rarst, one of this site mods.

Comments are closed.