Every single time we migrate a large Joomla website to Joomla 2.5, we have to optimize it. Not because the client asks to do it and not because we think it’s fun (or because we like gold-plating), but because we have to – elsewise the website would be crawling. But why is that?
Well, let’s start by discussing the existence of the weirdest Joomla table, the #__assets table. The #__assets table, in case you don’t know, holds information about nearly everything on your Joomla website. For example, when you install a new component, a new entry in the #__assets table will be created. When you add a new article, a new entry will be created as well. But what does that entry contain? Well, it contains the parent ID of that entry (for example, if you’re adding an article, then the asset ID of the parent category will be recorded), the list of (ACL) groups that can access that entry, the left (lft) value which equals to the rgt + 1 of that entry’s immediate left sibling, and the right (rgt) value which equals to lft – 1 of the parent’s entry. Confused? We’d be very surprised if you’re not. But don’t worry, the complexity of this table is not the problem, it’s how it works!
Let’s say you have 30,000 articles on your Joomla website, and you want to add a new article under Category A. Category A has a lft value of 100 and a rgt value of 103 (in other words, it currently has only one article, its lft value being 101 and its rgt value being 102). Since we want to insert a new article in this category, then the category’s rgt value must expand by +2 (the new article’s lft value will be 103 and its rgt value will be 104) to 105. Now the problem is that all numbers above 103 are already taken by other entries in the table, which means that we have to shift all the entries with a lft value above 103 by 2. The technical cost of doing a 2 x SQL UPDATE statement on 30,000 rows (it’s 2x because we need to update the lft and the rgt fields of each row) is tremendous – and can bring the server down to its knees.
But why does Joomla have the “lft” and “rgt” fields?
Honestly, we don’t know why they’re there. Their presence is not necessary at all to the day-to-day activity of the website. They’re not used for the ordering because the ordering is saved in the ordering field in any table. They’re not used to determine the parent, because there’s already the parent field in the same (#__assets) table as well as potentially in other tables (for examples, the #__content table has the catid field that contains the parent category of each article). In fact, come to think of it, we’re not exactly sure why the whole #__assets table even exists! Joomla 1.5 ran flawlessly without it and we’re sure that Joomla 2.5 can also run flawlessly without it!
Now, let’s discuss the second problem, which is the terribly (un)optimized views. Say that you want to visit the Category Blog page of one of your biggest categories (the category has 20,000 articles). The first time you visit the page, you are likely to see a memory error because the amount of memory needed to generate the page is tremendous! (If this is the case you will need to increase the memory limit available to PHP) This is because Joomla loads most of the fields of all the 20,000 rows (including the introtext field, which usually contains the article itself) to generate that view, even though you are only seeing 30 articles at any one time. The reason that Joomla does this is for paging. What makes things worse, is that the query to load the fields is run twice: the first time to generate the view and the second time to generate the paging (read more about this here). This strategy to load everything is lazy and amateurish at best – because 1) it can take more than a minute just to load that view and 2) any rookie programmer knows that the best thing to do is to select only the ids from the table, and then select the full information on demand (in other words, we get all the ids of all the articles in that particular category, but we only get the full information of the 30 or so that we are showing at any one time).
Not strictly an optimization issue, Joomla’s 2.5 ACL is too horrible not to mention in such a post criticizing Joomla. That ACL is so flexible that it’ll allow you to easily make your website unusable if you do the wrong thing. We can’t think of any other CMS where doing a small mistake at the ACL level will render the website useless. The Joomla team, priding itself with optimizing the ACL by making it more flexible, have actually made it more dangerous. In fact, we don’t see the 2.5 ACL as an advancement, we see it as a step in the wrong direction that causes a lot of problems to Joomla administrators (the number of people asking us to fix their ACL is quite high).
Now, if your website is suffering ever since you have migrated to Joomla 2.5, then all you need to do is to contact us and we’ll make sure that your website becomes optimized in no time. Our rates are affordable, our work is top notch, and we have the right attitude! Oh, and we’re fun!
Left, right and parent. It seems to represent a tree structure. With left and right values your are able to get all the nodes of a branch, the full path to a node and other useful things otherwise you will need recursive functions to get.
Could Joomla be using them for internal stuff?
Hi Aitor,
They are definitely used – but what we’re saying that their presence is not necessary and they are creating a lot of overhead on table updates. If you have 100,000 rows in that table then a new insert may potentially mean a 100,000 updates (that’s the worst case scenario, but you get the point).