I am trying to compile some data.
I have over the years heard devs bash WP/CP for bad/legacy code. In real terms, please share that one thing you found terrible in the codebase. Things like spacing don’t count.
I personally found having JavaScript and PHP and HTML mixed up is a cringe zone. What’s your viewpoint?
Am not asking for features we have petitions for that.
Actually (if I understand it right) when devs say that WP has “a bad code” they mean the whole architecture. From their point of view WP breaks many modern coding principles and OOP paradigm which are kinda industrial standard now.
WP doesn’t use MVC (or related) design pattern. It has no idea about business models, DDD and other things, since almost any entity is a Post. This also leads to a controversial database structure.
The hooking system itself breaks the SOLID principle and is considered antipaternal.
WP really mixes different tecnologies and methods due to the legacy reasons. Many functions are implemented several times or can be done in several ways. For example, customizer uses javascript copies of PHP templates to display theme settings (same markup is duplicated 3 times), WP itself tries to be both a traditional CMS (with a dashboard) and headless cloud platform (with REST API) etc.
Mixing PHP/HTML (+ JS/inline CSS in some cases) is a bad practice, too.
Build system (based on Grunt) is old and scary)
…
So, this is more about a paradigm/architecture than just code. People who use MVC frameworks (Laravel, Symfony etc) or build high-end modern apps won’t use WordPress anyway. And I suppose that they are technically right. But WP has strong ecosystem and is much cheaper for typical commercial websites (I mean average costs for the whole production cycle: building, management, support, upgrades). Its popularity is based on marketing values. Architecture and other technical things are not so critical here.
Really appreciate your feedback. Side note: do you have any ways we can sort some of these?
FWIW, using MVC is not as flexible as the WordPress hook system. I would leave in a heartbeat if it ever changed to MVC.
The REST API is redundant code.
The Customizer has a lot of redundant code and is slow because of so much JS.
By the way, the build system has changed since the fork of CP.
I think there is an inconsistency in the filters. Some are applied before the logic of the function, but a truthy value just returns it, and others are applied after the logic, passing the finished result. Either way, the logic often has to be duplicated to get the right filtered effect. I think more filters should be within the logic so it’s easier to modify.
I don’t mind mixing PHP and HTML, since that’s the true use of PHP. Even mixing PHP and JS is fine on occasion, but it is rare. PHP and CSS makes sense for theme options, but not for core.
PHP really is a filter language, and using classes only makes sense when there is state to maintain for the duration of the page request, such as WP_Query.
I don’t like how there is a config variable to use themes or not, and if you turn it off, you get no output at all.
I don’t like how the admin needs to do a lot of similar things as the front end, but the admin code isn’t really available to use.
I don’t like how the code grows and grows. Deprecated functions are rarely removed. There are some things that are too slow.
I don’t like how the focus is always on adding more features instead of fixing all the bugs.
I agree with your other points, too… but, this, for me, makes the development experience extremely trying.
WordPress has popularized the method of doing it inside out … it’s like a yoda-thing for markup, for lack of a better description. For example, this:
<?php // main opening tag
?>
<p><?php echo $whatever;?></p>
<?php
…should simply be:
<?php // main opening tag
echo '<p>'.$whatever.'</p>'."\n";
The benefits of doing it this way:
PHP is a scripting language.
Using classes actually makes total sense in WP/CP because it encapsulates your code without the need for silly-long prefixes. Additionally, classes makes it possible to better abstract and extend the code.
Agree.
I think hooks (actions and filters) are one of the best code-level features of WP/CP. They may not adhere to “modern” development principles, but with a bit of discipline (using a common prefix in your plugin’s hooks, for example) they are a very powerful and intuitive feature for modifying how a piece of code works, with basically no overhead when they’re not in use.
Admittedly this discipline in terms of naming conventions and common structure is lacking in hooks and general functions available within WP/CP. This lack of consistency is one of the biggest problems I have with the code - it’s all but impossible to remember the names and arguments (order, types, etc) that the major functions accept.
Another is just legacy code bloat. Here are a couple of examples of many - I challenge you to read them and understand everything that they can do:
I don’t agree that the REST API is redundant code, but I think it should have been rolled out more carefully with more restrictions by default.
I’m not convinced that any of these “major” things can be truly fixed without breaking backward compatibility and breaking a large number of plugins/sites in the process. According to our current approach this would most likely mean adding new features/systems and making them optional, but we are a long way away from having the development manpower to be able to undertake projects like this.
Same here. Hooks are what makes the system so easily extensible.
Ah, yes… great point. This has led some devs to reinvent certain wheels with wrappers, constants, or whatever.
I don’t like the settings api.
It doesn’t enforce a coherent UX between plugins settings but enforce the use of mixed html and php.
I think the WooCommerce (and soon Classic Commerce) settings API is much nicer.
Before I was thrust into the world of WordPress, my PHP experience was mostly based around CodeIgniter and, somewhat briefly, Laravel, both of which are MVC based.
I must confess that I do still miss that. MVC seems much more logical to my mind and it definitely better suited my way of working. My first impression of the WordPress codebase was “what a complete and utter mess”. To use an analogy, to me it was like being in a large comms room where there’s a rat’s nest of cables all over the place and nothing is labelled or colour-coded.
Another problem I had (and still have if I’m honest), is hooks. Great idea in principle but the biggest problem is knowing that they even exist. Plus, knowing the order in which they fire.
I also don’t like how admin-ajax.php, for instance, is required for the frontend.
I personally don’t mind mixing PHP and HTML. Any thoughts on templating engines, such as Twig or Smarty?
But this…
Nasty, very nasty. THAT just about sums it all up nicely.
I’d say this depends on a task (as well as everything else).
No need to swich WP to MVC. Switching paradigms is not realistic anyway, no matter if someone likes it or not. We can’t just throw the core away and start everything from scratch 
This has no sense.
My post just reveals the TS thesis and shows the typical reasoning of those people who don’t like WP architecture because they prefer another coding paradigm. I’m particularly involved into a couple of projects powered by Yii2 and Laravel (as UI/UX, not a dev). So I’m in touch with “another side of the moon”, too. But I accept both points of view easily, because I see advantages of both paradigms.
WP and its hook system is nice for typical websites with relatively simple business logic. But, for example, it is much simplier to implement a build-in CRM, when you have separate models/controllers fot Client, Order, Page, Manager (and 20+ others) and not only just ‘post type’. Especially if your CRM is a product itself and have to support 5 other CMS. So, all this depends on a task.
And since building websites is just a small piece of the whole industry and most devs are involved in different types of projects (apps, services and other software), it’s no wonder why many of them are a bit frustrated when facing WP.
Personally when I participate in a project, I simply accept its traditions, no matter what I prefer ‘outside’. This helps me to avoid global dogmatic opinions on MVC/hooks, tabs/spaces, dogs/cats and other holywar things (until they directly infringe my commercial interests ).
This shouldn’t be the case in core, but maybe with some plugins?
Re: templating engine petition. 10 votes in 12 months and a blank GitHub Blade theme repo. Guess it’s not too popular then I’ve used Twig in the past (in PyroCMS) and it was pretty useful at times but I still don’t think I’d want to see it built into CP core. It’s something I can live without.
Yes, you’re right. This only happens with some plugins now. So that’s a plugin issue, not a core issue. Forget I said anything 
What about PHP 5.X code? Would it be a good idea to remove it and keep only 7+?
Also, what about backwards compatibility? Basically, ClassicPress doesn’t need anything pre-4.9. If there are any plugins using deprecated code, someone could fork them or work with the author to update the code.
The version 2 roadmap gives an indication of what is planned. As you’ll see, it is proposed to move to PHP 7.x and to begin to introduce changes that may break compatibility with WP 4.9.x plugins and themes.
@james may want to comment further but essentially, the two issues you mention are already being looked at.
Some of this is happening in WP, and can be ported to CP. There were several tickets already handled in WP 5.2 and 5.3.
But PHP evolves, and it’s not as if you can label code as 5.X or 7+ if it is the basic language, which has been around since the beginning. The newer versions of PHP introduce different ways to do things, but they don’t have to be used.
Part of what makes WP 4.9 what it is, is it’s backward compatibility. So if you advertise that CP is compatible with WP 4.9, that includes all the pre-4.9 compatibility also.
It’s not just about making use of new functionality. Newer versions can also introduce deprecated functions and break backward compatibility. PHP 7.0, for example, focused heavily on removing code that had been deprecated in previous versions.
So, by requiring PHP 7.x and above, you can remove any code that exists purely for compatibility with earlier versions. And, you can also take advantage of the newer, more efficient code. Win-win.
Yeah, I mentioned “Some of this is happening in WP, and can be ported to CP. There were several tickets already handled in WP 5.2 and 5.3.”
That’s not how it works. You don’t introduce a deprecated function, you mark an existing function deprecated. And deprecation just means that it still exists but shouldn’t be used since it will be removed in a future version. (so deprecated functions don’t break anything)
You can use the newer language features, but that is not necessarily more efficient. The newer PHP versions have been optimized to run faster. You don’t have to use any new features to get the speed increase.
Besides, we’re talking about the existing codebase, not what to do next.
Semantics.
…until the deprecated functions are dropped completely. There’s a very real chance something will break when moving from PHP 5.x to PHP 7.x, not necessarily in the core, but certainly in plugins or themes. I speak from experience.
Efficient code is as important as raw speed. Take the spaceship operator (<=>) for example:
// PHP 5.6
usort($array, function($a, $b) {
if ($a == $b) {
return 0;
}
return ($a < $b) ? -1 : 1;
});
// PHP 7 with spaceship operator
usort($array, function($a, $b) {
return $a <=> $b;
});
@Ciprian mentioned PHP 5.x / deprecated code. That’s an example of one of the things we don’t like about the existing codebase.
TL;DR: I dislike the implementation of the Parent-Child-Theme feature. You cannot reliable use OOP within themes without jumping through lots of hoops and loops. It would be awesome if the child theme could inherit the parent classes - but with the current loading process, its the opposite: Child theme loads first, thus it cannot (easily) inherit classes from the parent theme.
Aside of that: I still hate the Customizer. Its matured a bit, but it still feels very sloppy, shoddy, and slow. And: That nasty piece of work nearly led me into a burnout when it came out!
Namespacing would be great to avoid all the prefixing orgies.
A decent, easily extendable Admin (UI) framework that is not just an afterthought, like the Settings API or the Customizer are - yes, THAT would be great. So, yes, I also very much dislike the fumbling and tumbling around with different sized toys and tools in the WP / Cp backyard, ie. the Admin interface.
Oh, on third glance, I also hate that there is no easy way to implement proper cli-based and semi-standalone tools - ie. you always have to load the full chain, but cannot eg. selectively skip plugins, skip them all together, do not load the whole Action and Filter tree, but just selectively up to a specific point. To avoid all that, you have to nearly reinvent everything. That is soooooo bad. So much time wasted which could have been used so much better, to be invested in improving other parts … tsk.
cu, w0lf.