Hello, it seems you have JavaScript turned off or you are using and old browser. Hikari WebSite uses JavaScript to implement some of its features, but JavaScript is not required to browse it.

If you are willingly disabling JavaScript, I assure I'll do my best to not force you to enable it, building unobstutive and responsible JS code that do not block your Usability in this site.


Collapse comments 4 comments to “Wordpress Large post showing blank / empty?! NO WAY!!” | Comments RSS | Top

  1. 1
    flag Windows XP Mozilla Firefox 3.0.13
    gravatar Comment by Abel Braaksma (http://www NULL.undermyhat NULL.org/blog/2009/07/sudden-empty-blank-page-for-large-posts-with-wordpress/):
    Thursday, 24 Sep 2009, at 9:55:23 AM, 14 years, 10 months ago | # |

    Thanks for making a detailed post about this issue, more attention to this problem is good. It is a PHP problem though, imo: the defaults are very low when you install it using the default installer, it has nothing to do with administrators creating too restrictive configurations.

    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 ;-)marketing

    Collapse nested comments
    1. 2
      flag Windows XP Mozilla Firefox 3.0.13
      gravatar Comment by Hikari:
      Thursday, 24 Sep 2009, at 10:22:00 AM, 14 years, 10 months ago | # | replying Abel Braaksma |


      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:happy: :yahoo:


      Collapse nested comments
      1. 3
        flag Windows Vista Mozilla Firefox 3.0.14
        gravatar Comment by Abel Braaksma (http://www NULL.undermyhat NULL.org):
        Thursday, 24 Sep 2009, at 10:50:10 AM, 14 years, 10 months ago | # | replying Hikari |

        researchTotally 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 ;-)research

        Collapse nested comments
        1. 4
          flag Windows XP Mozilla Firefox 3.0.13
          gravatar Comment by Hikari:
          Thursday, 24 Sep 2009, at 5:45:08 PM, 14 years, 10 months ago | # | replying Abel Braaksma |

          marketingAh 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 :)information

          Collapse nested comments
Leave a Comment

Comment Title / Subject

XHTML: You can use the following tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <strong> <em> <blockquote cite=""> <q cite=""> <cite> <code lang=""> <pre lang="" class=""> <tt> <del datetime=""> <strike> <ol> <ul> <li> <p style="" class=""> <span style="" class=""> <h1> <h2> <h3> <h4> <h5> <h6> <sub> <sup> <i> <u>