I’ve used WordPress for years. I’m also a long-term amateur programmer, mostly specializing in C# these days.
One of the wonderful things about WordPress is its open architecture, which led to a marvelously diverse plugin and theme environment. You can almost always find something, somewhere, that will do whatever it is you want to do.
One of the most frustrating aspects of WordPress is its pretty primitive debugging environment. Which is a critical part of the infrastructure, because of that marvelously diverse plugin and theme environment. When the parts are designed, built and maintained by so many different people and organizations conflicts are inevitable.
I recently ran into this involving two popular plugins. When Plugin A was activated Plugin B threw 404 errors. When Plugin A was deactivated Plugin B worked as designed.
The Plugin A support team’s initial reaction to my request for help (I’m a paying customer of their professional version) was “oh, that involves Plugin B; it’s not our problem”. Which, as I pointed out to the respondent was ridiculous: when you have a system based on interacting components you cannot simply say “not our problem” without at least doing some research.
Which they decided they were willing to do. But only if I gave them admin access to the site.
That’s also, IMHO, ridiculous. Can you imagine having to do that for desktop or cellphone bugs? Many users — and every sysadmin I’ve ever met — would balk at such a request.
I initially offered to do what they requested…if they’d send me a contract signed by an officer of their company accepting liability for any damage or security breaches they caused, accidental or not. Needless to say, they declined my offer.
Ultimately, I ended up having to go through the trouble of setting up a dummy duplicate site which showcases the problem. Even with Duplicator Pro, command line access and a fair degree of familiarity with Linux that took some time. Multiply that effort across the entire WordPress ecosystem and the overall cost of the current debugging/diagnostic environment must be huge.
I’m not going to propose a specific “solution” here. For one thing, despite having used WordPress for years and having spent a fair bit of time mucking around with its configuration and source code files, I would never claim to be an expert on it. But, more importantly, I can imagine a whole bunch of different ways of addressing this issue. I’ll leave deciding which one is the best, or maybe least bad, one to pursue up to the experts.
But the ecosystem really needs something better than what it has.