[pmwiki-devel] Strange keywords and description behavior...

[Patrick R. Michaud]

On Thu, Apr 05, 2007 at 08:14:20AM -0400, The Editor wrote:
> Second post.  Quite strange...

While we do indeed invite people to re-post questions that haven't
received an answer, it would probably be good etiquette to wait at
least 24 hours (and 36 or 48 hours is probably better) for an answer 
before reposting...

> [Fourteen hours earlier] The Editor <editor at fast.st> wrote:
> > I'm noticing some rather buggy behavior after all with the new ZAP
> > attr extensions.  Can't explain.
> > ...
> > Heres' the critical two lines....
> >
> > if (strpos($newpage[text], "(:$attr ")) $newpage['text'] =
> > preg_replace('/\\(\\:'.$attr.'(.*?)\\:\\)/s', "(:$attr $value:)",
> > $newpage['text']);
> > else $newpage['text'] = $newpage['text'] . "\n(:$attr $value:)";

I think the error must be somewhere other than these lines of code.

 - if the page source begins with "(:$attr ", then strpos(...) will
   return zero, the "if" condition will fail, and a second copy
   will get added to the list.  When using strpos() to test existence
   of a substring, always check the return value against "false".

 - The quotes are missing around "text" in "$newpage[text]"

 - You probably don't want the /s option on the preg_replace pattern,
   as this causes .*? to match newlines.

 - Because there's no required space in the preg_match pattern,
   it will replace anything beginning with "(:$attr".  For example,
   (:zap attr_title:) would end up replacing anything that
   begins with "(:title", including (:titlespaced:), (:titledict:),
   (:titlexyz:), etc.

 - The colons in the preg_replace pattern don't need backslashes
   (although it shouldn't hurt).

But none of these would seem to explain the results you're seeing,
which is why I think the error has to be somewhere other than these
lines of code.

Pm