No, it's not well-engineered (speaking with over 25 years as a professional software engineer), at least the portions of the code I have looked at. Things I vaguely remember (it's been ten years since I looked at it) are lack of data normalization (and not in a performance optimizing way), template includes that depend directly on order of inclusion and variables in other templates, very little code isolation, and PHP.
WP is a well-delivered product that works well for its user base in most situations. Plenty of code is well-marketed, profitable, and fulfills users' needs, but not well-engineered.
By the way, I know the PHP gripe is contentious, but it's not the reason why I think WP is badly engineered, it's just the reason it was easier to engineer it badly.
If PHP was compiled with --disable-url-fopen-wrapper, it won’t work. (Docs don’t say what “won’t work” means; returns null, throws exception?) Note that this flag was removed in PHP 5.2.5.
If allow_url_fopen is disabled in php.ini, this still won’t work. (How? No idea.)
Because of the @, the warning about the non-existent file won’t be printed.
But it will be printed if scream.enabled is set in php.ini.
Or if scream.enabled is set manually with ini_set.
But not if the right error_reporting level isn’t set.
If it is printed, exactly where it goes depends on display_errors, again in php.ini. Or ini_set.
I can’t tell how this innocuous function call will behave without consulting compile-time flags, server-wide configuration, and configuration done in my program. And this is all built in behavior.
I would argue that Wordpress is a great example of how something doesn't need to be "well-engineered" (when it comes to abstractions, maintainability, etc) to be widely useful for many.
Although I think the exception there is security (and yes I know many will say clean and well engineered code is secure code). Security has to be solid or it will impact too many people negatively.
For years, wordpress stored user session data in 'wp_options'. Moderately trafficked sites needed to come up with regular purging hacks to 'clean' their wp_options table. Why? Session data is not an 'option', it's... session data. Make a database table called 'wp_sessions'. Transient 'cached' data also... in 'wp_options'. This was not an example of 'good engineering'.
This is just one of many examples of suboptimal tech decisions. Some have been mitigated, updated or otherwise 'fixed' over the years, so they may not be relevant any longer. It's a very popular and widely used platform despite some poor development and engineering choices, and perhaps even in some cases because of these poor choices, but that doesn't make them good engineering.
The idea that no one is allowed to criticize anything unless they can and have done better is one of the most perniciously stupid ideas out there that just won't go away.
If the parent poster is secretly Linus Torvalds, do you walk away in shame because he HAS done a project with better engineering? Or are the criticisms, perhaps, objectively valid or invalid, and worth engaging with regardless of the merits of the person making the criticisms?
Well when their whole argument boils down to "php sucks" and they back up their claims with a document that was invalid 12 years ago when it was written, they better have something to back up these criticism.
Perhaps you should engage with the claims rather than the person. As someone who doesn't frequently use PHP, the criticisms in the linked post from 2012 seem valid if the facts presented are true -- there's some pretty weird, and in a few cases, downright dangerous behavior presented there.
What is invalid, specifically, about that blog post?
It's amazing how many people's opinion of PHP is stuck in a time warp from 10-20 years ago. It's now a much better language than it was then. It's fascinating to see programmer snobbery in real time.
WP is a well-delivered product that works well for its user base in most situations. Plenty of code is well-marketed, profitable, and fulfills users' needs, but not well-engineered.
By the way, I know the PHP gripe is contentious, but it's not the reason why I think WP is badly engineered, it's just the reason it was easier to engineer it badly.
See https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ for more details on PHP.
One excerpt from that page:
There is a whole lot of action at a distance. Consider this code, taken from the PHP docs somewhere.
@fopen('http://example.com/not-existing-file', 'r');
What will it do?
If PHP was compiled with --disable-url-fopen-wrapper, it won’t work. (Docs don’t say what “won’t work” means; returns null, throws exception?) Note that this flag was removed in PHP 5.2.5.
If allow_url_fopen is disabled in php.ini, this still won’t work. (How? No idea.)
Because of the @, the warning about the non-existent file won’t be printed.
But it will be printed if scream.enabled is set in php.ini.
Or if scream.enabled is set manually with ini_set.
But not if the right error_reporting level isn’t set.
If it is printed, exactly where it goes depends on display_errors, again in php.ini. Or ini_set.
I can’t tell how this innocuous function call will behave without consulting compile-time flags, server-wide configuration, and configuration done in my program. And this is all built in behavior.