[dubcanada]

> Composer support is absolutely fine and there are well maintained ways of keeping plugins and themes under Composer and have been for many years.

You need to use a third party service or setup.

> Yes, but adding further content types at the level of code or these plugins is easy, trivially so.

Compared to what? Drupal? CraftCMS? Joomla? Where you go to a UI and do it all, versus installing a plugin with it's own quirks or using functions.php which ends up being the last place you want to touch after your done?

> It has several caches that are very powerful indeed, including those included by default. PHP is a theming engine.

No it doesn't, you need a plugin like W3 Total Cache. On their Cache page they tell you to use a plugin. https://wordpress.org/support/article/optimization-caching/

The other caching setups Opcache, Varnish are either integrated in PHP or a completely different service.

PHP is not a theming engine. Blade, twig, etc are theming engines.

> I mean, people use it to run newspapers, so not sure if this is true. It depends what you need.

Newspapers are glorified blogs, so yes that makes sense that they run on WordPress.

But the problem isn't random sites use WordPress, the problem is people build weird monstrosities on top of a really garbage system.

[conatus]

Fair enough. Probably at "agree to disagree" here.

I'll agree that its easier to do custom post types on other CMS. But sometimes at the cost of real overheads in terms of complexity for users to swallow to get there.

Caching is built into the core, which is what all caching plugins leverage, the interface to it is hidden.

PHP is a theming engine.

I've never got why people escape into Blade, Twig or so on. PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML. It has an alternative syntax to make this easier. It's one of the unique capabilities the language has over almost all other languages you'd use on the web. More often than not you end up escaping into pure PHP in any case in something like Blade.

> But the problem isn't random sites use WordPress, the problem is people build weird monstrosities on top of a really garbage system.

Don't think its garbage for the reasons explained, but I think this true of all software projects. Seen plennty of Drupal, Laravel or Joomla projects end in this state.

[lemonberry]

I've been learning Laravel and Statamic this year. Both are a joy to use. I've been building WP sites for about 7 years. My goal is to never build another WP site again. Gutenberg is just one reason why.

I think one thing that's missing from the templating engine argument is WordPress' data model. While PHP may be a templating language WP's API to access data is a huge pain. A great example is wp_nav_menu. To modify it in any meaningful way you have to use the Walker Class. Seriously? It's an array. If WP's data model were better you could definitely 'foreach' your way through that thing... but you can't.

Antlers has a shorthand syntax to cycle through its navigation type. Laravel doesn't have a native navigation type but when I set one up it's pointing to table of pages. At this point I can use Blade to go through that table and pull out the appropriate title and url.

Why is this nice? No more "#" for placeholder menu items. More control over the Aria roles, etc.

This is just one win, in my experience, of using Laravel/Statamic.

Edit: for grammar

[conatus]

Massive fan of Laravel. If the relationship between Statamic and Laravel is similar to that between Wagtail and Python, plus the static storage, it seems like it would be very good indeed.

[lemonberry]

I don't know anything about Wagtail or Python so I can't speak to the comparison. However, I chose Statamic because it's a Laravel package and can be extended via Laravel. That adds a lot of flexibility to it. From what I understand Livewire is also compatible with Statamic.

[seanwilson]

> I've never got why people escape into Blade, Twig or so on. PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML.

Compare a Twig theme with a PHP based one. The former is much cleaner because views and controllers are separated, there's clean ways to reuse views, and the syntax is cleaner and more concise for common operations. The standard PHP approach in WordPress gets messy really quickly.

Related, but I can't believe how much responsibility WordPress theme writers have to manually make sure echoed strings are escaped properly (Twig has the same problem because it would be fighting against WordPress otherwise).

[LordAtlas]

Mate, Wordpress does not even have a way to manage your images without using a plugin. People using Wordpress to run newspapers and magazine sites have to use a hacked together solution involving either more plugins or writing custom code. As someone who's had to run a magazine site with Wordpress, I can painfully recall all the issues I've faced and cursed the dev team.

When you have a few hundred images (and that's just for a small site, let alone newspapers), do you really think having just a dropdown with media type and month for a filter (out of the box) suffices? Asset management is a core feature for any large-scale media outlet CMS.

[conatus]

You probably understand these points better than I do!

I just don't think it is truly as bad as has been made out by the initial comment.

[tannhaeuser]

> PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML. [...] one of the unique capabilities the language has

Totally agree, but unfortunately PHP's integration within a markup processor is quick and dirty, without consideration for context-dependent escaping and quoting etc. hence continues to give rise to a large number of HTML injection attacks.

[conatus]

This is true. I understand other languages (for example Go) have very nice features of this kind - contextual auto-escaping and so on. However a lot of other languages also have these footguns around escaping and security.