<div dir="ltr"><div>Thanks a lot for your immediate reply. This got me into the right direction. In case this is of interest to you, there have been multiple recipes and customizations causing the trouble. I believe some of them have this issue <a href="https://www.pmwiki.org/wiki/PmWiki/CustomMarkup">https://www.pmwiki.org/wiki/PmWiki/CustomMarkup</a> - at least I could not find
htmlspecialchars() in those recipes, but many Markup statements in the old style. Will need to understand how to update these Markup calls.<br></div><div></div><div>I had to disable all of the following and so far only the gallery one is leading to lost content. <br></div><div><br></div><div>$Skin = 'maguila';</div><div>include_once("$FarmD/cookbook/fox/fox.php"); # and all other fox related lines of code<br></div><div>include_once("
$FarmD/cookbook/gallery.php");</div><div>include_once("$FarmD/cookbook/flash3.php");</div><div>include_once("$FarmD/cookbook/ryevote.php");</div><div>include_once("$FarmD/cookbook/make_columns.php");</div><div>include_once("$FarmD/cookbook/zap.php");</div><div>include_once("$FarmD/cookbook/zaptoolbox.php");</div><div><br></div><div>Markup('ProcessForm', '<{$var}',<br> '/\\(:processform\\s*(\\w*):\\)/e',<br> "ProcessForm(\$pagename, strtoupper('$1'))");<br>function ProcessForm($pagename, $method)<br>{<br> global $InputValues, $FmtPV;<br> if ($method == "GET")<br> $method_array = $_GET;<br> else<br> $method_array = $_POST;<br> foreach ($method_array as $k=>$v) {<br> $foo = PHSC($v,ENT_NOQUOTES);<br> # This keeps the field values current with the form from submission to<br> # submission, but has nothing to do with PTV<br> $InputValues[$k] = $foo;<br> # Single quotes cause havoc in pmwiki.php (line 754 eval in 2.2.0 Beta65)<br> # unless they are escaped with \. This line escapes any unescaped single<br> # quote and turns any existing escapes into double-escapes.<br> $foo = preg_replace('/\\\\/', '\\\\\\\\\\\\', $foo);<br> $foo = preg_replace("/(?<!\\\)'/", "\'", $foo);<br> $foo = preg_replace("/\"/", '"', $foo);<br> # This creates a Page Variable for use in the rest of the page<br> $FmtPV['$'.$k] = "'$foo'";<br> }<br> return('');<br>}</div><div><br></div><div>So thank you again for your help!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Sa., 12. Sept. 2020 um 18:53 Uhr schrieb Petko Yotov <<a href="mailto:5ko@5ko.fr">5ko@5ko.fr</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Both actions "source" and "diff" appear to work fine:<br>
<br>
<a href="http://www.elfgestirn.de/Verein/HomePage?action=source" rel="noreferrer" target="_blank">http://www.elfgestirn.de/Verein/HomePage?action=source</a><br>
<a href="http://www.elfgestirn.de/Verein/HomePage?action=diff" rel="noreferrer" target="_blank">http://www.elfgestirn.de/Verein/HomePage?action=diff</a><br>
<br>
but not when the history has markup processed:<br>
<br>
<a href="http://www.elfgestirn.de/Verein/HomePage?action=diff&source=n" rel="noreferrer" target="_blank">http://www.elfgestirn.de/Verein/HomePage?action=diff&source=n</a><br>
<br>
so my guess is some markup processing causes the blanking of the pages.<br>
<br>
In the past, without any other warning or error message, the most <br>
frequent reason for a blank page or section was a call to <br>
htmlspecialchars() in a recipe/addon/skin.<br>
<br>
With recent PmWiki versions, any call to htmlspecialchars() can be <br>
replaced with a call to PHSC() which is a PmWiki helper function that <br>
safely calls htmlspecialchars().<br>
<br>
Depending on how the server is configured, it is possible that another <br>
function call may cause this. (Recent PHP versions change the rules and <br>
something that worked fine in earlier PHP versions may stop working <br>
after a server upgrade. I try hard to follow and fix any such cases, or <br>
implement and document workarounds.)<br>
<br>
It may be helpful to enable PmWiki diagnostics and open the page<br>
<br>
<a href="http://www.elfgestirn.de/Verein/HomePage?action=ruleset" rel="noreferrer" target="_blank">http://www.elfgestirn.de/Verein/HomePage?action=ruleset</a><br>
<br>
where some custom markup rules may be marked as obsolete.<br>
<br>
Again, try disabling (commenting out) *all* recipes and local <br>
configuration, then enable one and see if it works or becomes blank. <br>
Then proceed to the next one.<br>
<br>
See <a href="https://www.pmwiki.org/wiki/PmWiki/Troubleshooting" rel="noreferrer" target="_blank">https://www.pmwiki.org/wiki/PmWiki/Troubleshooting</a> -- read all <br>
sections, including the first one and the one on blank pages (since <br>
source and diff actions work, it is likely NOT a problem with file <br>
permissions but with something else).<br>
<br>
Petko<br>
<br>
On 12/09/2020 17:47, Marcel Schweiker wrote:<br>
> Dear all,<br>
> I really hope you can help me out after a full day of trying to solve <br>
> this.<br>
> My page based on pmwiki was blank (no content) when I started this <br>
> morning<br>
> - despite working a few weeks ago, when I checked the last time. I then<br>
> upgraded this morning from 2.2.8 to the latest version of pmwiki and <br>
> also<br>
> upgraded all recipes.<br>
> The result is, that header and footer are visible and working, but all <br>
> else<br>
> (sidebar left and main content) are not there.<br>
> I checked the $EnableRelativePageVars issue as I upgraded from 2.2.8 <br>
> (no<br>
> change with setting it to 0 or 1) and also manually <br>
> activated/deactivated<br>
> all recipes individually (no change in the pages behaviour). I am not <br>
> sure<br>
> how to work with a test page, because I cannot login for editing as the<br>
> login fields are on the main part of the page, which is not displayed.<br>
> I am using the maguila skin, which might be an issue, but I have the <br>
> same<br>
> behaviour when switching to pmwiki skin.<br>
> Any help would be highly appreciated. The page is <a href="http://elfgestirn.de" rel="noreferrer" target="_blank">elfgestirn.de</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Dreikönigstr. 10, 76187 Karlsruhe, Germany<br>T: +49 721 3 290 285 | M: +49 179 2605977</div>