Since I haven’t written a blog post yet, only pages, I thought I might give some of my thoughts on WordPress.
My biggest frustration is that it encourages the webmaster to give the server daemon write permission to some dangerous things, including PHP files the server executes and directories that PHP files are served from. It also encourages the webmaster to give write permission to the
Granted all those are one method of making web-based administration easier for the webmaster, but they violate well established security protocol. It just takes one bug in core or in a plugin and an attacker can modify files that either impact how the server daemon behaves (the
.htaccess file) or that are executed by the PHP processor.
Programming is about solving problems, but good programming solves those problems without creating dangerous new ones.
Another issue I have with core is that I do not understand the logic of what makes it into core and what does not.
It seems to me that eye candy is much more likely to be included in core than actual functionality that improves things.
Just as an example, Core does not have a mechanism for correctly creating the parameter strings needed to use the Google Fonts. If you look at themes that actually use Google Fonts (seems to be most of them), the almost all do it the same way. Even the comments are the same. It’s like they all cut and past from the same common source.
When that is the case, the right thing to do is to create a core function that does it. That way when there is a flaw in how it is done, as there currently is, you just need to update that one function and everyone benefits.
The three flaws in the common way themes make use of Google Fonts:
fonts.googleapis.comas the domain to use.
fonts.gstatic.comto the DNS prefetch.
https://as the protocol to use, but instead specify
//without protocol so that the same protocol is used the server is running on. Third party resources should always be https when possible, even when the server serving the web page has not migrated yet.
And I do not fault the theme developers for that. I repeat, in capitalized bold, I DO NOT FAULT THE THEME DEVELOPERS FOR THAT.
The job of a theme developer is to create an aesthetically pleasing theme that works well on a variety of modern devices and follows standard established accessibility guidelines. By the way, the theme I am currently using does not, I plan to create a patch for it that does and submit it to the upstream developer because I actually like the way it looks.
It is the job of core to provide such commonly used functionality as generating the GET parameters for a Google Fonts call. WordPress Core is not doing its job.
Class autoloading is heavily used in PHP, and has been for several years. It’s the right way to do object oriented programming.
There is a bug 36335 from 2016 asking for an autoloader. The proposed autoloader in that bug request is vastly over-complicated, a simple autoloader that works with any class that follows the PSR-2 file naming convention is all that is needed. I wrote such an autoloader in ten minutes: wp-autoload.php. Granted I only tested it by running the code in my head, and for that script itself to be PSR-2 compliant the class would need to be split into a separate file. And the class should probably also have a static function for autoloading PEAR modules.
But something very simple like that is all that is needed, and it should have been in WordPress core soon after that bug was filed. What is suggested in that bug should not, it tries to do too much, but I suspect an autoloader that does too much is what will eventually make it in. Code simplicity is not something WordPress Core is very good at (e.g. they use a frickin password generator to generate salts instead of just base64 encoding some random bytes. The insanity, it hurts!).
The result of Core not having a class autoloader is that theme and plugin developers have resorted to including composer in their plugins and themes. I sh*t you not. It’s insane. They only have to do this because a function they need is not available in the platform they are writing themes and plugins for.
But WordPress Core does have eye candy crap that belongs as a plugin, such as a broken fallback emoji generator that uses third party hosted SVG files for emojis and emoticons when it often incorrectly thinks the browser does not natively support them.
It does not make sense to me that key functionality plugin and theme developers need and have needed for years is not in WordPress Core but stand alone eye candy that could be a plugin and does not include an API plugin developers ever use is part of WordPress Core. It just does not make any sense to me.
You’ll notice I mentioned several PSR standards here. It seems WordPress really needs to have someone looking at PSR and recommending what they can do to meet PSR guidelines. It would really improve WordPress. PHP-FIG (creators of the PSR standards) was created precisely for that purpose, but WordPress is not taking advantage of it.
With respect to plugins and themes, they are optional and no one has to run any particular plugin or theme.
What I dislike about them though is how many pretend to be free but are actually nagware trying to get the user to pay.
I don’t mind nagware, but the way the nagging is done really puts me off.
The theme I am using is an example. After installing it, there is a suggestion to pay for a license that has additional features. That I do not mind. What I do mind is that it is constantly nagging me to install stuff I really do not want or care for, like Woo Commerce.
The theme recommended I install a components plugin developed by the same theme developer. So I installed that. It didn’t give me anything of value, just significantly magnified nagging showing me all kinds of options I do not care for that I could have if I paid them.
That kind of thing seems very common in the WordPress world, and I really dislike it.
Feel free to comment below.
Thank you for your time.