One of our regular customers emailed us today and told us that the Media Manager on his Joomla website of his company is not working. He asked to take a look. We logged in to his website and we noticed that while the Media Manager page is loading properly, the upload functionality is not working. In fact, when we tried to upload an image (in FireFox), the following happened:
- The below message popped up:
Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party. Are you sure you want to continue sending this information?
and…
-
…once we clicked on Continue – we were redirected to a blank page!
The first thing that we tried to do was to enable debugging since a blank page in Joomla is nearly always a sign of an error. Unfortunately, the page remained blank even after debugging was turned on. Hmmm…
We then thought: maybe that JavaScript popup message is related to the problem. So, we checked the HTML code of the Media Manager page (where the files are uploaded), and we noticed that even though the website was set to only use https://, the Media Manager page was submitting to an http:// page (which was http://www.ourclientjoomlawebsite.com/administrator/index.php?option=com_config&view=component&component=com_media&path=&tmpl=component. Aha! That was the problem!
You see, the secure version of any website is not the same as the non-secure version of the same website from many perspectives – so while the upload was being done from the https version of the website, it was submitting to the non-secure version. OK – we know that the previous statement is a bit complicated, so let us explain (in simple and concise steps) what happened:
- The file is uploaded to the non-secure version of the website.
-
The non-secure version of the form submission script (which was supposed to handle the upload) automatically redirects to the secure version of that script.
-
The secure version of the script can’t find the file that needs to be uploaded – and throws an empty page because it thinks that this is most likely an attack.
But – why was the form submitting to the non-secure version of the script?
Because Joomla’s configuration.php told it to… Yes – it was all its fault, the configuration.php had the the $live_site variable set to http://www.ourclientjoomlawebsite.com instead of https://www.ourclientjoomlawebsite.com – changing that variable to https://www.ourclientjoomlawebsite.com fixed the problem!
But isn’t that a Joomla bug?
As much as we don’t like to say it – yes, it’s a bug in Joomla’s core. Here’s why: what if the Joomla administrator wants to set the $live_site to the non-secure version of his website and wants to only have the backend of his website running in secure mode. Currently, this won’t work, because the form submission script of the Media Manager is set to use the $live_site variable if it exists. So either the whole website runs in https mode (not just the backend), or the $live_site variable is set to empty.
Is there a workaround?
The only workaround that can fix this erroneous behavior is by modifying a core file in Joomla – which is never recommended because it might affect (or be affected by) future Joomla updates.
Now, if you’re having problems uploading files to your Media Manager, and if the above didn’t help you, then maybe it’s a permission issue – remember, Joomla must have recursive write permissions to the tmp and the images directory for the Media Manager to work. If it’s not, then maybe it’s because you need to increase the maximum upload size in your Media Manager. If it’s neither, then your best option would probably be to contact us. We’re fast, we’re efficient, we don’t charge much, and we know our Joomla!