[pmwiki-users] preg_replace (RFC)
nzskiwi at gmail.com
Wed Dec 3 17:16:10 CST 2014
It would not be hard to inspect recipes on PmWiki, and flag as requiring an
upgrade on the recipe page.
This then would be a indicator to users that these recipes may cause issues.
Also can we use http://www.pmwiki.org/wiki/Cookbook/RecipeCheck and
http://www.pmwiki.org/wiki/PmWiki/SiteAnalyzer to flag some of these
I do note, having upgraded a recipe that I was not the original author of,
that there were a number of other, shall we say, issues, that also had to
be rectified that were detected during testing.
Perhaps we need a plan for recipes whose authors are no longer involved,
and perhaps consideration of incorporating some in the core.
On 4 December 2014 at 12:07, Wolfgang Faust <wolfgangmcq at gmail.com> wrote:
> If you can detect the /e flag being used (as suggested by option 1), it
> would probably be helpful to complain about the recipe which is using it,
> to make finding the offending script much easier. I agree with John
> Rankin's idea of a message listing the recipes which are causing the
> warning, if possible.
> I personally would go for option 3 (do nothing), as this is the least
> surprising option. Randomly breaking recipes are harder to debug than an
> error message, and disabling error warnings can (as you mentioned) cause
> similar grief.
> On Wed, Dec 3, 2014 at 4:59 PM, Petko Yotov <5ko at 5ko.fr> wrote:
>> On 03.12.2014 22:04, Krait, Philippe wrote:
>>> [Sun Nov 30 07:08:34.262716 2014] [:error] [pid 17719] [client
>>> 18.104.22.168:47958] PHP Deprecated: preg_replace(): The /e modifier
>>> is deprecated, use preg_replace_callback instead in
>>> /home/philippe/....../pmwiki.php on line 1664
>>> Are the warnings really caused by recipes, as this is core pmwiki code ?
>> Yes. The line 1664 is called when a markup rule is defined. All markup
>> rules in the PmWiki core will not trigger the warning.
>> I am using tons of recipes, and it would really be a pain to go
>>> through all of them to find the one(s) doing this if that is the case.
>>> Or is it still a bug in the pmwiki core itself ?
>> It is not a PmWiki bug and never was. You can disable all recipes and
>> skins and see there are no warnings. Moreover, there are no warnings with
>> PHP 5.4 or older.
>> 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.
>> 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.
>> 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.
>> 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.
>> Are there other/better propositions?
>> pmwiki-users mailing list
>> pmwiki-users at pmichaud.com
> The views expressed above are exclusively mine, if anyone's.
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pmwiki-users