[pmwiki-users] preg_replace (RFC)
john.rankin at affinity.co.nz
Wed Dec 3 16:59:12 CST 2014
On 4/12/14 10:59 AM, Petko Yotov wrote:
> The page Troubleshooting explains how to update your recipes, and/or
> how to hide the warnings if you like.
> 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'
More information about the pmwiki-users