[pmwiki-users] New recipe: Fox

[marc]

marc said...
> Patrick R. Michaud said...
> > On Tue, Dec 19, 2006 at 07:20:17PM -0000, marc wrote:
> > > Hans said...
> > > > Tuesday, December 19, 2006, 6:24:18 PM, marc wrote:
> > > > 
> > > > > So, the question is - probably for Pm - in what circumstances can 
> > > > > UpdatePage receive identical input, yet produce different results?
> > > > 
> > > > I take it that your problem with page save is only with fox.php, and
> > > > you can save pages fine from the normal edit window.
> > > 
> > > Yes.
> > > > 
> > > > I don't know if calling the Lock function does make a difference,
> > > > i.e. HandelEdit calls Lock before calling UpdatePage, in fox.php Lock
> > > > is not called. When Pm wrote about how to use UpdatePage he did  not
> > > > mention Lock. But it may be an idea to try and add Lock(2); at the
> > > > beginning of FixHandlePost, and Lock(0); at the end of the function
> > > > before Redirect, and see what happens? Just guessing, as I have no
> > > > clue.
> > > 
> > > My method is always to isolate the problem, then start hacking :-) 
> > > Hopefully, the issue will be obvious once isolated.
> > 
> > I don't know if this is the issue, but there's at least one big
> > nasty potential bug in fox.php:  all of the calls to RetrieveAuthPage()
> > are passing READPAGE_CURRENT, which means that any page history
> > is being lost when UpdatePage() is called.  
> > 
> > The READPAGE_CURRENT value says "give me only the most recent 
> > version of the page without any page history", so then UpdatePage() 
> > doesn't have the page history available to save along with the page.
> > 
> > Again, I don't know if that's related to the current issue, but
> > it's at least something to be looked at.
> 
> Unrelated to your post, Pm, but I want to continue the thread...
> 
> The problem is that $Author is empty on entry to author.php - obviously 
> I'm entering an author value in the form's author field. (Since, $Author 
> is set to $AuthId when logged in, this is not an issue in that case.)
> 
> So, my question is: where does fox.php expect $Author to be set to the 
> value from the form, $_POST['author']?

A breakthrough of sorts. I noticed on the clean PmWiki installation 
(the only recipe is fox,php, so no authuser.php) that author.php was 
setting $Author - as you would expect. However, On my main test PmWiki 
installation this was not the case. This is because, after

  include_once("$FarmD/scripts/authuser.php");

in farmconfig.php, there is

  $Author = $AuthId;

so that $Author is set. Thus, the section of author.php that uses $_POST
['author'] to set $Author is never called:

  if (!isset($Author)) {
    if (isset($_POST['author'])) {
      $x = stripmagic($_POST['author']);
      setcookie($AuthorCookie, $x, $AuthorCookieExpires,
                $AuthorCookieDir);
    } elseif (@$_COOKIE[$AuthorCookie]) {
      $x = stripmagic(@$_COOKIE[$AuthorCookie]);
    } else $x = @$AuthId;
  $Author = htmlspecialchars(preg_replace("/[^$AuthorNameChars]/",
            '', $x), ENT_QUOTES);
  }

By removing

  $Author = $AuthId;

I can force author.php to set author from $_POST['author'] and create a 
comment while not logged in.

This is not solution, because removing $Author = $AuthId will break 
other things.

(Note that this does not explain why leaving $Author = $AuthId in place 
on Linux works okay, and, since this is not relevant to a clean PmWiki 
install, it doesn't explain behaviour there either!)

-- 
Best,
Marc