Support

It's called a Download ID, not a license code. Unlike a license code, the Download ID is actually a user identifier i.e. it tells our downloads server who is the user account who tries to download the file. If there is a valid subscription for the product on the user account corresponding to the Download ID the download is authorised.

Likewise, the Download ID is sent to our server when you are using certain upload methods which require our server to act as an intermediary to authenticate yourself to the remote server (e.g. Dropbox, OneDrive, Google Drive or Box). Just like before we check if the Download ID corresponds to a user account which has an active subscription to that product. If it does, we allow the authentication to proceed and your backup can then be uploaded by your server to the remote storage.

Therefore you can use whichever valid Download ID you like, yours or someone else's (provided you have their permission to do so) and even switch between the two anytime you want. 

There is only one little snag. If Joomla has already determined there is an update to our software available but you have not entered a Download ID or the Download ID entered is invalid and you then enter a valid Download ID it may take up to 48 hours before Joomla can let you perform the update. This is due to the way Joomla caches the update information.

We do try to think of everything and find ways to do what we haven't thought of already, indeed. As long as it's technically feasible and doesn't cause problems for more people than it'd help we will implement it. The difficult part is knowing what's technically feasible and the impact of any change but, hey, 15 years of developing this software and another 10 before that doing all sorts of consultancy (including my two year stint as a business consultant) and user support certainly do come in handy :)

I will go on a bit of a tangent about naming things because it's one of the three hard problems to solve in computing, the other being off-by-one errors (see what I did there?).

The term “Download ID” dates back to 2010 when it was only used to identify the user when they were downloading an update through Akeeba Live Update. It has never been a license key. The license of the software is GPLv3 and you can use the software itself without entering a Download ID. The Download ID is only used when you need to authenticate yourself to our server. It's more like an “Authentication Code” but naming it like that is even more confusing. Calling it a Download ID makes it easier for people to understand its primary purpose, giving you access to downloading updates.

When some third party services started using OAuth2 it made sense to use the same user identifier to control access to out authentication mediation service instead of creating a jarring and confusing user experience by either introducing yet another user identifier or changing the name of the Download ID. You have to also keep in mind that at any given time we may still have users on 5 to 8 year old software versions. Changing something in version X confuses people using earlier versions.

This brings me to the tangent. Remember that terms tend to have origins related to their original use, not their contemporary use. For example, the term “bug” in the context of computers has its origins to a literal bug (an electrocuted moth) stuck to a relay in a Harvard computer in 1947. Likewise you car's trunk doesn't hold a literal trunk and the hood is most definitely not a literal leather hood covering the engine compartment (which, by the way, no longer holds just the engine of the car, nor is it a compartment per se). By comparison, I believe that the origins of the term “Download ID” in our software are rather mundane and have definitely nothing to do with my native language. For what it's worth, I got my Certificate of Proficiency in English at the age of 16, I am almost 41 and married to an American. Between that, my work and the pandemic turning us all borderline hermits I seldom speak Greek anymore. You could pick me up and drop me in a city in the US and the only thing that I'd find truly alien would be turning right on a red light (outside North America you get flashing yellow arrows to explicitly allow that; you don't turn right on a red light).

Back to your question about Amazon S3. I definitely understand your reaction but it's overly pessimistic. You do not need to learn everything about Amazon Web Services to use S3. Amazon S3 is one of their most approachable services. Still, you have to figure out buckets and regions at the very least. It could be worse, e.g. the ungodly mess that's Azure.

An easier, cheaper alternative is BackBlaze B2. You may want to look it up.

Please, never retire or sell out.

I can't retire before 64 years old and I don't intend to sell out; I'd be so bored! You'll have to endure me for another 23 years and change at the very least :)

I knew you were joking, hence the semi-pompous tone :p I also love etymology, I couldn't pass on the tangent.

Regarding B2, did the archive upload? If not, try doing that from the Manage Backups page. I have a feeling that the B2 API randomly throws errors some times. We definitely do sent the Content-Length header.

Regarding my age, I became a business consultant at the age of 24. I had the chance to become a project manager at the age of 26. My first project was supposed to be a lost cause. I got them results that even the client, paying our fees, didn't expect to see. I'm sure you can see a pattern starting to form :p

The option to copy Kickstart is so that you can clone a site without having to transfer files through your device. If you are on a mobile phone or tablet (or on a very slow or expensive connection, think about roaming abroad) you don't want to download the backup archive and then upload it to the new server together with Kickstart. You can simply use the Upload to Remote FTP / SFTP post-processing engine and check the option to transfer Kickstart. Once the backup completes you're ready for action! Note that this is the reason why this option is disabled by default.

Kickstart Core is uploaded, not Professional. The Professional version's only difference is that it can import backups from a URL or from Amazon S3. You clearly don't need that when you are uploading Kickstart to a different server along with the backup archive since, well, you have already uploaded the backup archive!

The other way to go about it is use the DirectFTP / DirectSFTP. In this case you are not creating a backup archive, you are transferring each individual file to the remote file instead of putting it in a backup archive. This could, indeed, take days to complete. That's what you read. Totally different use case.

The documentation is most definitely updated.

SiteGround has long stopped being Joomla's recommended host or anybody's recommended host for that matter. SiteGround used to be the joomla.com (now called launch.joomla.org) operator. Since nearly two years ago this is operated by CloudAccess.net. I speculate that they underestimated the amount of support they'd need to be doing for that hosting gig and overestimated how much money they would rake in from people converting to a paid hosting plan. Towards the end of their contract term with Joomla they started bad-mouthing Joomla in various events and treat Joomla as a second-class citizen or worse in their hosting environment. Their current hosting environment, launched last year, is only viable as WordPress hosting as you said and even as such it's extremely overpriced and decidedly underwhelming, not to mention full of issues.

We moved our site out of SiteGround and back to Rochen last September. Having our site down for a day without any explanation forthcoming and zero communication during the incident wasn't exactly confidence inspiring. We are a team of two. If there's an issue we communicate while we are working. Surely a hosting company with a few dozen engineers and just as many marketers can bloody communicate when there's a major outage. Too much to ask? Okay then, off we go to a host that checks these boxes.

That said, the B2 issue is not something we've only ever seen on SiteGround. We have seen it on other hosts, too. It happens so sporadically that we can't find a common thread. Our code does send the header that's supposedly missing. Whether there's something at the host's side or the B2 side is something we simply cannot know. We have no visibility in what each host does.

You're welcome and have a great day :)