It's not just a question about the software engineering benefits of PHP (or of Wordpress) but also about deploy-ability.

When I started programming CGI scripts in Perl it was unusual for a web server to be configured to let just anybody write CGI scripts because it was easy to hose a web server or a whole machine with CGI scripts. CGI scripts had a highly inefficient execution model, and no resource limits to prevent CPU and memory overages from bringing the server down.

Now, in principle, mod_perl is better, but practically, a mod_perl installation is rocket science. I saw more than one organization with a crumbling system written in Perl reject mod_perl, because their existing code base wouldn't work correctly in it and because they didn't have faith that they could work all the problems out.

PHP, on the other hand, put a trouble-free installation and deployment experience first, rather than last. PHP might be a crappy language, but an absolute idiot can build a very reliable web server that performs acceptably with no effort. Python, Java, Ruby and other languages are superior in many ways, but they've spent years hacking together deployment answers (with various levels of success) as an afterthought, whereas PHP had performance, reliability and simple deployment baked in from day one.

Can you give more detail on this? I'm curious if they're really that bad or if this is just a common thing to say because it's cool to hate anything built in PHP. I made a basic template for WP and I thought the little parts of the API that I used were fine. I've never done anything serious with WP but I do run a WP install.

Some tidbits that come to mind off the top of my head:

Until a few (minor) versons ago, some functions built entire translation tables EACH TIME they were called on the same page load. Someone finally caught it recently and put a static in there.

The critical add_action/do_action functions had a slowdown issue up to a few versions ago if there were more than a dozen actions on a filter. It was finally optimized to be hundreds of times faster.

The first time they tried to update the cookie functions for a major release (I think it was 2.5) they misunderstood the research paper and had to change cookies again in 2.6, breaking some plugins twice in two versions.

The meta tables until very recent history were allowed to have non-unique indexes on key values. This "feature" (an alternative to serialization) was almost never used and made meta updates much more complex (and the db slower in general).

The entire tag db structure was changed in version 2.3, breaking all tag plugins, because someone thought it was theoretically better to have a "Term_taxonomy" reference - which is still unused to this date. Having it in there makes tag queries much more complex and slower. Then they took out the timestamp for when tags were added which makes it impossible to track.

The list goes on and on. Remember, a few versions ago is still 2009.

Last time I checked (2.8?) WordPress still uses SQL_CALC_FOUND_ROWS which has some nasty performance problems on many versions of mysql.

To this day, the query count for most pages on a default install with a few posts/comments without plugins is over 20. WordPress 3.1 now uses nearly 1 megabyte of php code PER INSTANCE.

Oh and last but not least, ALL plugins are loaded on EVERY page load regardless of the request/rendering requirements. Even admin-only functions. Clever plugin authors can somewhat code around this but it's still a crazy system.

My current least favourite design decision is the import/export system. It spits out posts, links etc in an XML file.

So far so good, except that upon importing, it creates an entire tree any memory before doing in processing. I complained to Matt about this being a less-than-ideal design. His response was, essentially, "it works for me".

Of course it works for him. He has dedicated servers with gigabytes of RAM. I do not. What I do have blogs with dozens of authors, thousands of posts and hundreds of thousands of comments. Consolidating them on a single installation of Wordpress has cost me days and days.

Oh, no, I'm a PHP developer myself, and I think that PHP code can be well structured, but Wordpress is generally a mess. It isn't MVC, a lot of it isn't object oriented, and it generally lacks a logical sense of things.

It has gotten better over the years, though, I will grant it that.

There's a lot of non-MVC, non-OO "good" code out there. An immediate example is the Linux kernel. I just don't think that's really a great argument; the last several web projects I've done have been MVC, but I haven't really developed an affection for that format, and some implementations (CakePHP ಠ_ಠ ) make it serious pain in the rear.

I guess "no logical sense" is the most legitimate complaint here, but aren't a lot of programs also like that? A lot of things start out one way and end up finding a niche in something different, and that can make the initial assumptions costly and/or annoying, but I don't think it necessarily taints the whole codebase, though.

Maybe I'm old-fashioned but a huge rap sheet of functions is a lot more workable for me than a lot of OO programs that I've had to deal with.

MVC (or OO) is not a guarantee against bad code, but it does provide some necessary structure, especially for large, extensible projects. Other patterns can also be utilized, but some kind of pattern needs to be implemented. Wordpress had no logical pattern to it's implementation.

Also, MVC wouldn't make sense for the Linux kernel, but it would make a lot of sense for a major CMS.

A lot of the Linux kernel these days is basically OO, at least the parts I look at. It's not in an OO language, but the concepts and patterns are there: an opaque void * "object" that's only accessed via a set of associated "methods", which all have manually name-mangled names like foo_method1 and foo_method2. These "objects" are created via a "constructor" foo_create and destroyed via a manually called "destructor" foo_free, etc. There's even a little bit of manually implemented inheritance and virtual-function stuff going on with function-pointers-in-a-struct type patterns.

Generally a "because it's cool to hate anything built in PHP" thing.

If you take a look at wordpress's internals especially nowadays they aren't that bad

If anything I would say the codebase is not bad and the user interface is amazing. I love it because I know that even the least tech savvy of my clients can figure out its backend user interface so they can make content changes themselves.

Another great thing is especially at this point in its maturity you wouldn't need to alter the wordpress codebase itself at all to get most of the value out of it.

Plugins,whether found or written by you, can take care of whatever you need.

Please don't downvote this guy any more without discussing why he's wrong.

Just take a look at the WordPress' code. "aren't that bad" is like saying shit doesn't smell bad if you get used to it.

Hell, you don't even have to look at the code. Even running some static analysis will tell you how bad it is.

As a simple example, back in the earlier days, Wordpress was mostly a collection of a many, many functions. As it has matured, it's become more class based and slightly less functions. Perhaps more importantly, many of the functions now have quite good phpdocs so you can simply grep the code to figure out what you want to do. Also, as WP has matured, it's added a lot more hooks and actions for various things you might want to do, so it's become less and less necessary to hack core.

It is still relatively brutish code, but damnit if it doesn't work pretty well.

The same with any other product, the internals would only matter to the technical people.