This questions might be easily answered by looking at official WordPress sources:
From the WordPress Developers site we can read that:
Plugins allow you to greatly extend the functionality of WordPress without touching WordPress core itself.
Also, from the WordPress support site we find this concise description:
Plugins are ways to extend and add to the functionality that already exists in WordPress.
Based on these descriptions we could assert that plugins only allow us to add or modify the behaviour of features that already exist inside WordPress – but that they might not be useful if we wanted to, for example, remove an existing feature – it is also clear that to understand what a plugin is, we also need to understand what is WordPress Core and why we should not change it directly.
WP Trilogy
WordPress has a trilogy of base modules – Core, Plugins and Themes – and while there are some fuzzy lines, most things WordPress fit into one of these three compartments, while some might bridge across two – Core is the holy part, which developers should not edit directly, instead we access Core functionality via filter and action hooks run from themes or plugins.
For example, a theme can include code the affects parts of WordPress unrelated to front-end display and there is also no clear line at what point functional theme logic should be broken out into a separate plugin – like in cases where a theme bundles a framework – WordPress also still does not support plugin dependencies – which make it much harder to follow DRY practises.
Due to the technically liberal way WordPress is written, plugin developers tend to follow the same agnostic path – while there are coding standards, these are only really enforced for Core elements and in some cases for submissions to the plugin and theme repos.
WordPress mixes mostly procedural code with dashes of OOP – and while there may be common agreement about some of the wrong things to do – there really is no single correct way to write a plugin.
There are often almost limitless ways to solve technical problems, and most solutions might work just as well as any other – standardization in this case is really more about how easily others might work with your code.
Rapid Rise
Let’s go back to the beginning. WordPress – like many populate frameworks – was written to achieve a simple goal – yet this small blogging system quickly grew exponentially in popularity following a carefully made plan designed to meet the needs of current and future users.
This plan certainly paid off, in 2020 WordPress is by far the most popular CMS with 60.4% of the market share and is used by 33.5% of all the websites online.
This type of story – and the ethos is embodies – is what drives many open-source developers on – the idea that their small projects might be discovered and prove useful to others – and in turn they might have the chance to grow them into something more substantial with the help of other developers.
The current stated aims of the WordPress Development team is to compete with other drag-and-drop website builders, which might not be something all developers want to hear, as it almost inevitably means more usability layers being bundled into WP Core, when they might prefer that some are being removed or that focus is on moving Core to a modern OOP pattern.
As Josh Pollock points out in another great article for Torquemag:
A lot of professional developers get upset when Matt Mullenweg (and others) frame the path to growing the WordPress marketshare in terms of taking on drag-and-drop website builders like Wix and Squarespace.
When deciding what technical direction to take the software, WordPress applies it’s own version of the 80/20 Pareto Principle, which we can see stated on their Philosophy page:
The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.
We are able to do this because we have a very capable theme and plugin system and a fantastic developer community. Different people have different needs, and having the sheer number of quality WordPress plugins and themes allows users to customize their installations to their taste. That should allow all users to find the remaining 20% and make all WordPress features those they appreciate and use.
Slow Progress
WordPress Core has a structured technical development approach and puts a lot of focus on low level users and backwards-compatibility, which essentially means that nearly all old features are initially retained – then slowly deprecated over future releases based on an agreed road map.
A good example of this would be the jQuery library which until WP release 5.5 was still using jQuery version 1.12.4 – which was released in 2016 and is well behind the current version of 3.5.1 – the reason for holding things back on a previous release of a library included in WP core is to avoid technical issues for website owners and plugin developers – it is a safety net offered at the expense of new functionality.
Of course, plugin developers could use the WP API to remove the bundled jQuery version and ship their own, but the result might present issues to others, as WP and all other plugins would expect the bundled version to be included.
This tread carefully approach might work well to protect less technical users, but it has an inevitably negative knock-on effect on the entire eco-system, as WordPress requires plugin or theme authors to work with the bundled version of common libraries instead of including newer versions which might cause dependency issues or multiple versions of the same library to be loaded.
This is the main reason that WordPress Core is a miss-match of code, knitted together by hundreds of developers without a coherent coding style – and that Core approach has a clear knock-on effect to the modules that extend it – plugins and themes – nearly all of which mix data and presentation layers freely due to the lack of a base MVC pattern to implement in extensions.
This can be seen even in WordPress themes developed and released by the WordPress Team, take for example the latest default theme Twenty Twenty One – the code below is from the “comments” template and freely mixes logic ( PHP ) with presentation ( HTML ) – this is also because WordPress does not natively support Template Engines:
Core Development Plugins
During the process of updating jQuery, the WordPress Core developers released a plugin to allow other developers to test the changes before they were integrated into the Core version – giving the Development Team feedback and fixes to avoid disruption for end-users when the official WP release rolled out.
The same approach was taken for other impactful changes to Core, such as before the REST API was woven in or the standard editor switched from TinyMCE to the block ( Gutenberg ) editor – and once the Core editor had moved, a retrospective Classic Editor plugin was released to allow traditionalist to continue, as if nothing had changed.
As such, using plugins for this process offered a practical and flexible way to test out new ideas and to gather feedback from users to smooth the process of developing the Core WordPress code base – this aligns with the official descriptions above of what constitutes a plugin and the role they should play.
Guten-iceberg
Many developers don’t like shortcodes – which essentially place PHP functions inside data blocks – nor Widgets, which were either too liberal to be controllable or too limited to be of any use – and Gutenberg is essentially shortcodes + widgets merged into one feature – here is how WordPress describes the new block editor:
If it helps, you can think of blocks as a more graceful shortcode, with rich formatting tools for users to compose content.
And here is an example of the data that is stored inside the post_content field of the posts table – markup and block commands are mixed together inside HTML comments – from a data purest point of view, this has a bad code smell:
<!-- wp:paragraph {"key": "value"} -->
<p>Welcome to the world of blocks.</p>
<!-- /wp:paragraph -->However, we are fans of the REST API, but we doubt that it passes the 80/20 test – as such it would seem to be a perfect plugin use-case, the same could be said about Gutenberg – keeping these add-ons in plugins would keep Core lightweight, flexible and more user-agnostic.
What else can Plugins do?
We’ve seen some example of how WordPress itself makes use of plugins – to test and prepare for updates to the Core system – but most plugins will not end up being a part of Core, as they are built to meet requirements which would not pass the 80/20 test – however, they do manipulate WordPress Core to add functionality – or remove it – as in the case of the Disable Emoji plugin, to remove an odd feature which somehow made it into Core.
At this point, we could say that plugins exist in order to manipulate ( add, remove or alter ) the WordPress Core system – so perhaps the correct question is not what “can”, but rather what “should” a plugin do or not do – as clearly an extension that can control nearly any part of the core system is very powerful.
We wrote and maintain and number of plugins on the wordpress.org repo which extend WordPress to offer functionality which is not part of Core, but which many users look for, one such example is our Export User Data plugin which offers a simple way for users to access stored user data and metadata using filters and options to refine the list.
The plugins we wrote passed by a few validation steps in order to be accepted on to the wordpress.org repo and there are some rules governing submission, these cover basics such as:
- License terms – logically, all plugins should be released under GPLv2 or later to match WordPress )
- Code security to protect users from exposing their private data or database unknowingly ( WordPress has a very simple database layer, which most data mixed together inside a few tables of a single database )
- Responsibility for updates and fixes and provided support via the auto-generated forum.
- The structure of the plugin and how this should be prepared to work correctly with the archaic SVN system.
- Coding style – readable and unencrypted to enable others to edit and update and also to avoid obscured security issues.
- There are several things explicitly not allowed, such as user tracker, trialware, executable code, anything illegal etc, however SaaS tools are allowed
While the list does touch on moral and legal questions, what is really missing from the detailed list of rules which govern plugin submission is purpose – what a plugin should do – or not do – and which areas of WordPress are sacred and should not be touched ( to some degrees available filters control this ) and what concepts are not deemed acceptable.
Recently we submitted Willow our WordPress Template Engine to the plugin repo, but this was rejected – WordPress offered the following reason why:
Your plugin has been rejected because we no longer accepting frameworks, boilerplates, and libraries as stand-alone plugins.
The explanation fell short of our own understanding of what a plugin was – which was the inspiration to delve further into this subject and to produce this article based on what we have discovered so far.
Beyond WordPress
It’s important to note that it’s possible to run plugins on WordPress which are not hosted on their own plugin repo – a plugin file can simply be dropped into the plugins directory – and as long as it has the required comment block and format – WordPress will run it.
It is also possible to host your own plugin repo, for example on GitHub or any other third party host – we do this with most of our private client projects ( as they are proprietary plugins which have no reason to be publicly hosted and installed by others ).
The main issue with self-hosted plugin is how to manage versions and updates across multiple installs, even if that is just local, staging and production versions – we achieve this using the excellent Github Updater Plugin – that’s right a plugin to update plugins, see how the lines blur!
So, what is a WordPress Plugin?
Right, so the point of this exercise was to find a clear definition of what exactly a WordPress Plugin is – but we have not yet found anything really satisfying or fully encompassing, so perhaps we’ll just go ahead and create our own for now, based on the the official take, the views of others and our own experience.
A WordPress plugin is agnostic and has no technical limitations. It is able to manipulate the core WordPress system, other plugins or themes, by adding, removing or altering how features behave and are presented – it can also add new features which are not part of WordPress core and may optionally be hosted on wordpress.org.
Any thoughts? drop them in the comment section below 🙂
No comments on this article yet.