[pmwiki-users] preg_replace (RFC)

Krait, Philippe Philippe.Krait at thalesgroup.com.au
Wed Dec 3 18:37:26 CST 2014


Hi all,

Thanks everyone for jumping so quickly on this one, and with possible solutions. Although I've written quite a few personal recipes, they have all been simple, so I don't understand all the implications of the options and I will abstain. I will just make one comment about something that was said:

> I vote for option 3.
> It is easy to understand and troubleshoot the problem.

I'm really sorry, but it is not "easy to understand and troubleshoot the problem". I have been using PmWiki for many years, but I'm not a PHP Guru, and if it was that easy, it would have been fixed for all recipes in a wink. Please don't expect every "simple" user of PmWiki to have an in-depth knowledge of PHP and PmWiki itself. PmWiki is very user friendly in particular because it does not expect those.

Philippe

-----Original Message-----
From: pmwiki-users [mailto:pmwiki-users-bounces at pmichaud.com] On Behalf Of Johnny Nielsen
Sent: Thursday, 4 December 2014 9:59 AM
To: pmwiki-users at pmichaud.com
Subject: Re: [pmwiki-users] preg_replace (RFC)

> I request comments from the community about this.
> 
> 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.

I vote for option 3.
It is easy to understand and troubleshoot the problem.
It gives admins the chance to spot that they should start working on a problem resolution, before something starts breaking in the possibly near future.

Option 1 breaks stuff without any warnings or any time to try to avoid troubles (as I read it).

Option 2: Not only admins will dislike it. Users will dislike it too. Stuff wont work for them and they will have to wait for admins to finally figure out what the problem really is, before a resolution comes into sight.
And we all know how patient users are :o)

Just my humble view on the matter.

Thank you, Petko, for your willingness to help :o)

Cheers :o)

Johnny :o)

_______________________________________________
pmwiki-users mailing list
pmwiki-users at pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

This message contains OPEN information that is not sensitive and can be freely accessed by people both inside and outside of the Thales Group

This email was classified by Krait, Philippe  on Thursday, 4 December 2014 11:37:26 AM


-------------------------------------------------------------------------
DISCLAIMER: This e-mail transmission and any documents, files and 
previous e-mail messages attached to it are private and confidential.  
They may contain proprietary or copyright material or information that 
is subject to legal professional privilege.  They are for the use of 
the intended recipient only.  Any unauthorised viewing, use, disclosure, 
copying, alteration, storage or distribution of, or reliance on, this 
message is strictly prohibited.  No part may be reproduced, adapted or 
transmitted without the written permission of the owner.  If you have 
received this transmission in error, or are not an authorised recipient, 
please immediately notify the sender by return email, delete this 
message and all copies from your e-mail system, and destroy any printed 
copies.  Receipt by anyone other than the intended recipient should not 
be deemed a waiver of any privilege or protection.  Thales Australia 
does not warrant or represent that this e-mail or any documents, files 
and previous e-mail messages attached are error or virus free.  

-------------------------------------------------------------------------




More information about the pmwiki-users mailing list