The design issues are also in other parts of the system. Major silliness of WP is, that basically every tutorial and documentation encourages a pattern of concattenation, instead of composition. This is in PHP tradition, which just runs scripts from top to bottom, which means you can change code while it is running and next request it will run your changed code, if it passes by that part of the code to handle the request. In the WP ecosystem countless plugins engage in making their parts unreusable, by following this concattenation idea. They will start some HTML element in one part, but not close it. That job they leave to another part, which you just have to implicitly know must come later, to close all the tags. The different parts are described at [1]. This also implies treating HTML as a string, also in old PHP fashion, with all the issues coming along with that.

Worst is, when you have people, who even manage to break composition on the procedure level by doing the following: (1) open php "tag", (2) write function header, (3) close php "tag", (4) write plain HTML inside the PHP function body, which results in outputting that HTML as a side-effect, instead of returning it as result value, (5) open php "tag", (6) insert closing brace of function.

Literally, makes the code only usable in very specific places, where that side-effect is just in time for the document creation, otherwise cannot be used. You cannot use this and then wrap it with some other HTML, because it is already output as a side-effect. Of course since it is stupid tradition to treat HTML as string, you also cannot pattern match on that stuff and cannot have intelligent operations work on the result.

But not only this major F up. No. The use of global state is very pervasive. One doesn't pass in information to templates to then have information locally and render templates independently from the rest of the system. Instead rendering templates happens while frequently retrieving information from the global state.

Another bad design is how one provides metadata for plugins inside comments inside the code of the plugin, instead of having a clearly separate metadata file. Of course this doesn't lend itself well to being edited automatically, as one would have to parse PHP code and then work on an AST to change it. But I guess no one responsible for this design has ever thought that far.

The whole thing feels more like it is made for people, who live edit code on a server and then check 20 times whether it now works and the moment it looks right, they drop everything and call it a day. This is also the impression that the quality of plugins leaves. You want to see bad code, you just grab a random WP plugin.

WP is in essence a guide showing by example how not to develop a website.

[1]: https://developer.wordpress.org/themes/classic-themes/basics...