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 _______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users