Not the OP, but I’ve fought Wordpress plenty of times as well. Probably the worst time was when I was writing a WP authentication plugin for my org. I was reading the docs when I ran into this gem[0]:

> The semantics seem rather fuzzy. If id is a WP_User or other object, or an array of properties, it seems to clone it without touching the cache. Otherwise if id is a number it seems to try to read it possibly from the cache, or from the database using ->get_data_by(), which can also update the cache. If id is empty it reads by login name.

I realized that if even the offical documentation didn’t know what Wordpress was doing, I definitely had no hope.

[0] https://codex.wordpress.org/Class_Reference/WP_User

I’m not the fellow you’re replying to, but here’s my 2C. My perspective might be out of date, as I haven’t touched WP in 5 years or so.

-The plug-in APIs have been largely written by accretion, making them confusing and hard to grok. I always vaguely feel like I’m doing something wrong, that this shouldn’t be this difficult... Furthermore, API functions are inconsistently named, and return hard-to-predict datatypes.

- The theme tools are similarly confusing, and can make simple tasks take a lot of time. Sure, you just have to create magicfilename.php/css and put this magic snippet into it - but the discoverability in that is pretty garbage and results in a lot of hacks that solve things in the wrong way.

- Using other people’s plugins was a crapshoot, as plugin conflicts were (are?) pretty common. For a casual user plugins are a massive footgun, as WP makes it easy to install decade-old unmaintained junk plugins full of security holes.

Compare all of this to Drupal, which while far from perfect actually tries to design sane APIs and solid code, and iterates on it to correct their mistakes.

In my case, it just seems architected entirely backward, because of an accident of history that was LAMP and the only options at the time for having any kind of software running "on the internet" that could provide an authoring interface. The authoring software and its database and all the security surfaces and performance and cost associated with those should only be incurred when author changes are being made, not 24/7 when people are viewing content that isn't changing. The viewing experience can (and should) closely resemble a CDN of static pre-rendered documents, possibly plus thin edge-worker type logic around interactive features like comments or form submissions.

Check out the public API, read the source, look at the data model.

Wordpress is a workhorse on the web, but it is a complex, inconsistent mess full of weird edge cases. It is much harder to introspect, debug and reason about than it should be. You need tons of specific, specialized knowledge to interact with it as a developer.

The reason for that seems to be this: it is built with people in mind who cannot code, but the reality is that for many cases this doesn’t suffice, so you end up with a hodgepodge.

Mine are mostly state-related. The DB and files from a live site are so tied up in basic config & functionality that if you only have the source code repo you may as well have nothing.