The problem is that clients really want WP a lot. Bigger and bigger companies currently and for most of their departmental sites. This is WP shoe-horned in a full site CMS function. The thing is, users seem to love it. I would wager that if you just rip out the guts of PHP and leave only the frontend (the /wp-admin part that is), but leave it 100% as it is and write a solid backend in Django/Rails, you have a winner. The problem is that when people attempt this, their own 'taste' comes in and it always ends up being a vastly different frontend which then users don't want as it's not 'the same as WP'.

Before anyone says it; sure some users use WP for the themes and plugins; we use some of them but we are very careful using plugins. They have to be rocksolid for many years, actively supported and we have to have reviewed the code. Next to that they have to add something significant; installing a plugin for some social buttons is very much not worth the pain of updates / security breaches on a 100k+ (+ SLA) project. And so in the end we end up using 4-5 the same plugins for projects and the rest is either not needed or easy to implement anyway. So the hero implementing those guts in Django/Rails could also implement those plugins. I believe you would have something safe for the enterprise. Until then, they'll just use WP and trust admins/coders to fix the issues.

> I would wager that if you just rip out the guts of PHP and leave only the frontend (the /wp-admin part that is), but leave it 100% as it is and write a solid backend in Django/Rails, you have a winner.

I would love for WP to exist as only an admin interface to a clean, backend data store. Unfortunately, the problem is the database schema that WP ships with and the way WP handles data. It's almost impossible to get data out of WP press without using its lackluster DB "abstraction" layer and running the fetched data through its many obscure filtering mechanisms. To top it off, WP smashes everything into a handful of tables and makes doing normal, straightforward relational looks up (as any sane schema would allow for) a complete nightmare. Alas, when you go the WP route, your data is very much dependent on WP (and by default PHP).

Any organization that uses WP for an extended period of time and builds up a non-insignificant amount of data will run into this wall, guaranteed. If you truly value your data and your project is anything beyond a personal blog that you'll give up on in 6 months time, do yourself and your organization a favor and find an alternative solution. If you must use WP, use it as what it was originally intended for: a blog. It's not a framework to develop a complex application off of.

As the person who wrote a patch to import data from WP to Pelican I agree. It's a complete nightmare. In order to properly maintain the formatting from ~6 years of blog posts I had to literally translate the PHP code that parsed the database representation into Python... which is some really gnarly code.

Have you looked at/heard about the WP REST API[1]? Basically, it allows WP to function as that backend admin tool that you talked about, and you can build the front end as what ever you want[2].

[1] http://v2.wp-api.org/

[2] An example of a front end powered by the WP REST API https://github.com/ustwo/ustwo.com-frontend

I agree with everything you said here but I can explain this to clients usually however not always. There is, for instance, a supermarket chain running all their web through WP. They spent and spend millions on it; they cannot be convinced and although I might not choose a certain tech for my own company assets, I am not spreading religion (although as I get older I feel more and more the need to do so) and we are not in the position to just say no to large contracts.

> The problem is that clients really want WP a lot.

This. I can waste my breath talking about another CMS which is better suited for the task, has cleaner data representation (good for 5 years' time) etc, and try to get stakeholders to buy into it. Or I can mention WordPress and have brand recognition do the work for me.

> The thing is, users seem to love it.

In my experience, the users find the admin confusing. It's the managers and above who love it. They know what they're getting and it feels safe.

It used to be "You're never fired for buying IBM". Now it's "You're never fired for buying WordPress".

> In my experience, the users find the admin confusing.

My 'entry' into the enterprise world was web CMSs; my previous company used to make/sell a respected web CMS. If you talk about 'confusing admins' then the web CMS world is where you should look. Boot up a Liferay (oh and check out that code by the way) or Alfresco or Sitecore or Oracle CMS and stare in disbelief.

This is what these users are used to and compared with those, WP is really very simple. That's why no (?) enterprise will replace an international corporate roll-out with WP, but regional, if allowed (and it usually is as marketing simply doesn't work the same way worldwide), they will. Because of the ease and less friction; create a new content writer? Fill in paper work and ask the main IT dep vs do it yourself in 5 seconds and that kind of thing.

What's your list of preferred WordPress plugins?

"old" PHP code should not be finding it's way into your project. Use a facade, adapter, proxy or bridge pattern to decouple your new shiny awesome code from the legacy cruft.