Tag: The Sins of WordPress

All nanny state ideas sound great until you get down to the ways they are being implemented. The manifestation in WordPress is the “automatic update” of core/themes/plugins. The notification in the admin panel as if tells you “There is a new version just install it, it takes less then a minute, and you will have the latest, greatest, and secutitest (just made up the word).

In reality the nanny state promises things that it can not actually check. Does the new version has breaking changes? how was it actually tested to ensure that there are no bugs or security issue? the nanny state just do not know, but still the message is “trust me, I know”.  No wonder people actually buy into that message, after all most of the wordpress site owners have no knowledge about software development and proper ways to run a test on a “testing” site before upgrading production.

And what happens when an upgrade “killed” a site? The owner goes to the plugin/theme developer and tells him exactly what he knows about the profession of his/hers mother. At this moment plugin authors are mystified, after all in the TOS they did not guaranty that any version of the plugin will ever work as expected, and for sure they didn’t ask any site owner personally to upgrade.

So on the one hand the nanny state pushes people to upgrade but on the other refuses to take responsibility to the results, and worse than that, basically there is no way for the plugin author to communicate any possibility of breaking changes, as nanny state do not believe that such things exists.

Instead of teaching people to run tests before installing new version, or forcing hosting companies to provide such facilities, WordPress just pretends it has no responsibility for any breakage.

The plugin and theme repository are not the only manifestation of the nanny state in WordPress, it is less noticeable for most people, but exist in the planning of WordPress events. It is just unbelievable there are people still willing to jump through all the hoops and organize those events.

Wait what? didn’t you just say the exact opposite about users being assumed to be technical idiots?

This probably goes back into the days WordPress was created when it was far from being a complete software even if blogging is all you cared about, and you were mostly expected to be able to tweak the CSS, HTML, or add some PHP code. The days before commercial themes, plugins, or even a repository of them.

Those days are in the distant past, but WordPress did not succeed in finding a new balance between removing obsolete features which actually hurt security, and keeping a “hacking” culture. This is why you see the theme and plugin editor as part of WordPress, although just the ability to edit code files in the browser should be a big no-no from security point of view.

Worse, it is being made as an excuse for WordPress not solving security issues. To paraphrase WordPress’s security czar – “It is not our fault it is the fault of the user that didn’t configure his server properly” https://wptavern.com/wordpress-security-issue-in-password-reset-emails-to-be-fixed-in-future-release#comment-219662

It is not just the security aspect, more important is the software development aspect. If you are join to change the code you better save revision in a place from which you can extract them and reinstall them if something bad happens, but WordPress do not offer any such tool. So on the one hand you are encouraged to hack the PHP/CSS/HTML/JS with the most primitive tools around, but there is no support for basic development practices when using those tools.

Software development is not something magical, and to some degree everyone can learn to do it, but as you are unlikely to service your car by yourself all the time, servicing your site should be left to the minority of people who actually know enough to avoid doing stupid things instead of letting people the impression that they can just copy and paste some codes they found on the net.
Changing something is easy, making sure the change is scalable, will not hurt your UX, will not hurt your SEO and social sharing, and most importantly, will be documented so you will remember in two weeks why you have done it in the first place, is not that trivial.

It is as if there is not enough bad software developers that write code for wordpress, from time to time you run into sites which were hacked by their owners, and when they ask you how they can upgrade to the latest wordpress/theme/plugin, the only logical response is to run away.

Famous 5 minutes install, ha? no need to know anything at all about the web, webservers, PHP, MySQL, browsers, javascript, CSS, HTML (short list of things you actually need to know to some degree in order to operate a site for the long term), just upload the software to your hosting and click a button. Oh wait, that is too hard, it requires to setup a DB first and to use an FTP software, lets do it even easier and cooperate with the hosting companies to have a “one click install” in which the user will need to know only the domain name (I guess that with some shared hosting even that is not required), no other technical knowledge required.

Just try to imagine this kind of process in any other aspect of life. For example, you want to drive a car? just go and buy one, 5 minute for the credit card transaction to be approved, 5 more minutes to get the keys and sign documents and you can just drive. Learn how the car operates? Driving laws? what for, it takes too much time.
Even when you buy a commodity appliance like a laptop you are expected to have some basic understanding in the technical aspects, but the WordPress motto is “we serve the lazy and the dumb”.

There is nothing wrong with focusing on serving the dumb and lazy, as long as you are always doing the right decisions, and again with the way the internet changes all the time it is just impossible.  The problem starts when you do not give them any tool to work with when they actually decide that they do want to understand “how it works”. This is why from time to time there is a question on stackexchange about how to secure the login form against brute force attacks, when at least some of the time the people that ask to not even know they have an xml-rpc end point through which they can be attacked.

And when you do not even know there is anything to learn you are unlikely to learn it. A sad positive feedback loop.

Inspired and helped to articulate feelings into words by this great blog post by @rarst.

Sometimes you find yourself at the end of a deep rabbit hole and you ask yourself how did you get there. It is tempting to think that the problem is with you doing a zig while you should have done a zag but rarely you hear people asking what exactly was Alice doing outside by the river with no parental supervision in the first place?

It is pointless to discuss several of WordPress sins without understanding why they came about, and why there are not ever likely to get fixed.

In the beginning, in the good old days when WordPress was just a blogging platform, it was easy to understand the guiding philosophy – make web publishing easy and accessible to all.  This motto worked well and in an era in which you had to have some technical knowledge in order to even buy a domain, it was a major factor in WordPress’s success and in the flourishing of blogging.

Then, two things happened, WordPress decided it wants to be more than a niche blogging platform, but an actual CMS, and Facebook (and to lesser extant twitter) came and killed blogging. This caused a shift in perspective, WordPress do not measure itself anymore in how many bloggers use it (that ratio is declining due to people preferring to “blog” to their friends on Facebook instead of addressing unknown audience), but in how many installs it has.

The problem is that in too many cases quantity and quality do not go hand in hand. It might not be a problem if every decision being made is the right one, but it makes it impossible to change anything for the better if it means that someone’s site will stop functioning. This is true for every type of software but it is even more visible on the web where everything is almost always in a flux.

When you claim that 27% of the web is powered by WordPress, and give the (disputed) number importance it is very easy to see why you are not going to do something that will annoy about 5% (at this point in time) of your users by doing the right thing and dropping support for the EOLed and generally insecure PHP 5.2.

It is actually worse, as with PHP 5.2 there are at least mostly reliable stats on the amount of people that are going be be impacted from a deprecation of support, but there is no usage collection for almost any other feature, and no one dares to suggest changing or even deprecating any of them because the impact is literaly unknown. This leads into the worst kind of stagnation, where even bad decisions has to be preserved.

I am going to try to enumerate as many of the WordPress sins as possible (maybe to get it off my chest, maybe to have a place to point to when someone asks me what is my beef with WordPress) but it is very important to remember that everything in life needs to be measured in a context, otherwise all you end up with is just a pointless “holy rage” which might be cool when you need a reason to burn some adrenaline, but unless you are are religious leader or politician, it is very rarely productive in real life.

After all the things are said, the only interesting question for most people is “Is it the best tool to do X in terms of ROI or time to market?” and right now for many things the answer is still a “Yes”.