The biggest block of data that goes into the #__admintools_storage table is the .htaccess Maker settings. Everything else is much more compact and predictable. The .htaccess Maker settings include large segments of arbitrary text data (all the custom rules you add) which could, under certain conditions, cause the stored data to be broken.
A few years ago that table's value field type was TEXT which is just 64KB of storage on MySQL. We discovered that if you added a lot of custom rules you'd go beyond that size. Therefore MySQL would truncate the JSON data in the field, making it impossible to read them back. That would be consistent with your experience. However, we changed it to a LONGTEXT which allows up to 4 GB of storage. That was more than 3 years ago. I'd have to go a long way back to the edit history of our SQL file to find the exact date.
Can you please confirm that the field type is LONGTEXT? If it's not try the following. Disable the System - Admin Tools plugin. Export your settings. Delete the table. Go back to Components, Admin Tools. You may have to reload the page twice before it stops complaining about the database table being broken. Import your settings. Re-enable the System - Admin Tools plugin.
Another issue is what kind of data you put in it. By default, Joomla uses plain old UTF8 encoding for its tables. Admin Tools will use whatever encoding Joomla is using. If it's UTF8 and you try including some Emoji or other long multibyte characters (4 bytes per character) the data in the table will be broken. I don't see why you'd do that in the settings but that's a possibility. The solution to that is converting your site's database to UTF8MB4 encoding which means backing it up with Akeeba Backup and restoring it, making sure you check the box about UTF8MB4 in the Restore Database step.
The final issue that could cause the MySQL data to be broken is including a \x00 (NULL byte) in it. If I would be hard pressed to see any practical reason why you'd include Emoji I can definitely see absolutely no reason why anyone would end up with null bytes in their .htaccess Maker data. The only solution to that is, um, not include null bytes in your data?
Beyond that I cannot think of any other reason you'd have a problem reading data back from the table assuming the table is not corrupt. You can never rule out table corruption. But I'd be more willing to believe it if it was only affecting a specific server or host than separate hosts. Given that the problem happens to you but nobody else (that we know of) and you cannot reproduce it except your live sites I am thinking that the problem lies with the kind of data that you put into Admin Tools' configuration and the field type or the table's character encoding. Everything else sounds far-fetched to me.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
