We get constant calls from Joomla administrators telling us that their Media Manager page (the one accessible from the backend by going to Content -> Media Manager) takes an awfully long time to fully load. We then ask them, “how many images do you have under the main images folder?”, and the answer ranges from “a few hundred” to a “few thousand” pictures. “That’s exactly the reason why the Media Manager is slow”, we tell them, “you just have too many images under the root directory of the images folder”. “Why would that be a problem?”, they ask. And so we start explaining…
You see, when you go to the Media Manager page, Joomla grabs all the images under the root directory of the images directory, and displays them as thumbnails in an iframe. Note that Joomla does not physically create thumbnails, it just grabs the image, and displays it in thumbnail dimensions. Now, this is OK when you have a few dozen images under the main images folder, but, when you have a few hundreds or a few thousands, and when the size of each image is a few megs, then that page will take ages to load properly, even with an extremely fast Internet connection, because you’ll be literally loading Gigabytes of data (a Gigabyte is a thousand Megabyte).
So, what is the solution to this problem?
The solution, moving forward, is to store images in nested directories, and ensure that no directory has more than 50 images. You can follow different methodologies to create those nested directories. The nested directories can have meaningful and related names such as: images/fruits/apples, or images/vegetables/tomatoes/cherry-tomatoes/. An even easier approach is to put all the images used on one page under one folder, which is the id of that page, for example, images/id/5 is a folder that contains all the images that are used on the page which id is 5. Yes, there will be some redundancy issues (the same image will be in two places if it’s used on 2 pages), but such issues have zero effect on the stability and the performance of the website (in other words, you don’t need to worry about these redundancy issues unless, of course, you have a limited amount of available diskspace on your server).
The above solutions are manual. An even better solution, if you have a very large website with many images, is automatic, and it requires some modifications to the way the media manager works. In short, everytime you upload an image to the media manager, the media manager must convert the title of that image appended to the current Unix Timestamp to the MD5 equivalent, and then store it under the folder images/A/AB/ where AB is the first two characters of the MD5 equivalent, and A is the first character of the MD5 equivalent. For example, for an image with an MD5 value of 2b93fbdf27d43547bec8794054c28e00, the storage folder should be images/2/2b. Of course, the media manager must tell the user the exact storage folder so that the user can correctly reference it in the article. Now, this method is very complicated, and it requires some serious modifications to how Joomla works, but it’s the ideal solution to balancing the image folders on Joomla.
We know, many of you will probably think that the second method is much better than this one, but the second method has a limitation: a Linux folder cannot have more than 32,768 folders in it, which means that you can only store images for 32,768 articles. If you reach a point where you have more than 32,768 articles on your Joomla site, then you’re in trouble! (Assuming, of course, each article contains at least one image.) Note: You can modify the second method to place several sub-folders under another sub-folder. For example, for articles having ids ranging from 1 to 100, you place their folders under a folder named 1, for articles having ids ranging from 101 to 200, you place them under a folder named 2, etc… This will allow you to accommodate over 3 million articles with images!
OK, now how to fix the already huge images directory?
You will need to develop a script that will loop through all your content items, and, for each content item, it’ll do the following:
- Create a list of all local images (including their paths) used by that content item.
-
Generate the new path of the image (by following the second or the third method above; the first is not feasible by using a script).
-
Copy the image file from the old path to the new path.
-
Replace all references of the old image path with the new image path in the content item.
-
Save the content item.
Now, once the loop is done, then the script must delete all the images that were already copied. (The script must maintain an index of all the copied images.)
This method, of course, is not flawless, especially if external websites are referencing your images directly and you actually care about those sites (this is rare but it does happen). Naturally, there is a solution to this problem, but it is outside the scope of this post.
We hope that you have found this post to be useful. If you need help implementing any of the above techniques, or if you need further information, then you’re at the right place. Just contact us and we’ll definitely solve this problem for you. Please note that our affordable fees apply!