[pmwiki-users] preg_replace (RFC)

Patrick R. Michaud pmichaud at pobox.com
Fri Dec 5 12:05:51 CST 2014


On Fri, Dec 05, 2014 at 10:15:01AM -0500, DaveG wrote:
> On 12/4/2014 3:55 AM, Hans Bracker wrote:
> >Could  PmWiki  be more specific to identify in which function call and
> >script offending regular expressions reside? I don't see how.
>
> Agree with this sentiment, and option 3. If we could somehow guide
> admins in tracking down exactly where errors are occurring, beyond
> the pmwiki.php end point I think that would help a great deal.
> Perhaps an option to provide more of a stack trace -- although like
> Hans, not sure how that could be done.

I wasn't sure how this could be done either, but searching the PHP
function library helped.  There's a debug_backtrace() function available
since PHP 5.1 that can provide the current backtrace.  So, the 
Markup() function could check the $pat argument to see if there's a 
"/e" modifier, and produce a warning/backtrace if so.

Ideally this behavior would only be triggered by an administrator and
not be enabled by default; e.g. if ?action=diag or ?action=ruleset or 
something like that.

For example, perhaps something like the following in PmWiki's Markup()
function (this is completely untested!):

    function Markup($id, $when, $pat=NULL, $rep=NULL) {
      global $MarkupTable, $EnableMarkupDiag;
      if ($EnableMarkupDiag && preg_match('!/[^/]*e[^/]*$!', $pat)) {
        var_dump(debug_backtrace());
      }
      # ...

So, when a recipe calls Markup() with a pattern containing an 'e'
modifier after the last slash, it produces a backtrace showing the
file and line that called Markup().  I'm sure the output can be 
vastly improved beyond doing a simple var_dump, but I'll leave 
that to others to work out.  :)

Pm



More information about the pmwiki-users mailing list