[pmwiki-users] preg_replace (RFC)
wolfgangmcq at gmail.com
Wed Dec 3 17:07:06 CST 2014
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
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
>> 220.127.116.11: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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pmwiki-users