See, this is exactly why I've been saying for years that automatic updates are bad unless the user can control whether they happen, what they happen on, and when they happen. Brian Teeman has also been saying the same thing, without putting so much stress on the qualifier, on the (correct) assumption that the casual user won't know where to look to control these updates with the immediate effect that the user is ambushed, confused, frustrated, and end up barking the wrong tree.
I think WordPress is the proof of the validity of these statements.
I disagree about Joomla and Elementor. Joomla 4's interface isn't bad, it's different to Joomla 3 and more like WordPress. Do not conflate familiarity with quality. The Joomla 3 interface was based on the top menu, a UI design dating back to the 1960s. It was not very usable on touch devices such as big tablets and touchscreen laptops. Moreover, Joomla 4 is more logically organised EXCEPT the System page — which will change, if not on Joomla 5.0 then definitely throughout the Joomla 5 lifetime.
As for Elementor and all page builders in general: they are the same as visual site builder services (WiX, SquareSpace, …), or visual page builders (DreamWeaver), or if you're an aging greybeard like me RAD tools (think Visual Basic). I've seen all those tools in all of their incarnations and they all suffer from the same problem: they make it really hard to re-theme the site / application as you need to rework all content / views. This leads to "throw away and start over". In the context of sites this can be detrimental to SEO ranking and more convoluted solutions being invented to work around this problem. I'm already seeing the early adopters struggling with that.
I am not being a dick about it, it's something we had discussed in one of the early Joomla 4 Working Group meetings. I do understand the appeal of site builders and, heck, even I would be tempted to use one if I were to make a new site with content I know won't be needed forevermore. For example, if I were to redo our site I might use a page builder for the Products section and the home page instead of my much more complicated solution. There are plenty of site builders for Joomla such as SP Page Builder, YooTheme Page Builder etc. The caveat is that I know exactly what I'd be walking into, the drawbacks in performance, and how to work around both. I'm not sure most people using Elementor do, and they've locked themselves into a SaaS which requires a yearly rent to let them maintain their content (something which is not the case in Joomla).
If you have any influence in WP circles, I'd suggest you ask them to:
I do not, unfortunately. I am always seen as “that Joomla guy” which is why I stopped attending WordPress conferences. The only exception was the AWESOME Greek WordPress community which is the only WordPress community I've seen which was willing to deal with me without any prejudice. They were happy for me giving it a go to write a block plugin when Gutenberg was fresh out the door and give them feedback on the sodden state of its documentation.
1. Work off server time, not GMT, for everything, that's the point in servers having their own times. Also with date and time formats.
Real world use case: the server is in the US East Coast (EST, GMT-5), the administrator lives in California (PST, GMT-8), and the systems operator is in Mumbai (GMT+5:30). It gets worse. US and Canada change their clocks 2 weeks before anyone else. Right now US is in Daylights Savings Time but the rest of the world is not. Right now the timezones are US East Coast GMT-4, California GMT-7, and Mumbai still GMT+5:30. Welcome to Timezone Hell!
This is why the UTC was invented. Everything is expressed in UTC to avoid misinterpretations. The reason WP-CLI replies in UTC instead of your "local" timezone is that it cannot possibly know what exactly should be your "local" timezone. At best, it knows the server's timezone. But are you really in the same timezone as your server? It's very unlikely for most sites. So, UTC/GMT it is.
2. Don't do updates when someone accesses a website - most idiotic system from any point of view you can think of
The real problem is that updates can happen at any point in time, even during your site's "busy" hours. This can introduce inconsistencies for a user caught in the middle of an automatic update, which is why updates should only be applied at pre-vetted windows where the site operator knows their site isn't going to be busy and the number of affected visitors will be as close to 0 as possible.
3. Disabled updates = disabled updates
While this does happen, but disabling updates is insanely counter-intuitive as it requires a. knowing that this requires setting some constant; b. finding which constant in a number of non-obvious documentation pages; and c. editing the wp-config.php file to set these constants. I would totally go with a few settings in Options, Updates. But that's not The One True WordPress Way :(
Or, you have to install yet another plugin such as https://wordpress.com/plugins/disable-auto-updates. This should be part of WordPress, not a plugin. See #4.
4. Auto updates = auto updates at a scheduled time
It's already possible…
…if you use real CRON jobs and WP-CLI. Which is not possible on all sites, notably not on managed sites.
That's The One True WordPress Way. Unfortunately, the biggest drawback of WordPress is that it FORCES you to change how you work, and many times modify your use case, instead of allowing you to do things your way. This is maddening, but it's ingrained to the mentality of the CMS.
And yeah, I fully agree with you that automatic updates should have a window, regardless of the trigger method.
5. Scheduler - this is where they may have to use the "when someone accesses the website" option, as not everyone will have access to CRON, but need to have a CRON only option
Remember what I said about non-obvious documentation? Here it is: https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/
6. Scheduled Window - eg. between 11am and 7am local time, "when someone accesses the website" option, but need to have a CRON only option
See #4 about scheduling.
As for the "when someone accesses the website", it actually cannot happen for objective technical reasons. At best, you could measure the number of visits but you cannot predict the future, i.e. if someone will visit your site after you start the update. WordPress has a different workaround for that which actually makes sense. It disables access to the site while an update is in progress. This is the most realistic way to implement it.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!