Hacker News new | ask | show | jobs
by Communitivity 624 days ago
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.

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.

2 comments

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.

Ah yes, the infamous 12-year-old fractal of bad design article which is almost entirely obsolete.
Nope, as someone who has coded modern PHP recently I would say it is mostly still relevant. Some of the issues have been fixed but most remain.
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.