Support

Um, that's totally not how it works. We don't install updates, WordPress does.

We do convey the latest available version information to WordPress by handling the filter pre_set_site_transient_update_plugins as you can see in our plugin's helpers/AkeebaBackupWP.php file in line 551. This is the standard way for implementing updates of custom plugins, as officially documented by WordPress developers: https://make.wordpress.org/core/2020/07/30/recommended-usage-of-the-updates-api-to-support-the-auto-updates-ui-for-plugins-and-themes-in-wordpress-5-5/

I suspect that you have accidentally enabled automatic updates for Akeeba Backup. This is managed by WordPress, not Akeeba Backup. I can't tell you how or why this happened. Maybe you have a "master site" with automatic updates accidentally turned on and you just copied over the accidental setting to other sites?

I can also tell you that before October 27th the automatic updates for Akeeba Backup were a bit iffy as our code was based on an earlier version of the aforementioned blog post. Unfortunately, the code sample in the earlier version of the blog post had a bug which was transferred to our plugin when we copied it, causing the control for automatic updates to only appear in the Plugins page when updates are available, i.e. you could only ever enable automatic updates for Akeeba Backup but never disable them (since they were installed automatically, making the control disappear again). This was fixed on October 27th 2022 and made it into the next release, Akeeba Backup for WordPress 7.7.4 which was released in November 2022.

Now, here's the thing. Automatic updates do not use WP-CRON. They rely on a transient. "Transients" are WordPress configuration settings with a set expiration time. When the transient expires, WordPress runs the hooks and filters necessary to populate them afresh. If a plugin update is discovered when the transient is rebuilt, WordPress will install it if automatic updates are enabled for this plugin.

To disable WordPress' automatic updates for plugins you need to add

add_filter( 'auto_update_plugin', '__return_false' );

to your wp-config.php file. It is a very non-obvious way to do it and I have to admit I had to search for it myself because I couldn't remember it off the top of my head (I just remembered there was a very non-obvious way to do it).

Alternatively, you can disable automatic updates for Akeeba Backup through the Plugins page of each site.

Since you have 200 sites I think it's easier to write a script to update the wp-config.php than going through the backend of all 200 sites, especially since you absolutely NOT want to have automatic plugin updates in your sites, as you very strongly implied in your ticket.

I hope this helps!

Considering that we just released new versions less than 48 hours ago it does make sense that you only saw our plugin being updated on so many sites.

You are right that the automatic plugin updates use a WP-CRON schedule. My bad. I got confused with the updates transient which I will discuss below.

It does sound, though, like you are using the wrong way to schedule automatic updates, by disabling around with WP-CRON. You should never do that! WP-CRON is necessary for automatic maintenance tasks in WordPress core, and third party plugins. Moreover, just disabling the built-in WP-CRON trigger does not remove the scheduled events, only the runtime trigger. If there's a  wp_update_plugins event scheduled it might execute e.g. if a third party plugin, your theme, or a CLI command trigger the WP-CRON scheduler.

The correct way is to disable automatic updates and only trigger updates with a CRON jobs, using WP-CLI.

But I'm getting ahead of myself.

You can see that WordPress does schedule the plugins update on your site. On an affected site use WP-CLI to check when it's scheduled to execute with

wp cron event list | grep wp_update_plugins

I am assuming that WP-CLI can be executed with wp. On some servers this might be more something like /usr/bin/php80 ~/wpcli/wpcli.phar instead. If unsure, ask your host. I know how I've set up my Linux boxes, I can't tell you how your host has set up theirs :)

Anyway, the command above should reply with something like this:

wp_update_plugins       2023-03-10 12:59:15     41 minutes 22 seconds   12 hours

The date and time is when it's next scheduled to run. The following column is the next time it's scheduled to run relative to now. The final column is the frequency it executes.

If anything triggers WP-CRON after the next run time of this event, it will be executed and install updates.

Side note: WordPress only checks for plugin updates when the transient storing this information expires. I made the releases between 06:00 and 08:00 GMT. This would very likely be just a few hours after you ran an updates check, having updated everything that was pending an update. Most other plugins release between 14:00 and 20:00 GMT (continental US business hours, since most WP users are in the USA). Therefore the only update discovered, and installed, within the half day between your automatic updates and WordPress' transient expiration would be our updates. We can't release updates later than 10:00 GMT because the end of our working day (7pm local) is between 16:00 GMT (summer) and 17:00 GMT (winter). We always need to have a buffer of 6 hours between releasing and the end of our day so that if something important breaks we can fix it without either of us having to stay up all night.

If you want to only install updates whenever you want them to install you need to disable automatic plugin updates and use a CRON job with WP-CLI. The command to execute is

wp plugin update --all

Note that, very much counter-intuitively, this command does NOT use the automatic update flag for plugins. It is completely independent from it. It's the CLI equivalent of going into wp-admin, going to Updates, Plugins, checking all the boxes, and clicking on Update. In other words, it checks each plugin for available updates; if there is an update available, it will install it.

Let me show you on my test site where I have deliberately installed an older version of Admin Tools for WordPress so I can demonstrate the update methodology.

$ wp plugin auto-updates status --all

+----------------+----------+
| name           | status   |
+----------------+----------+
| admintoolswp   | disabled |
| akeebabackupwp | disabled |
| akismet        | enabled  |
| hello-dolly    | disabled |
| query-monitor  | enabled  |
+----------------+----------+

$ wp plugin status admintoolswp

Plugin admintoolswp details:
    Name: Admin Tools Core for WordPress
    Status: Active
    Version: 1.5.8 (Update available)
    Author: Akeeba Ltd
    Description: The complete security solution for WordPress

$ wp plugin update --all

[...information about enabling maintenance mode...]

+--------------+-------------+-------------+---------+
| name         | old_version | new_version | status  |
+--------------+-------------+-------------+---------+
| admintoolswp | 1.5.8       | 1.6.0       | Updated |
+--------------+-------------+-------------+---------+
Success: Updated 1 of 1 plugins.

So, as you can see, even though the plugin is set up to NOT be automatically updated by WordPress itself whenever WordPress pleases, it will update "automatically" when the CRON daemon runs the wp plugin update --all command. No fuss, no misfires, no headaches.

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

See #6.

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

It does.

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.