Beyond WordPress

We want to use this post to set-out some of the reasons why we are considering this and to see if any users have feedback or opinions they want to share.

This was not a simple decision, having some of our plugins hosted on WordPress.org does bring some benefits, mostly to users of our free plugins, who can easily find, install and update plugins without needed to get their hands dirty, thanks to the tightly integrated nature of WordPress.org and its own Theme and Plugin repositories.

Reasons

Writing and sharing Open Source code is a pleasure, it’s a great feeling to know that something you created is also useful to someone else and the feedback and collaborations which this can bring around are developmental and can return positive contributions to the commercial work we produce for our clients.

As a business we are also very aware that writing, releasing and supporting OS code is a very time and resource hungry activity – and one which brings us no economic benefits – but we see that as a basic obligation, seeing as our entire business model is based around the use and customization of another OS project, WordPress – for us, it’s a positive loop.

Over the last few years, the WordPress theme and plugin teams – the so-called Gatekeepers – have introduced tighter rules, more stringent validation and immediate takedowns for plugins found or reported to be insecure or in some way in violation of the latest version of the terms.

Yet, a quick browse of the plugin repository will turn up many outdated, unsupported and no-doubt insecure plugins, covered in dust, untouched in half a decade, yet still freely available for unsuspecting users to download and install on their already probably poorly protected and outdated WordPress instances.

This is not a criticism of other plugin developers, as we also have a hosted plugin on WordPress which is untouched in 6 years, yet remains publicly available to install, and is no doubt, outdated and insecure – we totally understand how this happens, it was a good idea at the time, yet overtime became less important until eventually it was abandoned at which point it really should have been removed, but for whatever reason it was not.

Some of our plugins – such as Willow – were never hosted on WordPress.org, due to not meeting certain requirements, which we find to be very fluid and open to personal interpretation.

In the case of Willow it was rejected for being a “Framework” or a “Developer Tool” – loosely defined as a plugin which had no immediate visual effect when activated – which, of course, is the case with many plugins also hosted on WordPress.org, some of which are essential tools , such as Advanced Custom Fields.

And, while we might be developers, most WordPress site publishers are seen as end-users, who should be protected from tools which are beyond their abilities to use or understand – or so the story goes..

Way back when the internet was still wild and free, the WordPress plugin team took a more lenient approach to accepting submissions, many more applications were accepted, code quality varied highly, standards where non-existent, UX was abused and functionality was a roller-coaster –  and we did not get to the topic of security yet…

Recently, the Gatekeepers have been taking down plugins based on bug reports from what they describe as “less than ethical ‘security’ firms”, mostly concerned with XSS or CSRF vulnerabilities – these reports are often correct and highlight important security, which should be addressed – the issue we have is not with these reports, but rather with how they are communicated and handled by the Plugin team.

Faulty Logic

The problems here are multiple:

• Removing the entry point to installing a plugin does little to resolve the existing security flaw for any site which has the plugin installed – WordPress could also force the deactivation or even removal of this plugins from each hosted site, but that would expose WordPress to criticism for any side effects that action might take
• Community coders make generous contributions to WordPress and have helped in some small way to elevate the value of the company into the billions, yet WordPress offers no technical support when bugs are reported, instead they transfer full responsibility for code hosted on their own repository to the developer and they follow this up with threat about how these mistakes will reflect on the developers.
• Often the code flagged as insecure is in fact not – such as instances where code is not escaped “late” enough, but still fully escaped and noted as being escaped correctly or perhaps commented code which contains unescaped echo statements ( WordPress argues that commented code also remains dangerous, as a user could uncommented it, but the same could also then write any insecure code they want, which means that users are the danger, not the code ).
• The language used to communicate flagged problems is condescending and often contains false statements or indirect threats if the problems are not resolved quickly – we were recently told ( without any evidence ) that a minor security bug would be used to “hurt and humiliate” us by the unscrupulous firm that found it – that’s a form of bullying and not unacceptable.
• In a recent exchange with the plugin team we were told that our plugin would be deleted to punish us for questioning the request, when it would surely have a much more negative effect on the users of the plugin.

Pros and Cons

There are both benefits and downsides to hosting plugins on WordPress.org, here are a few of the main considerations:

• Pros
  • Projects works is placed in a large shop window in a huge shopping center which continues to get a lot of customer footfall.
  • By being required to keep up to date with modern standards and requirements, developers learn new methods and approaches, which can have a positive effect on commercial projects ( but note that WordPress Core remains a graveyard of legacy code and practises ).
• Cons
  • Often – as in our case – incalculable hours of free coding & support work may never lead to a single direct or indirect commercial gain or any source of income.
  • Users can leave poor ratings based solely on their expectations not being met – and while it is possible to respond to these reviews, the scores remain, lowering the overall plugin ratings, which in turn affect user-uptake.

Impact

Let’s examine some of the real-world impacts on users of removing plugins from the WordPress.org repository?

Sadly, mostly are not positive, as WordPress tightly controls the gateway to install and update plugins, authors who chose to move beyond this route are required to provide their own mechanisms to allow users to take the same actions, usually by installing an auxiliary plugin such as GitHub Updater or our prefered choice of  bundling a vendor plugin called Plugin Update Checker which provides a simple API to connect to private and public repos on GitHub and filter in updates to the WordPress update checker.

By bundling a system to check for updates we can take care of one key part of the plugin lifecycle, so that end users have an essentially native experience when updating an installed plugin, but this does not help with the issue of allowing users to find the plugin or install it, without them needing to step outside the safety of the WordPress repository and the extra inconvenience of needing to upload or ftp code they download from the wild – both of which are understandably risks which WordPress would rather users did not take.

So, that begs the question, why does WordPress force developers hand so much, both in terms of limited access to the WordPress repositories and also in how plugin and theme developers monetize their projects, usually via freemium versions with showcase paywalls – you see the features, but are denied their use, until you upgrade – again, off-site, at risk to the end-users WordPress tried so hard ro coral in and protect.

Some of the positives of working on a self-hosted plugin using Github are:

• You can build plugins to your own standards, however we have no technical issue with those defined by the WordPress plugin team, but find them loosely enforced.
• Issues on GitHub are delivered in a useful format and often come from users with a higher level of experience, meaning they are more descriptive and easier to resolve
• Other GitHub developers can easily fork projects and propose structured changes via PRs

Future Moves

Perhaps the problem is really one of design and scale – WordPress has reached a junction, moving from the free, open world of OS into a corporate world of responsibility and risk management.

WordPress is a widely used system, stable and capable, but still relies on an outdated extension repository model which has a massive bottle necks and does correctly support reflect the needs of either end users nor developers – in boths cases it is too restrictive and at some point this blockage will induce a movement away from the safety net of the managed repositories towards a system able to cater to the requirements of both website owners and also the developers who produce their essential tools.

Please add your thoughts below.

Notes and after thoughts:

• One recent development to WordPress blocks the update or installation of plugins which do not match current PHP version, for example, the most recent version of the stalwart User Role Editor plugin shifted the minimum PHP version to 7.4, meaning any sites running an older PHP version were blocked from applying the update – meaning WordPress can and does take decisive action to block certain user actions, when they are deemed unsafe – so, why not also undertake a total cleanup of the repository and also remove all the abandoned plugins?
• A code repository is not the same thing as a web host or an email host – it is not the place where your web pages are served from, rather it is where you store the versions of your project code – WordPress.org does this using SVN, while a more modern approach is based on Git and its popular GitHub range of services.