Support

Akeeba Backup for Joomla!

#29104 6.0.0b loading instead of 5.6.3

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by on Thursday, 08 March 2018 17:17 CST

palazzi
Please look at the bottom of this page (under Support Policy Summary) for our support policy summary, containing important information regarding our working hours and our support policy. Thank you!

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Description of my issue:

I saw another semi-related post so I am aware that 6.0.0b1 is really mainly a visual changeout and core-functionality is same as 5.6.3... however, it's still a beta. I am 100% set on all my sites to stable release only for update manager. However, doing site updates this week I found every single time that anything other than 5.6.3 on the site already, updated to 6.0.0b1 - even though, the actual component even states 'click to update to 5.6.3' making me mop up and manually install the correct one.

Please fix this - either call it a "release" and drop the beta connotation/numbering or fix your update server/cdn. I'm coping with it - but I'm sure lots of people out there are confused. This is for the pro version I subscribe to, btw, not sure what happens on the free one. No need for follow up - this is more an FYI for you. Keep making great products!!

Oh - and if I can make a request, bake in scheduling somehow. I know I can cron the command line, but a great visual interface would rock and be worthy of a 6.0 major release number.

nicholas
Akeeba Staff
Manager
You have hit a Joomla! bug. Akeeba Ltd does not publish Joomla. As a result there is nothing for us to fix. Please file a bug report with Joomla.

Akeeba Ltd is forced to use Joomla's built-in extensions updater. If we don't, the terms of service of the Joomla! Extensions Directory (JED) stipulate that our software will be unlisted from the Directory anywhere between 1 month to forever.

More specifically, the update to all our Joomla software is handled in whole by Joomla's built-in extensions updater which is a feature of the com_installer (a.k.a. "Extensions") component which is part of Joomla itself.

Akeeba Ltd only published the XML update stream on its CDN. The XML update stream correctly identified the 6.0.0.b1 version as a Beta. This is the only item in the update process under our control and it's correct. The XML Update Stream is public information. You are free to examine it and verify the accuracy of my claims.

Joomla will periodically download the XML update stream. The frequency of that check is determined by Extensions, Manage, Update, Options, Updates Caching (in hours) and how often you visit your site's administration backend. When Joomla determines this information is out of date it will fetch this XML file and parse it. The file has a list of all currently published versions of our software along with their stability level and Joomla compatibility. On each and every one of them Joomla will check that the current version of Joomla is supported and that the stability level of the available version is higher than the configured (Extensions, Manage, Update, Options, Minimum Stability) minimum stability level. If either of these checks fails the available version record is disregarded, i.e. it's as though it has never existed for all of Joomla's extensions updater intents and purposes. Then and only then it checks whether this version record is a more recent version than the one currently installed. If at the end of the process for all records there's a version newer than the currently installed found the update information is written to the #__updates database table which is used to render the information on the Extensions, Manage, Update page.

Please keep in mind that Joomla! may cache the update information for up to 24 hours. Therefore after changing this setting you must click on the Clear Cache and Find Updates buttons, in this order, to force Joomla! to refresh the update information. However, if you have turned on Cache in your site's Global Configuration you have to Clear Cache first, then click on System > Clear Cache from the top menu, then go back to Extensions, Manage, Update and click on Find Updates again. I know this is completely inane, but I was not the person who decided to design com_installer like that.

Finally note that I have tried the update steps with Joomla! 3.8.3 and 3.8.4 with Akeeba Backup 5.6.2 installed. When the Minimum Stability is set to Stable only 5.6.3 is reported and installed. After its installation no more updates are found. When the Minimum Stability is set to Beta then 6.0.0.b1 is reproted and installed. I would like to point out that not only I tried this process on testing and live sites (including our own live site where you filed this ticket and all of my personal sites) but I also tried this on three different development sites. On the development sites I stepped through the code to make sure that what happens is really what I described. It is. Our XML update stream marks the release as beta and Joomla DOES see it's a beta and DOES take it into account.

Therefore what you observe seems to be an old installation of Joomla, an installation of Joomla not properly upgraded to 3.8.4 (some files did not get written?), or a very weird bug affecting only some servers. In any case, there is nothing for us to fix since we are not publishing Joomla and we do not manage your site or your server. The only thing in the update process that's under our control (the CDN update stream) works perfectly. The downloads on our site OF COURSE work perfectly. God forbid we delivered random files!

So, back to your point. Yes, you're paying us so we can develop and maintain our own software and services. We do. Your problem is NOT with our software or services. It might be with Joomla, but my debugging sessions and my visits to affected sites tell me there's a near certainty that your issue is with the Minimum Stability setting, update caching or an outdated Joomla! version. In any case, it's nothing under our control so what exactly do you suggest we should "fix"? The CDN update stream which is already correct? The downloads which serve the correct files? Or people's sites which we didn't build nor configured? Please clarify what you have in mind.

In any case, you have no idea how much testing goes into a new version before releasing it. Our "beta" versions are actually stable. We only use the "beta" tag to entice people to put the new version through its paces, uncovering any small issues we might otherwise never hear about for months or years. We didn't expect that some Joomla installations would drop the ball despite us doing everything right.

So let me tell you what I'm going to do on Wednesday. I'm going to take the exact same code as 6.0.0.b1 with a minor visual tweak and release it as 6.0.0 Stable. I hope that makes everyone happy. The only reason I can't do this today is that I'm not at the office and my Internet connection here seems to drop randomly. Good enough for replying to tickets, bad enough to make releasing software a massive pain in the posterior.

Oh - and if I can make a request, bake in scheduling somehow. I know I can cron the command line, but a great visual interface would rock and be worthy of a 6.0 major release number.


You are thinking about the Lazy Scheduling Plugin we had back in 2011. Please do take a look at the very old documentation of the 3.4 release under section 5.4. I have listed 14 reasons why this won't work properly on a site. Items 4 and 6 have been mostly but not fully solved following the re-architecture of the backup engine in version 5 - there are still some ways they can cause a problem. The points 7, 11 and 13 are actually very significant and put the final nails to its coffin.

7. Use of a hidden IFrame. Since circa 2015 this is typical behavior of malware. Browsers and Internet security solutions (browser extensions or standalone applications) block or report it. Basically, your site will appear to be malicious.

11. Parallel run of the same backup step. This is something that cannot be avoided as the lock mechanism, be it database or filesystem, has a delay between write and read. The only way to work around that is adding a 1 second delay which means that your page load time increases by that much. 1 second delay was not a bug deal in 2011 with 10 second page load times but it's a massive deal in 2018 with 0.5 seconds page load times. More so when your site gets penalized by search engines for being slow to load.

13. System - Cache breaks the plugin. Since the scheduling plugin relies on outputting something to the browser only on SOME pages, page caching is incompatible with it.

The only solution to most of these issues is running the backup step before the page is rendered by the browser, in Joomla's onAfterInitialize event. This means that you will have page load times between 10 to 40 seconds, making your site unusable and increasing your bounce rate. At the same time, tying your backup to user visits (which tend to modify the filesystem and database data) is the best way to end up with issues upon restoration. So, if you ask me, this is a rather reckless -if not outright daft- way to go about scheduling backups. There's a reason there is CRON and there's a reason we tell you to use 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!

palazzi
Than you for testing and retesting - it is hugely appreciated! You mentioned a couple of things in there that may be helpful. I was going from 3.8.2 to 3.8.4 as well as updating the plugins. That combo is likely the cause. While I knew that J! is handling the update, I guessed that you had the wrong file pointed to in the XML itself. But the more likely case is that using 3.8.2 to use the current XML caused this. Definitely am set for stable, I checked every time this happened.

As for the why - it's the recommendation that all external features are updated first and then J! core.

In any case, no harm nor foul as I mentioned. Also thanks for the explanation on the scheduling. I never saw that stuff when it was published. Makes a lot of sense.

Have a good one!

nicholas
Akeeba Staff
Manager
Hm, that's interesting. Normally, updating Joomla should not have an effect on the extension updates unless there was a bug in the previous version of Joomla. I think it's possible that one of the Joomla core files which deal with updates has not been properly updated or otherwise had a bug reading the minimum stability setting, causing the problem.

Have a great day!

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!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!