[pmwiki-users] Latest ZAP release

[The Editor]

Just released a slightly updated version of ZAP.  This fix allows you
to have multi-line text vars by changing the format for how data is
stored.  You will need to update any ZAP pages you have created since
ZAP first started saving on the same page (late beta).  It will,
however, read FAST Data pages.

Also, ZAP now allows you to hide data, by flagging fields you wish to
hide in a format text vars cannot read but ZAP can.  This is to
prevent someone from snatching your email or password by using a text
var in some page they edit or even in an input field of a ZAP form.
Of course, it will not help if you give someone edit access to a page
that has ZAP enabled.  So be careful.

Any way, this solves a problem I've been chewing on regarding how to
deal with member profile info, and it now allows one to completely
separate data and structure for fully updatable comments, forums,
blogs, etc.  Really nice.

I've been putting up more snippets all the time and encourage you to
give them a try.  www.zapsite.org.  Some of these snippets show things
you can do I never initially envisioned for this recipe but which are
very powerful.  Share your snippets/thoughts too!

Cheers,
Caveman

PS.  Lastly if anyone can help with the questions below I'd appreciate
it.  I will repost again the questions from a few days back.



---------- Forwarded message ----------
From: The Editor <editor at fast.st>
Date: Oct 22, 2006 4:58 PM

[snip]

I) guess I misunderstood how htmlspecialchars worked.  I thought it
parsed form submissions after they were received by the engine for
processing. Looking over the php docs more closely I take it now that
it should be used when creating forms input markups, to prevent bad
data from being sent to the engine. If so, the following would need
need
to be fixed:

    Markup('select', 'inline', '/\(:select (.*?):\\)/', '<select name=$1>');
    Markup('textarea', 'inline', '/\\(:textarea (.*?):\\)/e',
"Keep(PSS(\"<textarea $1>\"))");

I took a stab at it, but not sure I got them right. I wouldn't even
know how to test if it was right!  : )  Do these look ok?

    Markup('select', 'inline', '/\(:select (.*?):\\)/',
"htmlspecialchars(\"<select name=$1>\")");
    Markup('textarea', 'inline', '/\\(:textarea (.*?):\\)/e',
"Keep(PSS(htmlspecialchars(\"<textarea $1>\")))");

I also presume these are all ok, with no need for change...

Markup('option', 'inline', '/\\(:option (.*?):\\)/e',
"Keep(PSS(\"<option value='$1'>\"))");
Markup('selectend', 'inline', '/\(:selectend:\\)/', '</select>');
Markup('textareaend', 'inline', '/\(:textareaend:\\)/', '</textarea>');

2) I have these lines in my code, yet I'm still getting slashes.  Any
suggestions?

  foreach ($_POST as $field => $value) {
      if (get_magic_quotes_gpc()) $_POST[$field] = stripslashes($value);

Evidently they are in the form submission, because they show up when
the data values (fields) are saved on the page.  They can be seen when
retrieved using regular text variables.  They are created both with
PmWiki's (:input text:) and ZAP's (:textarea:) input.  They occur on
my server (linux), but not on my home machine (XP). Would the
slashmagic() work better? I'm wondering if perhaps it is a problem
with the markup?  the /e part? (But then why the problem with Pm's
markup?)  Don't like slashes!

3) I noticed this pattern does not seem to be working either (it comes
right after the stripslashes line above.  (I know the conditional is
being met because line 3 is processing properly). Anyway, this line is
supposed to disable pmwiki directives, but it's not.  Is there a typo
somewhere?

   ->       $_POST[$field] = preg_replace('/\\(:/', '(&#x3a;', $_POST[$field]);