[pmwiki-users] preg_replace (RFC)

John Rankin john.rankin at affinity.co.nz
Wed Dec 3 16:59:12 CST 2014

On 4/12/14 10:59 AM, Petko Yotov wrote:
> <snip>
> The page Troubleshooting explains how to update your recipes, and/or 
> how to hide the warnings if you like.
>   http://www.pmwiki.org/Troubleshooting
> I request comments from the community about this.
> First of all, for security reasons it is out of the question to 
> automatically rewrite the eval()ed PHP code in markup definitions.
Totally agree. The idea of automatically rewriting the eval()ed PHP code 
is "so bad it's not even wrong."
> I see the following options:
> 1. Disable/skip any markup rule with the /e flag so that it doesn't 
> trigger a warning. This will effectively hide the warnings but some 
> recipes will no longer work.
I support this option in principle, with some comments. It would be 
helpful if pmwiki could display an unobtrusive message saying "some 
recipes skipped" which, when clicked, displays a page listing the rules 
which have been disabled, and if possible the name of the PHP file 
containing the skipped rule. This would make it easier for 
administrators to troubleshoot and modify their installations.
> 2. Disable error reporting for E_DEPRECATED warnings. This will hide 
> the warnings, and in most environments the recipes will work as 
> expected, in short term. However, if future PHP versions deprecate 
> other features, the administrators will not see the warnings and will 
> not know they should update their code. It may be something entirely 
> different from the current issue. This sounds easy but as an admin I 
> would strongly dislike if a software changes the error_reporting 
> parameters for me.
This is my least preferred option. It strikes me as addressing the 
symptoms without dealing with the root cause, and as Petko notes, may 
have adverse consequences in future. I would prefer to focus effort on 
option 1, which will over time eliminate the root cause.
> 3. Do nothing, let the administrators see the warnings and request 
> that recipe authors update their modules to make them work with PHP 5.5.
I would rather do nothing than implement option 2, on the basis that 
"first, do no harm." However, I recently tested an unpatched 
installation under php 5.5 and the number of warnings was overwhelming. 
Perhaps mine is an edge case. Once I applied the necessary recipe 
upgrades, everything was fine. The changes were purely mechanical, no 
functionality was affected. In many cases, an administrator can readily 
modify the recipe, without input from the recipe author. The explanation 
on http://www.pmwiki.org/wiki/PmWiki/CustomMarkup is very helpful.
> Are there other/better propositions?
Some recipes use preg_replace with the /e modifier in ways other than a 
call to Markup. I don't see how pmwiki can detect and report these under 
option 1, and this would be a reason *not* to implement option 2, in my 
view. I would want to see any residual warnings, so I can take the 
necessary actions. Fixing these may require advice from the recipes' 


John Rankin

More information about the pmwiki-users mailing list