Wordpress Large post showing blank / empty?! NO WAY!!
Recently I've made a post that had become really large. While I was still preparing it, I was faced with a damn situation: when it was published it was showing an empty page!
Header, sidebars, footer, post title, comment area... they were all there, but the post itself was gone. How was that possible?
The situation
First of all, a better explanation of what was happening. I don't use TinyMCE editor to prepare my posts, I prepare them with Dreamweaver and only add the resulting HTML to Wordpress' post editing page.
Inside Dreamweaver everything was fine. Inside the edit page the whole HTML was being presented too. I also tried to add it directly to the database with phpMyAdmin too... no success. Strange...
That post had a lot of copied texts and images on it (I was denouncing a dissembler that had been threatening me and censured my comments on another blog when I tried to denounce his lies, so I was publishing all my deleted comments here to make them public and impossible to be censured again), so my first thought was that some div or table was out of place or not closed. But I verified the whole code and found nothing suspicious...
The only difference that post had from all others was it was my largest post ever, and it wasn't even ready yet! I indeed tested removing part of the post and voila, there was the post properly showing! What a damn! I even tried to remove other parts of the code, maybe it was some table in its middle that was breaking everything, but again I had no success. It didn't matter which part I removed, as soon as the post got larger enough it was becoming a blank post again!
Of course I considered splitting the post into 2 posts, but that wasn't a proper solution. What was causing it? Could Wordpress have a post size limit and not be able to handle large posts?!
The first clue
Searching on Google I ended up in Under My Hat site (http://www NULL.undermyhat NULL.org/blog/2009/07/sudden-empty-blank-page-for-large-posts-with-wordpress/). He had the exact same problem I was having, a large post that was showing blank/empty.
He explains it was being caused by a mix of shortcodes with paragraphs handling. As you can read on his post, Wordpress has this great shortcode feature, that lets us use "proprietary" text enclosed in [], and it is converted in PHP code just before a post is shown to our visitors. Wordpress also has this evil wpautop function, that takes our post (and comments too) texts and seeks for loose texts, adding paragraph tags to them.
The problem seemed to be that both these features seek post texts numerous times in loops, trying to find nested paragraphs/shortcode brackets. But they are not properly coded, and for each loop, they queue gathered data into some kind of variable, which gets bigger and bigger and bigger, until all available RAM is used and this variable overflows (like in buffer overflow I believe). When that happened, all the data would be lost and post gathering routine would simply return empty, resulting on the empty post.
Even worse, it seems that this may happen inside edit page too, so if somebody uses it to create posts and create a large post in it (god has compassion for these poor souls...), saving it and having it reloaded, it would load empty. Then, if they try to save it again, the empty post would be saved to database and original large text would be lost! (NOW god has compassion for them!! )
The solution he first proposed, then, was to not use shortcodes inside large posts and disable wpautop, or hack it to remove the 1-line code that seemed to be creating the overflow. I hate wpautop and it is already removed (by raw-html plugin), and I couldn't remove all my shortcodes! I even tried his suggestion of hacking Wordpress core, but no solution at all, post was still empty.
The ultimate solution!
It was in his comments area that I found a better suggestion. Somebody talked about editing a php.ini config, increasing some recursion limit.
It seems that when shortcode handler/wpautop is browsing post code and storing its data, it uses recursion to seek for paragraphs/shortcodes inside them, and that keeps happeing without flushing the data until the whole post seeking is done.
What they discovered is that the bug is not in Wordpress code, but in PHP's regular expression engine! So, if we increase that engine's RAM limit, we will be able to create even larger posts without facing an overflow that results in an empty post.
But there was still another problem... The solution required to edit php.ini. Original php.ini is not available in shared hosts, because any change on it will affect hundreds (or thousands, for those "unlimited bandwidth" hosts) of sites. I believe Apache lets us create a php.ini file inside any folder, and its config will affect only sites in there. But my host doesn't use Apache, it uses Litespeed!
Litespeed is a commercial Web Server, that is much faster than Apache and is somehow compatible with it in configurations, but Litespeed doesn't have php.ini support
Taking a few more minutes of my life away searching for a solution for the problem that the previous solution created, I found an alternative. Instead of using php.ini, we can use .htaccess to set configs that were originally set by php.ini.
php.ini uses the following syntax:
key=value
that can be converted to .htaccess using the following syntax:
php_value key value
Being that, original solution was to edit php.ini, changing the following configs (or adding them, if they are nowhere):
pcre.recursion_limit=20000000 pcre.backtrack_limit=10000000
But if php.ini is not available or if we just prefer to use .htacces (which is already used for other stuff, and then we can leave all our Wordpress configs in 1 unique file), we must add the following lines to our Wordpress .htaccess (it is in our blog root folder and there are already some Wordpress configs in it, don't mess with them if you don't know what they do and always backup everyting before editing it!):
php_value pcre.recursion_limit 20000000 php_value pcre.backtrack_limit 10000000
This solved my issue. After editing .htaccess my large post was there, as it was always meant to be. I finished it and posted it on my production site, and as you can see it is working fine. The dumb guy even kept bothering me with spam comments pretending to be fake people.
I also contacted my host alerting I was changing a config that could lead to more RAM consumption and they said it was ok.
And that's it. Wordress is innocent, PHP is innocent too. The blame goes to restrictive PHP configs that must be broadened to allow higher code flexibility. Of course Wordpress developers should be more careful about it, letting us know about its possible bottlenecks, building better documentations for our loved blog/CMS engine!

Popularity: 7%

It has accumulated a total of 38,187 views. You can follow any comments to this article through the Comments RSS 2.0 Feed. You can leave a comment, or trackback from your own site.
Variables and loops: was never the problem
Another little point: it is not about variables or loops, it never was. I used advanced debugging techniques to track it down and it was clear that the problem was in the regular expression engine, however, when I wrote my first draft, I wasn’t aware of these settings. Once I was aware of them, it proved pretty hard to find the real impact of them, hence I hesitated posting “big” about them, but I eventually did (some time ago). You suggest that it might take more memory. That’s true. But if you set them to the values I suggest in my post, the increase of memory is marginal compared to the rest that PHP uses.
the actual problem
The real problem is actually “regular expression recursion”. This is a complex technology and regex engines have varying ways of dealing with it. The regex engine PHP uses is compiled with recursion ON, but the regex engine can also be compiled with recursion OFF, which would be a much better solution overall. That too, is a PHP problem (actually: a distro or built problem). Note that a very simple regex can hit the default limit.
in search of the right section ;-)
I wonder why the PHP.INI solution wasn’t clear the first time around, there’s a large green link on top “solution” that points to the only section labeled “The solution” (http://www NULL.undermyhat NULL.org/blog/2009/07/sudden-empty-blank-page-for-large-posts-with-wordpress/comment-page-1/#solution). I’ll look through my post to see whether I can make it a bit clearer for future visitors ;-)information
information
Hey dude tnx for the explanation!
Indeed that is php.ini’s default config. What I mean is that, for exemple, if you develop an application considering that register_globals is on, you should inform that to whoever uses it. Because if it is not set to"on", your app won’t work and user will be lost without knowing the cause.
This exemple resembles what happened to us. Everything works fine as long as WordPress user doesn’t try to publish large posts (well, together with shortcodes and with wpautop enabled). But it turns out to a bottleneck when large posts come to place, so WordPress devs should notify that.
About your post, when I came to it now to make my post I saw the final solution was there. I don’t know if you edited it or something like that, but I remember that when I found it in the past when I was facing the issue, the solution that worked to me was found in a comment. I wasn’t able to find it too (ok call me crazy -.- ), but I remember the guy was commenting about part of your post related to php.ini, saying that hacking WordPress core didn’t work, which was the same to me.
Well what matters is that it is working now and we are all happy with our large posts

homepageTotally agree. From the comments on my post, some people without using shortcodes had the same problem. Resolutions could be found the long run in three ways, I think:
1. Defaults of php.ini set to a reasonable figure
2. Next php built contains non-recursive regex engine (is faster anyway)
3. WordPress and any other PHP tool should be aware of this and catch the error (easy) and warn the user
Short-term: as you also noted, this setting can be adjusted through code, so why not simply add a line of code in wp-settings.php?
PS: my post was edited about a one and a half month ago or so, to include better browsing and a clear tale on the solution, so that makes sense with your story ;-)
participateAh so that’s what happened :D
I noted there was “something” different, but I couldn’t see what it was, and my story was fun so I decided to narrate it anyway :p
Your idea is nice, WordPress already edits .htaccess, so it should add those lines to it by default, or offer an option to do so.
Another thing: as I said, my host uses Litespeed with anohter PHP engine, PHPFast, PHPCGI, something like that. I don’t remember the name, but I know it’s different from normal PHP that we install with Apache. And the same problem happened, so I believe it’s not just a compilation/engine issue, it may be further than that.
My guess is that recursive code needs more RAM to run indeed, and default php.ini config simply doesn’t give enough for it.
So maybe it is a mix of WordPress code requiring more RAM than usual, with default config not giving enough for it.
But these 2 .htaccess configs give something like 10x more RAM than default, so we should be OK. The best solution would be a more efficient code, but since hosts (mine at least) don’t bother with it…
Tnx again for sharing your experience on your site and helping us. I’m starting to post some of my experiences and learnings too, I will document all WordPress tweaks and hacks I’m working on :)