[pmwiki-users] preg_replace (RFC)
design at softflow.co.uk
Thu Dec 4 02:55:20 CST 2014
Thursday, December 4, 2014, 12:37:26 AM, Philippe wrote:
>> 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.
I think you are right. It should not be expected for a site admin to
fix the problems introduced by the update to PHP 5.5, which was most
likely not done by her/him anyway. To be able to identify which recipe
scripts or skins are generating these error messages would be nice.
Partly PHP does this and points to the script and code line involved.
An admin should hopefully be able to see by this what recipe is
involved, and check if there is an updated PHP 5.5 compatible version
available. Otherwise contact the recipe author or mention the problem
here on the user list, where someone else may be able to help to fix
the recipe. I have been relying on such error feedback from users
about scripts I authored or co-authored.
But there are many PHP error messages pointing to pmwiki.php, which
are not caused by pmwiki code directly, but by use of the Markup()
function in recipes and skins using the /e modifier in the regular
expression. I think Petko did a good job adding a PmWiki error message
in such cases, which identifies the offending regular expression. But
how can a site admin work out in which recipe or skin script this
regular expression pattern is? Because that is not clear from the
error message. A Markup() call with /e modifier could be anywhere, and
an admin would not know, unless s/he has a good idea about the scripts
involved and the regular expressions. One could make a text search on
all cookbook and skin scripts for the offending regular expression
pattern, I guess. So this is not an easy way to identify offending
code and scripts. Still Petko provided a handle and I am grateful for
Could PmWiki be more specific to identify in which function call and
script offending regular expressions reside? I don't see how.
So my vote is for option 3 (do nothing, although Petko has already
done a lot to help flag the problems ). But in the end we might need
to think about issuing warnings in the cookbook about the scripts and
skins which are not PHP 5.5 compatible. Maybe they can all b searched
for regular expressions with /e modifiers? But that does not sound
easy either. And sometimes RE patterns with /e modifier were
created, which do not appear inside a call to preg_replace or
preg_match etc. Finding all these is difficult. Fixing them may prove
difficult as well.
mailto:design at softflow.co.uk
More information about the pmwiki-users