Note: This post is extremely advanced. Only try to implement the below if you’re a solid developer and after backing up the Joomla website (database + filesystem).
We had a weird case this morning. A client called us and told us that her staff were able to edit certain articles only once every day – in other words, they edit the article the first time, they save it, and then they can’t do edit it again until the next day.
That was very weird, we thought. We haven’t seen something remotely similar in a decade of Joomla consulting. So, we visited the website, and we edited one of those cursed articles, and then we saved it and closed it. To our surprise, the article was no longer editable (the article title was no longer a link).
We knew this whole thing had something to do with the #__assets table, but we just didn’t know where to look. However, after examining the issue further we noticed that the all of these articles belonged to the same category, which was the Uncategorized category.
So We looked up the entry of the Uncategorized category in the #__assets table, and we couldn’t find one, we were, however able to find an entry in the #__assets table matching the value of the asset_id field of that category, and that entry was that of a module (its name was com_modules.module.334). Clearly, that was wrong…
After some testing, we discovered what was happening, when an article belonging to the Uncategorized category was edited and saved, a wrong entry for that article was created in the #__assets table. Why is it a wrong entry? Well, because the parent of that entry is not the right parent (it is a module instead of the Uncategorized category). Obviously, fixing the problem consisted of recreating an entry in the #__assets table for the Uncategorized category. Here’s how we did it:
- We created a new category, we called it “Test Category”. We made sure that it had the same parent category as that of the Uncategorized category (it actually had no parent).
-
We went to the #__assets table, and then we searched for the entry corresponding to “Test Category”.
-
We changed the value of the name field for that entry in the #__assets table to be com_content.category.33 (where 33 is the ID of the Uncategorized category in the #__categories table), we then changed the title field in the #__assets table to be Uncategorized.
-
We changed the value of the asset_id field of the problematic (Uncategorized) category to that of the ID of the row that we have just changed in the #__assets table.
-
We deleted the Test Category from the #__categories table.
-
We ran the following query on the #__assets table…
DELETE FROM #__assets WHERE name = 'com_content.article.nnn';where nnn is the article ID that we were not able to edit. Doing this removed the bad asset information associated with that article.
-
That’s it. The problem was fixed.
So, what caused the problem in the first place?
We don’t know what caused this data corruption in the #__assets table, but we think it was one of the following:
- A previous migration that wasn’t 100% clean.
-
A poor extension that corrupted the #__assets table.
-
An incorrect manual edit to the #__assets table.
Why were they able to edit articles the next day?
Well, because the website had a cron job to optimize the #__assets table at midnight of each day. The optimization consisted of pruning all the articles entries in the #__assets table as per our guide here. Once the cron ran, all the bad references in the #__assets table were removed, and so editing articles belonging to the Uncategorized category was possible again.
If you can’t edit articles on your website, then check your #__assets table, and implement the guide above. If you have problems with the implementation, or if you’re too scared to do it, then please contact us. We will do the work for you swiftly, professionally, and for very little money.