Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#392 PHPWiki 1.3.10 refuses to accept significant volumes of text

Reini Urban
Stuart Longland


I've recently set a wiki from scratch here and

tried copying & pasting the content of this thread. The
expected result is that I should have seen the
plaintext document there, ready for me to format at
some later date. Instead, I was taken straight back to
the edit page -- with the additional text missing. It
was as if I hit the Reload button on the browser.

Steps to reproduce:
1. Go to the wiki site at
and click on the SandBox link.
--> Expected Result: Current 'SandBox' page is rendered
and displayed.
--> Actual Result: As expected:
2. Click the Edit This Page link
--> Expected Result: Taken to a text area where I can
edit the page.
--> Actual Result: Again, as expected:
3. Try adding a small amount (3 lines) of text
4. Now, click Preview.
--> Expected Result: A preview is shown of the page as
it stands with the edits.
--> Actual Result: As expected -- scrolling down the
page reveals:
5. Continue editing... this time adding a much larger
paragraph (I used the output from 'fortune -l law').
6. Now... click Preview again.
--> Expected result: Something like what's shown in step 4
--> Actual result: ALL added text disappears, I'm
effectively taken back to what's shown in step 2. Same
happens when I click 'Save'

PHPWiki has been installed using MySQL as a backend

DB. The server is running Apache 2.0.50 with PHP 4.3.8
and MySQL 4.0.20 on Gentoo Linux 1.4 (Kernel 2.4.24).
They were compilled using Gentoo's ebuilds. Any ideas
what could be causing this?

Stuart Longland


  • Config.ini file used for the wiki

  • Reini Urban
    Reini Urban

    Logged In: YES

    Yes, Apache2 seems to have some problems with the after-edit
    I'll try to figure that out with which cfg and why.

  • Logged In: YES

    I just tried downgrading to 1.3.9 with the security patch
    applied... no dice there.
    I'm now running the latest nightly, with no change to the
    problem -- phpWiki still refuses to accept any significant
    quantities of text.

    I have previously had it work just fine, that was v1.3.7
    with the same web server and database server. I can't
    however find the backup for that database.

  • Logged In: YES


    Did some investigations of my own... it seems the content of
    the textarea is being lost at some point.

    I hacked up _restoreState inside editpage.php, peppering it
    with 'echo' statements like so:
    function _restoreState () {
    $request = &$this->request;
    echo ''."\n";
    echo ''."\n";
    $posted = $request->getArg('edit');
    echo ''."\n";
    $request->setArg('edit', false);

        if (!$posted || !$request->isPost()
            || $request->getArg('action') != 'edit')
            return false;
        echo "<!-- if (!\$posted || !\$request->isPost()
                    || \$request->getArg('action') != 'edit')
                    -- not fired-->"."\n\n";
        if (!isset($posted['content']) ||

    return false;
    echo ''."\n\n";

        $this->_content = preg_replace('/[ \t\r]+\n/', "\n",

    $this->_content = $this->getContent();

        $this->_currentVersion = (int)


        if ($this->_currentVersion < 0)
            return false;
        echo '<!-- current version >= 0 -->'."\n\n";
        if ($this->_currentVersion >

    return false; // FIXME: some kind of warning?
    echo ''."\n\n";

        $is_old_markup = !empty($posted['markup']) &&

    $posted['markup'] == 'old';
    $meta['markup'] = $is_old_markup ? false : 2.0;
    $meta['summary'] = trim(substr($posted['summary'],
    0, 256));
    $meta['is_minor_edit'] = !empty($posted['minor_edit']);
    $meta['pagetype'] = !empty($posted['pagetype']) ?
    $posted['pagetype'] : false;
    $this->meta = array_merge($this->meta, $meta);
    $this->locked = !empty($posted['locked']);
    ... etc...

    I saw the following:

    Notice the lack of a "content" key... I think PHP is playing
    tricks on us. I'll try an update shortly (not to 1.5 though).



    Summary: summary

  • Reini Urban
    Reini Urban

    Logged In: YES

    maybe this:
    try to rename the "content" field. (in the form and in

  • Logged In: NO

    Gentoo's ebuilds for PHP use a restricted config file
    "so-called hardended PHP" and the default textbox uploads
    allowed are pretty small. Check this value in your php.ini:

    It was set to 1000 as the default in Hardened-PHP/4.3.8 on
    my system. Upping that to something larger might help your

  • Logged In: YES

    nobody: I am running Hardened PHP, but I don't see any
    'varfilter.*' lines anywhere. Which file in particular are
    you referring to?

    rurban: Just finished upgrading PHP. I'm running v4.3.9 now
    (hardened PHP). However, initially, I forgot to restart
    apache. So at first, when I changed the name of the textbox
    (I changed it to 'pagecontent') nothing else changed.
    However, once I restarted apache, everything started working

    I've now unpacked the nightly version again, and copied in
    my config.ini, all is working well now. It seems that
    upgrading PHP and restarting Apache has fixed the issue.

    Sorry for the false alarm.