You are here:

MeMSO PHP Core v4: Plugins

2/25/2014 10:34PM

Plugins in Core v4

 

Back in March of 2013, I had started work on a completely new way of organizing files for the MeMSO PHP Platform, and started making plans for Core v4. The system was on v3.2 at the time, which was already taking strides to being more plug-n-play, but this new idea changed everything.

 

The old way involved having all of the platform files intermingled into sorted directories by the type of file. This is all well and good for a smaller project, but I was working on projects with 20+MB of code, so it started getting more and more complicated making updates since each feature was interspersed with every other feature. To make matters worse, custom features for each website ended up getting mingled in as well. And lastly, installing new features meant manually going through the core system and picking and choosing the files to use for each.

 

There are many code systems that work this way, including many games, such as anything on the Unreal engine, most Valve games, the Sims series, etc. Anybody that has worked with plugins in these infrastructures has seen this problem as well... it's just hard to keep track of what belongs to what when everything is blended in together.

 

The old structure:

/admin/*
/admin/installscripts/*
/backend/*
/inc/*
/inc/content/*
/inc/settings/*
/includes/css/*
/includes/js/*
/intcom/*

 

The new structure:

/Admin/*
/Install/*
/Timed/*
/Class/*
/Content/*
/Config/*
/CSS/*
/JS/*
[no more intcom]

And then /Plugin/*, which works the same as everything above for each plugin

For the new system, Core v4, I have separated everything out to their own individual directories. Dependencies will just tie into the relative sub directories of the other plugins. Otherwise, user side scripts, timed scripts, admin scripts, install scripts, classes, css, javascript, images... everything is now included with each plugin as its own package, stored under the Plugin directory.

 

Not only that, but to facilitate overriding default behavior and functionality in any feature, everything is being rewritten to work as classes, instead of local-data functions. Taking advantage of the features of PHP 5.3 and above also has made it possible to clean up and stream line a lot of this process. Adding a registry system for classes makes it possible to override any class with ease, or to include them dynamically. Including setting files, content files, JS and CSS through high-level functions allows them to be intercepted and changed, so that a display plugin can intercept, say, CSS/Site.css and instead use Plugin/MyCoolDisplay/CSS/Site.css, and no script would notice the difference. I will go into the details in another article about all of the benefits of the new system and format.

 

This update also changed the naming convention for files. Why the heck not, since we're redoing how everything else works? The file names and paths are all now camel capsed, just like the source. A new directory format has been made to split out files by their task, but also by the plugin. And the names of files should be non-plural unless the meaning is completely different otherwise.

 

This required a lot of changes to how features work together. Includes were no longer all available under /inc/*; the core features were moved under /Class/ and the plugins were interspersed through out any number of places in the system under /Plugin/*/Class/. An existing include such as /inc/emailalerts.php is now located at /Plugin/EmailAlert/Class/EmailAlert.php, /inc/admin/admin.php is now under /Class/Admin.php, and so on.

 

The installation system, the timed scripts, the includes, everything had to be updated to support a more complex structure. Administrations are now under /Admin/ (for the Core features) or /Plugin/*/Admin/ for plugins. Install scripts are under /Install/ or /Plugin/*/Install/. Classes are under /Class/ or /Plugin/*/Class/. Can you see where this is going? Each plugin is just like the core, with its own code stored only in its own directory, so now everything is consolidated by plugin.

 

Easing the Transition: Core v3.3

 

This restructuring is so different, and everything is in new directories, so to ease in the new format, I have created a Core v3.3 for the time being. This is so that I can use the new infrastructure, but keep scripts in the old locations that abstract away the new format behind the old format, allowing the new code and the old code to work simultaneously. As mentioned before, /inc/emailalerts.php was moved, and its implementation rewritten in a class format, but old scripts can still use the old way through /inc/emailalerts.php still just as if it had never changed. The same is true of almost all of the old format files. A couple exceptions exist because only one or two features used them ever, and they have already been rewritten to use the new format.

 

It is Core v3.3 that this site is built on. It is partly why I kept pushing back the release date for this blog... I was busy making the new infrastructure, testing it, and so on. New features going forward can use the new features of the system, while the old features do not need to be changed for the most part, and in a couple instances, only marginally.

 

The down side is that to any casual observer, the system is really a big mess at the moment. Old format code doesn't look anything like new format code and vice versa. There are sometimes two includes (old and new) to do the same thing, and how they are implemented (functions vs classes) are very different. For this very reason, I am not going to be releasing the source of Core v3.3 unless some people are very insistent. It is an interim or temporary solution to the transition, and it will go away in the near future.

 

Plans for Core v3.4

 

Core v3.4 will be the final version of v3.x for the platform. It will have every single open-source feature rewritten in the new format, but it will still maintain downward compatibility with v3.x. This is largely for projects that would be enormously time consuming to rewrite in the new v4 format, such as the A Far Site Better websites I have done. The hope is to be able to push my employer into upgrading their code base to the new format, but I also doubt this will ever happen. This will hold their whole system back from ever receiving all of the benefits, and I very well may end up supporting v3.4 for a very long time because of it.

 

Nevertheless, v3.4 should be completely forwards compatible with v4.0. Once it has been prepared and tested, it most definitely will become available.

 

Ease-of-use with plugins

 

Was it worth it? HECK YEAH it was worth it. Already, the ease of working with the new plugin structure has already confirmed to me that this was a worthwhile, even if time consuming, upgrade to the system. Now adding a new feature is as simple as just dropping in the new code, going to the Install admin, and running its install script. And then it's ready for use.

 

The end goal is to have it so that plugins can easily be included, "plugged in", and they will function from that point forward. Eventually, a plugin manager will become available, allowing a site to dynamically download, install and configure a plugin without ever having to manually ascertain the source and integrate it into the website.

 

The next challenge in this process is to make it easy to configure the /Config/* files as well, so you install a feature, you change its settings right there, the installation reruns to configure itself based on your settings, and you're set.

 

I will have to leave discussing other features of this update to another time, but the directory structure change alone has been in use for a couple months now, and I'm excited about it. I'll be even more excited when I can finally release this stuff and to see what other people can make with it.