[pmwiki-devel] Pmwiki bug with ZAP chat...

[The Editor]

On 11/11/06, Crisses <crisses at kinhost.org> wrote:
> On Nov 10, 2006, at 2:55 PM, The Editor wrote:
>
> > Working on a fairly simple ZAP snippet--and get this error on my
> > server, but not on my home machine.  Any ideas?
> >
> > Warning: session_start() [function.session-start]: Cannot send session
> > cookie - headers already sent by (output started at
> > /home/fastst/public_html/zap/pmwiki.php:951) in
> > /home/fastst/public_html/zap/cookbook/zap.php on line 452
> >
> > Warning: session_start() [function.session-start]: Cannot send session
> > cache limiter - headers already sent (output started at
> > /home/fastst/public_html/zap/pmwiki.php:951) in
> > /home/fastst/public_html/zap/cookbook/zap.php on line 452
> >
> > Line 452 in zap is the place that sets the session variables that
> > secures the form from forged headers. Never noticed this problem
> > before.
>
> Can you show us the section of code?
>
> If you even put a space outside the "?> <?php" it would ruin the
> header output for PHP.  So it could be something really simple.


Hi Crisses!

Below is the sidebar markup, and the zap code connected with this
problem.  If I delete the zapforms the warning goes away.  Sometimes
it goes away by itself if I refresh, etc.  I'm not using any new
fields in these forms that don't work elsewhere in ZAP.  And the code
works perfectly on my home machine. You can see the error at
http://www.fast.st/zap/pmwiki.php?n=Chat.Test, sometimes.  BTW the
chat forms still works...

The (:zapform:) directive does set a session variable that stores
information about the forms to secure them from forged headers, but
that is true on every zapform.  I did rework that markup a small bit,
but the only line that produces any output in the function is the very
last line, after the session variable is set.

I've checked my cookbook and there's not another recipe anywhere
setting any session variables.  It seems for some reason PmWiki is
putting out output (that's what line 951 does in PmWiki) before the
markup is fully processed.  Could this be some kind of bug in PmWiki?

Cheers,
Caveman

__________________________________

(:if exists Chat-{$Name}-Members.{$AuthId}:)
(:zapform:)
(:input hidden datapage "Chat-^-Talk. at -+":)
(:input hidden chatter "{$AuthId}":)
(:input textarea cols=15 rows=7 name=talk:)
(:input hidden savedata "talk,chatter":)\\
(:input submit value="Chat":)
(:zapend:)

(:zapform:)
(:input hidden destroy "Chat-{$Name}-Members.{$AuthId}":)
(:input hidden nextpage "Snippets.Chat":)
(:input submit value="Leave Room":)
(:zapend:)

(:if ! exists Chat-{$Name}-Members.{$AuthId}:)
(:zapform:)
(:input hidden join {$AuthId}:)
(:input hidden room {$Name}:)
(:input hidden nextpage Chat.{room}:)
(:input hidden create Chat-{room}-Members.{join},Chat.{room}:)
(:input hidden passdata join:)
(:input submit value="Join room":)
(:zapend:)
(:ifend:)


Here's the pertinent sections from ZAP:

Markup('zapform', '>{$var}', '/\(:zapform(.*?):\)/ei', "ZAPform('$1')");

function ZAPform($d) {
   global $pagename;
   ...
   session_start();
   $_SESSION[ZAPlock]["$pagename-$GLOBALS[AuthId]-$x"] = $l;
   return "(:input form$u$o:)\n(:input hidden action zap:)\n(:input
hidden ZAPkey $x:)\n";
   }