• View
• Edit
• History
• Attach
• Print

01409: Losing page content on save after edit

Description: Upon saving after editing pages in pmwiki, it occurs regularly that a large portion of the page in question is lost. It's always the tail part of the page. Luckily, I can usually restore from history, but it shouldn't be happening in the first place.

This is the site, a wiki where I keep personal information.

This is happening more and more often, to the point of making pmwiki useless. Please let me know if I should supply more information. Wim Rijnders May 08, 2017, at 03:56 AM

Could you please upgrade to the latest version (PmWiki and any modules) and report if it still happens? Since PHP 5.4 there is a change in a PHP function that may sometimes cause blank sections of a page, or blank pages. This should have been worked around since PmWiki 2.2.42 and 2.2.88. The PHP function is htmlspecialchars() and the PmWiki helper function that replaces it is PHSC(). --Petko May 08, 2017, at 08:05 AM

I got the tip to copy the page and use the new one. Apparently, having a 6-year history of many changes in a page can cause issues. I can hereby inform you that it appears to be working much better now; the speed increase is noticeable. For me, this is quite acceptable as a workaround.

Anyway, I'll do the update. Also the note about htmlspecialchars() is interesting; I have had problems with 'strange' characters when copying text from web pages. Wim Rijnders May 09, 2017, at 17:40 PM

This looks like the new htmlspecialchars(), especially if it happens around international characters, see the entry at Troubleshooting#blank_sections. If you want to preserve international characters like Russian, you should enable UTF-8. Unrelated to this, you can automatically drop old page history, see $DiffKeepDays. --Petko May 09, 2017, at 03:43 PM

So, taking into account all advice, I have done the following:

• Upgraded pmwiki to most recent stable (v2.2.97)
• $DiffKeepDays=180;
• $DiffKeepNum=30;

Tested, pmwiki now feels snappy and everything is working, no surprises. I checked the 'Diff' settings on a big, old page by editing, the size dropped by 120KB. So really, I am quite content. I feel I'm set for the future now. A tiny quibble I have is that I use a farms configuration, and I discovered by trying that I need to configure them all separately. Since this is a one-time thing, I can live with it no problem. Funny you should mention international characters, because I have plenty of those (Russian, Greek). But I note that this works perfectly fine. I have the following in the main config.php:

    include_once("scripts/xlpage-utf-8.php");

I believe this is sufficient to ensure utf-8 is working correctly, is this correct? Wim Rijnders May 13, 2017, at 18:05 PM

Read the page UTF-8, you can only include the file if your wiki has zero pagenames and filenames with international characters. If you have a farm, you can use a common file farmconfig.php and in it you usually have $FarmD like include_once("$FarmD/scripts/xlpage-utf-8.php");, see WikiFarms. Yes, if you enable UTF-8, when you type an international text like "Чебурашка", your wikitext will not be transformed to "Чебурашка" (and then you will be able to have international characters in the page names if you like). --Petko May 13, 2017, at 11:39 AM

Thanks for the tips.

• UTF-8 has now been properly enabled and the russian characters are retained in the rendering of a page.
• Usage of farmconfig.php appears to be working

In other words, I am a very happy user right now. Methinks it's time to close this issue.

Thanks all for your help! Wim Rijnders May 13, 2017, at 19:00 PM