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.

Close

#392 PHPWiki 1.3.10 refuses to accept significant volumes of text

Wiki_syntax
closed
Reini Urban
7
2012-10-11
2004-10-17
Stuart Longland
No

Hi,

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 http://atomicdoc.hopto.org
and click on the SandBox link.
--> Expected Result: Current 'SandBox' page is rendered
and displayed.
--> Actual Result: As expected:
http://www.longlandclan.hopto.org/~stuartl/phpwiki/sandbox-00.png
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:
http://www.longlandclan.hopto.org/~stuartl/phpwiki/sandbox-01.png
3. Try adding a small amount (3 lines) of text
-->
http://www.longlandclan.hopto.org/~stuartl/phpwiki/sandbox-02.png
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:
http://www.longlandclan.hopto.org/~stuartl/phpwiki/sandbox-03.png
5. Continue editing... this time adding a much larger
paragraph (I used the output from 'fortune -l law').
-->
http://www.longlandclan.hopto.org/~stuartl/phpwiki/sandbox-04.png
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?

Reguards,
Stuart Longland

Discussion

  • Config.ini file used for the wiki

     
    Attachments
  • Reini Urban
    Reini Urban
    2004-10-20

    Logged In: YES
    user_id=13755

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

     
  • Logged In: YES
    user_id=777641

    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
    user_id=777641

    Update:

    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']) ||
    

    !is_string($posted['content']))
    return false;
    echo ''."\n\n";

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

    rtrim($posted['content']));
    $this->_content = $this->getContent();

        $this->_currentVersion = (int)
    

    $posted['current_version'];

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

    $this->current->getVersion())
    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).

     

    Related

    Summary: summary

  • Reini Urban
    Reini Urban
    2004-10-22

    Logged In: YES
    user_id=13755

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

     
  • 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:
    varfilter.max_value_length

    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
    problem.

     
  • Logged In: YES
    user_id=777641

    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
    again.

    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.