> I know that when it goes wrong it is usually when there are multiple updates to perform.
This is actually a very important hint.
There are two ways for download IDs to work in extensions. One is having it in the #__update_sites table, the other is through plugins in the installation folder. The latter is a finicky solution and it is perfectly possible that one plugin gets in the way of another (or in the way of Joomla's built in download ID management with #__update_sites records). When you are updating multiple extensions at once it's possible that an installation plugin overrides the download ID in our downloads, hence the problem.
I had said that this would happen when I saw how the installation plugins were meant to work. Unfortunately, understanding the problem requires having experience troubleshooting this kind of issues, experience in mass distributed software, talking to users like you and being able to think what takes place beyond the code's happy path. I have never seen a core maintainer having all these traits, maybe 2 of these at most. Nor do I expect any maintainer to have these traits because they are incompatible with having the time to be a core maintainer in the first place. What I am trying to do for years is have core maintainers acknowledge that they can't know everything, nor should we expect them to, they need to ask 3PDs who've proven their mettle with core contributions for advice or help. This is changing, however slowly.
Anyway, a moot point now that Joomla 4 exposes the #__update_sites Download Key records in the user interface, rendering the installation plugins obsolete.
> Enabling the plugin is then not enough. I always have to reinstall akeeba, after which the issue is resolved.
This is troubling for two reasons.
First of all, if you are not disabling the plugin and we are not disabling the plugin, who does?
The second and most concerning problem is that enabling doesn't do anything... so you're telling me that its files have been deleted? Do check the folder plugins/system/backuponupdate next time. Is the backuponupdate.php file deleted? If so, you didn't delete it, we didn't delete it, who did?
Do you see why reading this I am very worried? The best case scenario is an extension you use or the host you use is doing something stupid.
> This is a support ticket system and not a bug reporting system.
It is both, by definition. We discover bugs in the course of providing support. Many times what we report as a bug is a limitation we had hit and hadn't found a good way around it at the time. The last several months these are the bulk of the "bugs" I am fixing.
Sure, we have a bug report option in our contact form. 99.5% of the submissions there are users being confused about what they are doing or their host doing something wrong i.e. not a bug. We don't expect to get real bug reports there. We expect users to complain about bogus bugs and we'll point them to the documentation they need to read to understand why it's not and what to do to fix it. It's a public relations tool, not a development one :)
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!