Support

It's either an issue with the Live Site you chose during restoration or a hosting issue. I remember fixing a related issue in Joomla itself back in September. I will, however, need direct access to the site to determine what is the problem.

I have made this ticket private so that only you and me can see the information posted here.

Please provide me with the following information:

1. The URL to your site's administrator login page
2. Super User username and password
3. FTP connection information

Please allow up to one business day (GMT+2 timezone) for me to log in to your site and debug this issue. When I'm done I will post back. Once the issue is fixed, you can revoke my access e.g. by changing the Super Administrator and FTP passwords.

IMPORTANT INFORMATION
In order for me to help you fast and accurately, please provide the information by copying the form below, paste it into your reply and fill in the information:

----- Access Information Form -- START -----
Super Administrator access

• URL to site's administrator page (e.g. http://www.example.com/administrator?foobar):
• Super User username:
• Super User password:

FTP connection information

• FTP methods supported (e.g. FTP, FTPS, SFTP):
• FTP Hostname:
• FTP Username:
• FTP Password:
• FTP Port (if other than 21 for FTP and 22 for SFTP, ask your host):

----- Access Information Form -- END -----

Please make sure that you have tested the Super Administrator connection using a different browser or machine than the one you are using daily. Double check that logging in is possible and that the user has Super User privileges, i.e. it's not a regular Administrator. Make sure that your site does not block whole countries or IP ranges which would make it impossible for me to log in / connect by FTP. Finally, please do make sure that the FTP connection works and that logging in to it I have access to your site's files.

Kindly note that your site connection information and your site content is handled in strict confidence. Not only we are a reputable development company, we are also bound by law (EU GDPR) to do so. After you file your reply, the connection information to your site will be stored in an encrypted, hidden storage area on our site and will be automatically deleted when this ticket is closed. Finally keep in mind that the people providing support to you are the same developers who wrote the software you're using on your site.

Your Live Site, i.e. the URL you are telling Joomla is the canonical URL to your site, was set to http://www.micomp.ca. However, a. this is not your site's URL and b. you don't need to set it (it can be blank on the vast majority of sites). I fixed that manually. When restoring a site you can do that yourself in the Site Setup page, see the Live Site text box,

The other problem is that you need to access your site's administrator as http://www.ve3rmi.org/administrator/index.php (note the www. part). This is not standard Joomla behaviour. Neither is loading third party JavaScript from events.api.secureserver.net. I believe that your host is doing something wonky which breaks your site. Unfortunately, this not something I can help you with.

Executive summary

You are not getting a refund because your issue has to do with how your server is configured, how Joomla works, and what you did during the restoration.

When restoring a site, as soon as you reach the Site Setup page --the penultimate page of the restoration-- take a look at the Live Site.

Normally, the Live Site needs to be empty.

However, because of your host's misconfiguration of their web server you must set it to the URL of the site you are restoring to, exactly as you will be accessing it. In this site's case, http://ve3rmi.org (note that it does NOT have the www. subdomain!)

Seeing that your issue has nothing to do with the way our software works (it would happen all the same if you manually transferred your site) and there is a very simple to address your server's misconfiguration by using the documented restoration interface you are not entitled to a refund as per our Terms of Service.

The gory, technical details

Before I start, a few words about me and the way I approach technical support. You are talking to the lead developer of Akeeba Backup, someone who has been developing software for Joomla since it was called Mambo back in 2004. I am also a systems engineer, managing my own servers. Furthermore, I have written large parts of Joomla itself, including the feature you have had a problem with. You are not talking to some random outsourced support guy. I take pride in honesty and technical accuracy. If the problem was with our software I would have told you so, given you the exact timeframe to fix it, and offered a refund if it would take more than 2 working days as per our Terms of Service. It would not have been the first time I did that. Finally, when replying to support tickets I try to give just the pertinent information instead of going into a full technical analysis. I was doing the latter in the past and I've been told it sounds patronising. Clearly, with tickets like yours being far from rare, I still need to give the full technical analysis. Oh, well, live and learn.

The problem you experience is that the quick icons try to make an XMLHttpRequest (a.k.a. "AJAX request") to the wrong domain name, www.ve3rmi.org instead of ve3rmi.org. This does not have to do with the way our software works. It has to do with the way Joomla detects the hostname the site runs under and a server misconfiguration.

Joomla doesn't guess or magically divine the hostname it is being accessed from. Assuming that the $live_site line in configuration.php is empty, Joomla looks at the $_SERVER['HOST'] superglobal which contains the environment variable $HOST set by the Apache web server. This is how Joomla has worked since it was called Mambo, two years before Joomla 1.0 was released in 2005. Normally, Apache uses the $HOST environment variable to relay the contents of the HTTP Host header which is sent by the browser and contains the fully qualified domain name (FQDN) of the site being accessed. If you access the site as http://ve3rmi.org this contains the string literal ve3rmi.org. If you access the site as http://www.ve3rmi.org then this contains the string literal www.ve3rmi.org. Basically, the browser tells the web server which tells the operating system which tells PHP which tells Joomla what the host name of your site is. I know it sounds ass backwards, but there are very good reasons this happens. Among other things, this is why Joomla can work with and without TLS (HTTPS), with and without the www subdomain, and even keeps working when you change your site's domain name.

The real problem here is that your host has set up Apache in a way so that the $HOST environment variable does NOT relay the actual HTTP Host header. It is forcibly set to www.ve3rmi.org even when you access your site as ve3rmi.org (without the www subdomain name). Your host is doing this wrong! They are doing this to avoid a well-known exploit in Apache which has existed for well over 24 years, that sending an arbitrary HTTP Host header will result in the first configured vhost (site) of the Apache instance to handle the request, passing along the bogus hostname. This can be used for malicious redirects and phishing among other problems. Your host is following a wrong and misguided solution to this problem, forcibly setting the $HOST environment variable to www.ve3rmi.org. This would only ever work if you'd always access your site with the www subdomain, something you most definitely not want to do as it turns out. The correct solution, also known for the past 24 years, is to create a default vhost in Apache (first in order vhost and defined as *:80 and *:443) which simply returns an HTTP 403. I understand that your host tried to protect you from a security issue, but they are doing it in a wrong way which causes Joomla to break. WordPress, which requires the site's domain name to be hardcoded in literally thousands of places in the database, wouldn't break -- but it'd have other issues, let's not get into that because we'd go off in a tangent.

You might still wonder how this relates to the problem you have with Joomla. Luckily, the feature you have a problem with (Quick Icons) is one I contributed myself to Joomla in 2012 and reworked its JavaScript last September. Not to put too fine a point on it, you are talking to the one person in the world who knows this Joomla feature best, on account of being its developer! These icons need to do an XMLHttpRequest (a.k.a. "AJAX request") to URLs belonging to Joomla core components to get the status information. Each URL is constructed by the site's domain name and a known, invariable path. The site's domain name is provided by the Joomla\CMS\Uri\Uri class which extends Joomla\Uri\Uri which reads the site's domain name from the $HOST environment variable through PHP's $_SERVER['HOST'] superglobal.

Since your server is lying about the hostname (remember, the $HOST environment variable always has the www subdomain), these icons try to access a URL in www.ve3rmi.org even though you are accessing your site as ve3rmi.org (without www!). However, www.ve3rmi.org and ve3rmi.org are two different origins (web sites) as far as the browser is concerned and cannot allow an XMLHttpRequest to cross the origin boundary for security reasons. As a result, the browser returns an error to the Quick Icons JavaScript instead of executing the request which is why these icons appear red and marked with "Unknown". I disagree with the error handling in this JavaScript but I wasn't allowed to change it. Sorry, I did try to fix Joomla!. You can observe that yourself by hitting F12 in the backend of your site and then reloading the page. Go to the Console tab of the browser's developer tools and you'll see it yourself.

Remember when I told you "Your Live Site, i.e. the URL you are telling Joomla is the canonical URL to your site, was set to http://www.micomp.ca." This is the reason why it was set! If the $live_site in the configuration.php file is non-empty it overrides the information Joomla would read from the server environment. This is used exactly when we have a server which is lying about the hostname of the site.

Ah, now it makes more sense, right?!

The server lies. So we need to go with this lie, OR tell Joomla how not to be lied to, OR prevent the lie. Indeed, these are the THREE (3) ways you can address this problem:

1. Go with the lie. Always access the administration of your site as www.ve3rmi.org/administrator. It's simple, doesn't require any change to your site or server configuration, and it works. You don't want to do it. No problem!
2. Tell Joomla not to be lied to. Change the configuration.php file, namely the $live_site line to read public $live_site = 'http://ve3rmi.org';   Moreover, as I already told you, this option is exposed during restoration, Site Setup page, Live Site option, and it's fully documented as well.  This will work by overriding the information relayed by your host.
3. Prevent the lie. Ask your host to fix their server configuration as it's not under yours or our control.

So, if you want to get really technical with me, no, Akeeba Backup isn't your problem. It never was. Your problem is your host's server configuration and that you failed to change the Live Site during restoration. That's why we can't give you a refund. We can't take financial responsibility for what we cannot control!

Regarding my previous reply, I was intentionally vague in an attempt to not confuse you unnecessarily. Apparently, it had the opposite effect.

I made the reasonable assumption that you did want to access your site with the www subdomain seeing that the Live Site was set to http://www.micomp.ca. That's why I told you to use the www subdomain on your site which if you tried to do before contacting me you'd have seen it works (you'd be going with your server's lie). Had I known you are vehemently against it I would have simply changed your Live Site to http://ve3rmi.org and instructed you to do the same during restoration without any further explanation, i.e. ask you to tell Joomla not to be lied to.

Sidebar: This is NOT a great solution. If you or your clients access your site as http://www.ve3rmi.org you will see that some aspects of the site will appear broken. That's because you are accessing the site with the www subdomain BUT the $live_site tells Joomla that the site is being accessed from the non-www subdomain. That's why the $live_site rarely goes alone. There is also a redirection between the two sites, in this case from the www subdomain to the non-www subdomain, at the .htaccess file to prevent exactly this issue. Keep this in mind if/when visitors tell you that your site is broken. And for Christ's sake don't tell me it's a problem with the backup software when I've already explained in detail that it's a problem with the server configuration and how PHP and Joomla work!!!

I told you I don't know why the problem happens --even though I actually do-- because I wanted to avoid writing 1800+ words explaining a deeply technical issue. I reckoned that you could just follow my suggestion to a working site, thus avoiding potentially confusing you or sounding patronising and/or haughty. Since you chose to ask me for a refund for what I can clearly see is not a problem under our control I have to unfortunately explain this issue in detail. I don't want you to take me on my word. I want you to have a seasoned PHP software developer and a systems administrator go through what I wrote so they can confirm that what I said makes sense. I want you to access your site's administrator with the www subdomain before making any other change so you can see that it actually works as I said. I want you to manually transfer the site using ZIP and phpMyAdmin to see for yourself that the issue is unrelated to the transfer method, it is exactly what I said: a server configuration issue and the way PHP and Joomla work. Is it a lot of work? Yes, it is. But since you don't trust me I want you to go through one hundred thousandth of the pain I've gone through the last 22 years I've been writing PHP code and managing servers to see that I really know what I talking about, and that I am honestly trying to help you, not deceive you. I won't accept having any other discussion with you until you have done and have seen for yourself that I am one of the last honest software developers out there. Fair?

Finally, as I explained in my previous reply, during my debugging I saw your site making event calls to your host from within the Super User backend interface context. THIS IS A PRIVACY AND SECURITY ISSUE. It's not my job to find out where this comes from, it is my duty to tell you that I discovered it so you can take it to your host and ask them to stop tracking how you use your site for privacy and security reasons.

> HOLY SMOKES man you are talking way above my head... there is NOT A DOUBT IN THE WORLD you know your stuff!!

Sorry! That's why I try to avoid the technical explanations :( They are mostly there so a client who doesn't want to believe us can go ahead and verify themselves (presumably with some hired expert help) that we know what we're saying. If you don't care about any of that, no worries, you can safely skip that part.

The best thing you can do is please read the executive summary and follow the instructions there.

> Just as a side bar, the live site I was restoring to was completely empty; the only thing there was the site backup and kickstart.php.

Yup, that's the right way to do it!

If you want to read why (executive summary level, not full-on technical details, I swear!) and also other pitfalls when backing up or restoring your sites and how to avoid them: https://www.akeeba.com/documentation/akeeba-backup-joomla/restoring-backups.html#general-guidelines

> I don't want a refund; I want a way to back up my site and restore it if needed, and OBVIOUSLY you are then man (no sarcasm here my friend)

Awesome! I am indeed the man who can and will help you! I enjoy helping people. If I didn't, I wouldn't have dropped a career in mechanical engineering to become a FOSS developer :)

> I do indeed see if I access the backend of the site from http://www.ve3rmi.org/administrator/index.php everything does indeed 'seem right with the world'.

Perfect!

> All I really want to know is... WILL I BE ABLE TO SUCCESSFULLY UPDATE MY WEBSITE THE NEXT TIME AN UPDATE FOR joomla! 4.x comes out?

Yes, you will!

I am not "just saying" this. The Joomla Update component used to be part of our Admin Tools component. I contributed that to Joomla in late 2012, namely when Joomla 2.5.1 went out. The only part of that component I have not written is the pre-update check. The way it gets update information and applies the updates, including how they are extracted (which is just "Kickstart Lite") is written by yours truly. If you have a Joomla Update issue you've found the right person to ask!

By the way: Don't rely solely on the Quick Icons in Joomla's control panel. If you see it saying "unknown" Joomla update status you can always go to System, Update, Joomla and see if there is an update available. Like all update systems (including Windows, macOS, and all Linux distributions) the update information is cached. When you are temporally adjacent to a new release you saw announced on social media you are unlikely to see it on that page. Worry not, there's the button in the toolbar to reload updates which clears the update cache and checks for updates afresh.

The only case you won't see updates or be unable to download them is if the host is blocking the download of the update information or update files. But even then we do have a workaround. I say "we" because we came up with it with Michael Babker and George Wilson back in Joomla 3.4 when a small single character typo in a file accidentally nerfed the Joomla Update. So we decided to add some workarounds to ensure that, no matter what, you can still update Joomla.

> I really do appreciate the time you spent with me and taking the time to (at least attempt to :o) explain this to me.

No problem :) I want to help you succeed. That's why I'm here, that's why I'm writing software, that's why I contribute to Joomla itself.

Have an awesome day!