I guess that WP wants to become "one to rule them all". This means that they strive for even bigger adoption rate among users. FSE is the direction of that. I can totally understand that professional developers are feeling frustrated with the way things are going in WP ecosystem.

When Gutenberg was introduced it produced more pain that good things that it has brought at that time. A lot o money is floating around WP and investors want to get their share of the cake. Did you notice all of the investments in WP or plugins that have changed their owners?

Agreed, if you have a dedicated engineering team, but most non-tech companies that need basic websites don't...so in that context, Wordpress's admin UI is a big gain. It's familiar to users and provides media management functionality out of the box. The vast majority of CMSs have terrible/non-intuitive admin UIs and limited functionality. Leaving aside Gutenberg and the rest of the garbage pile that is Wordpress, the admin is the primary selling point of Wordpress IMO.

Things like copy/paste from Google docs with keeping all of relevant the styles and links works. And I guess that a bunch of users is doing that - using WP as a platform for distribution of content.

Having a classic editor plugin has nothing to do with characterizing people as crufty throwbacks who can't learn new things. Many people are in the business of their business and don't care to learn the next new-greatest-software every few months.

Especially when you add custom blocks specific to their site needs

Take a look at WooCommerce. I guess that it is much easier to do some of the custom code than to reinvent a wheel. Not to mention learning users on how to do something in a totally different environment.

The designer can, within the structure and strictures of Wordpress, build a site with all the whizzy things the client wants, and they can charge $X for it. A developer can do all of that as well, but they will probably need a designer as well (see above parenthetical), and it will cost $X * 2.

The counter to that is, "well, just build a good templating system and tweak that for other clients, and you're good." Which is true, and that's why there are lone PHP developers out there who make a decent living with a stable of clients.

One of the worst aspects of Wordpress is dealing with the infuriating and opaque reasons why a particular site is slow. A relatively simple site can be maddeningly slow for any number of reasons, and finding them is like searching for a contact lens in a full bathtub.

If performance is a real business concern (and when is it not?), hire developers, not designers.

Hire developers, not WordPress developers. Because the latter will push WP onto a project where clearly the downsides, like performance, outweigh the benefits. But the latter may pick WP when it is a good fit.

I mean, I get it. I've written some stuff that screws the pooch performance-wise, and the solution isn't immediately clear. But with WP, and with enough installed plug-ins, the reason for the slowness may simply be "in order to work with WP, there is a lot of back-and-forth with the DB amongst all these plug-ins," and there ultimately isn't anything you can do about it.

WP is amazing that it does so much and works as well as it does, but let's not pretend it's not a bit of a faff sometimes.

Here's a question: suppose that you want to use WordPress as a starting point for a CRUD app with some basic permission controls, the ability to dynamically add content and maybe even write your own search logic which respects those permissions.

Example:

  1. Upon opening your site, you'll be presented with a list of Foos
  2. Each Foo will have a description, a configurable amount of maximum Bars, and a summary of how many Bar instances have already been added, as well a location on a map below the list (a pin, think Leaflet.js)
  3. Upon logging in to the site, you'll be able to open each Foo and see all of the Bars under it
  4. In this list you can click on a Bar to open its view, which shows all of the data added it: typical stuff like text, numbers, dates, times etc.
  5. With the appropriate permissions, you can either edit the Foos/Bars that you have access to, or edit all of them as an admin. As a user, you can only view them.

How would you go about that? Are there any resources that you would recommend?

For example, if one were to use Slim, they'd look at their documentation: https://www.slimframework.com/docs/v3/

Similarly, Laravel has pretty decent documentation for developers: https://laravel.com/docs/8.x

Whereas with WordPress, i don't think that there is such an informative, guided resource for implementing things like that: https://wordpress.org/support/

A lot of it seems to focus on how to maintain installs of WordPress or how to work with its built in concepts (like pages/posts/etc.), but there's nothing along the lines: "Here's how you're supported to mess around with its internals in an idiomatic way and introduce custom views, validations, persist the data in the DB and add whatever you need to cover what constitutes a business process". Maybe i haven't dug inside of it enough.

Are you just supposed to hack things together with a custom theme or custom widgets, custom post types and storing most of the information into custom fields that are attached to the post? Why does the documentation have such a lack of PHP in it, then? Is there a separate set of developer docs somewhere?

Actually, i wonder if there's some super lightweight boilerplate theme, that attempts to do almost no styling and has very basic layouts, to be used as a boilerplace, e.g. what the likes of Skeleton are for CSS: http://getskeleton.com/

Slim and Laravel are both proper application frameworks specifically designed for your use case. That's why they properly document all of the CRUD use cases. However, they don't do CMS stuff at all.

If you absolutely need a working CRUD app to live inside of a CMS, then your best bet would actually be a Drupal module with a custom entity type. However, that requires you to actually know the ins and outs of Drupal's Entity and Field APIs, which are rather overengineered[0]. On the other hand, if you do manage to figure all that out, permissions are relatively easy to hook up, forms are just filling out an array, and you get Views support basically for free.

[0] In Drupal's defense, they're a CMS, so they need to support use cases like letting users define custom node types and custom fields on those types. This makes the interface for interacting with Entities way more complicated than an ordinary CRUD app needs.

This was also a sneaking suspicion of mine after diving into some plugins and seeing how they work, e.g. things that definitely aren't pages/posts beings stored in those tables in the database regardless, hinting that maybe the base functionality needs to be stretched out a bit for custom use cases.

We're working on switching to wordpress for the volunteer organization I work at. Right now all the "information/kinda static" content is on wordpress with pages and posts. Its a win, anyone with permission can edit. Our custom application isn't there and has its own separate database and code. We're thinking of moving the whole thing into a sort of plugin, but we're very symphony based.. Which we like

This is a nice approach - getting to leverage WordPress for the typical use case at which it is good, using something bespoke for the more advanced use cases. I've actually done something a bit similar in the past (the particular app i made used Lumen which is essentially stripped down Laravel, but the concept was close enough).

It's just that many made WordPress seem like a pretty much universal tool and while i've seen some pretty advanced things be done with plugins, i personally didn't quite feel like it's well suited for certain tasks where you'd typically reach for a general purpose web framework instead.

The PHP side of WordPress has been very stable for over 5 years at this point. All the new stuff is happening in JS unfortunately...

When we picked WordPress back in ~2012 as our CMS it was because of how simple the editing of post/page content was compared to the alternatives. The majority of our content editors are student assistants, graduate assistants, least tenured faculty member, etc. People who aren't that technical and also have a dozen other things that are their actual job, unlike updating the departmental website which just got dumped on them.

We've done a ton of work with our theme and in-house plugins to keep WordPress super simple/basic for them, overwriting and undoing a lot of what core has added over the years. Most of the site editors find Gutenberg too complicated, so we're running the Classic Editor plugin in a ton of our sites. Our content editors just want to come to a CMS, have a text box where they can add content, add heading tags, links, images, use some of our shortcodes (from custom TinyMCE buttons) to add some styled components to their page. They don't want a full-site editor, they're not remotely qualified from a UI/accessibility perspective to be messing with anything really than just the base content of the page.

I think Wordpress needs something like better defaults. You are so dependent on picking a good theme and it seems really hard to tell what’s going on in the theme world.

The overhaul that came with Gutenberg was painful and it took almost two years to catch and fix all the bugs, for example with embedded videos. But as of 2022, I am happy with Gutenberg and it feels intuitive.

I know a few guys who could never make the necessary switch in their heads and hate Gutenberg with a fury of thousand suns, though. All of them are over fifty.

Now, Substack has even more intuitive and amateur-user-friendly editor, but a much more limited set of options.

Automattic could create a PluginV2 system with tightened security and new requirements for plugin developers, then put a plan in place to deprecate and remove support for v1.

[0] which were then massively refactored, twice.

They can't afford it, and most people don't want it. I think history shows that taking flexibility away from something popular because of its flexibility is not good business. At least you can install a plugin now and completely sidestep this awful 'site builder'. If that goes away, hoo boy.

PHP code is not sandboxable (ignoring the ability to disable functions), AFAIK. Is it? So plugins do have complete (read) access over the entire code, the secrets in the config files, the database etc.?

Not allowing plugins to directly execute PHP code would either fundamentally break the wordpress plugin model or require an interpreter for a turing-complete "wordpress plugin programming language", right? That would kill any performance, especially on uncached wordpress instanced, even on PHP 8, wouldn't it?

People said the same about JavaScript, and yet smart people figured out ways to do it. For example: https://github.com/googlearchive/caja

PHP may be particularly challenging to sandbox, but it's not too much for talented engineers to figure out.

As a near-last resort, a secure PHP subset language could be developed.

> WordPress is used by 65.3% of all the websites whose content management system we know. This is 43.3% of all websites. [1]

And these numbers have been growing for years. In other words, WordPress is and will be widely used for a long time. So I’m not sure WordPress really needs saving. :p The number of OSS contributors has also been growing. So the project itself hasn’t been stagnating either.

Disclaimer: I’ve been a WordPress contributor and work for Automattic.

1: https://w3techs.com/technologies/details/cm-wordpress

Is this something you came up with on the spot? I haven't come across this idea in communications literature and a cursory search only brings up other types of bundling in economics/business/strategy.