This is not a problem, but I got scared for 20 minutes.

Back in august 2005 I wrote and ultra long blog post. This was a traslation I made during several days, separated between them for weeks. At some point when I was editing my master piece translation, I realized that the post was being cut, and no matter what I wrote, nothing would be saved after a given amount of characters.

I thought this could be a limitation on the maximum size of any given post. Search here and there I found that the 'post_content' field in the 'evo_posts' table was type 'TEXT' and this kind if field has a maximum size of something (65k characters, if I'm not wrong). I was editing past that limit, and when the post was fed into the DB the content was cut to fit that size.

Alright, I said, maybe if I change the type to something bigger, the problem would be solved. So I read mysql reference manuals and determined that a type MEDIUMTEXT would do the trick. I backed up y database, did the change, and voila, I could post ultra long posts.

Problem was when I upgraded B2 to the next version. The update script would again set the 'post_content' field to type TEXT. So that time, I went to my ultra long post, and it was cut. I panicked, thinking I would have to write the missing text all over again. But I rememered I had a DB backup from before the last upgrade. So I restore the particular post and everything fine.

The next upgrade, I forgot the issue with the 'post_content' and had to repeat, restoring the particular ultra long post from a previous backup.

To my surprise, today someone leaves a comment in that post and I go there to read it and, what the hell! The post is cut again. Again, I panicked, and rush to look for my last DB backup, but before doing that I click the edit link to see what was happening. Bigger surprise! The post content was complete inside the backoffice editor, but outside, in the blog it was displayed cut.

So, OK, I say, now I don't understand nothing at all.

I go the phpMyadmin and check that in the DB, the post is complete. So I say "these guys changed somethin inside the get_content() function or something of the sort, because the problem is in the trip between the DB and the blog display". Thus, I venture into b2evo source code, but I don't find anything. Not any clue of any kind.

I was already preparing for a post in the forum crying for help, when two neurones made contact in my brain and made me remember there is a link, an obscure and unexplainable link, in the backoffice "Tools" tab, which says something like 'purge cache of pre-rendered items' or something to that effect. So I click there and then go again to my ultra long post, product of months of work, and it was there! complete in all its majesty!

So I understood a little bit of black magic. What I think it happened was that nobody had seen this post for a long time, from sometime after being cut to be made fit into a 'TEXT' field, and before it was restored by me to its full size. So this post was sitting there in the 'cache of pre-rendered itmes', cut and incomplete, but in the database it was full and complete. After I purged the cache, B2evo had no option but to suck it from the DB and display it complete.

And that is how I understood what a cache of pre-rendered items is for: to make me panick and make me write and ultra long post in the forum, letting everybody know of my 'discovery'.

So, anyway I ask, this cache of pre-rendered items is never refreshed? Is there a way to call a post manually directly from the DB and not from the cache? If the cache is not stored in the DB to speed things up, where is it stored? I' sure the answers to all my questions are in the source, but I did't want to let pass a post without questions. Never mind.

MORALEJA: have your backups always ready for any emergency.