#392 PHPWiki 1.3.10 refuses to accept significant volumes of text

[Stuart Longland]

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

[Stuart Longland]

Config.ini file used for the wiki

[Reini Urban]

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.

[Stuart Longland]

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.

[Stuart Longland]

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

[Reini Urban]

Logged In: YES
user_id=13755

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

[Nobody/Anonymous]

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.

[Stuart Longland]

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.