[pmwiki-users] can't edit after upgrade
rich.talley at gmail.com
Sun Jun 12 17:51:42 CDT 2011
Better solution: make both wiki.d and wikilib.d world writable. Upgrade then
processed correctly. I needed to make a link on Site.Site point to the new
page on Site.Admin. Otherwise the upgrade looks good.
I was able to set the permissions on wiki.d to 775 and wikilib.d to 755, so
the site is no longer so wide open. It was only for the upgrade that I had
to set each of them to 777.
Now I can start looking at some recipes.
On Sat, Jun 11, 2011 at 11:13 PM, Richard Talley <rich.talley at gmail.com>wrote:
> OK. First a note on permissions.
> I had read the PmWiki page on permissions.
> "On a Unix host the webserver typically runs with a userid and groupid that
> is different from the account holder."
> So the permission are usually set:
> directories except pub/ and uploads/ 755
> files 644
> pub/ and /uploads 777
> But in our case, the user account I use to administer the site has been
> configured to be in the same group that the Apache server is in.
> So I should be able to use:
> directories except pub/ and uploads/ 750
> files 640
> pub/ and /uploads 770
> And in fact that works, on the production site that's running PmWiki
> So, I tried a different tack. I copied the working site to the test site,
> but set the permissions back to the usual case (755/644/777) and confirmed
> that all uses of $FullName in Site.PageActions are changed to *$FullName.
> Site works, of course.
> I apply the upgrade. Now I see something I should have seen before, but
> didn't. I get an upgrade notice about relocating Site.ApprovedUrls ->
> SiteAdmin.ApprovedUrls. When I click on the 'Relocate pages listed above'
> button, I get caught in a loop:
> "PmWiki can't process your request
> Cannot write page to SiteAdmin.ApprovedUrls
> (wiki.d/SiteAdmin.ApprovedUrls)...changes not saved"
> Which has a link back to the test site, which offers to 'Relocate pages
> listed above'.
> So I manually copied Site.ApprovedUrls from the production site to the test
> site as SiteAdmini.ApprovedUrls.
> Now PmWiki complains:
> "PmWiki can't process your request
> Cannot acquire lockfile"
> So I deleted the .flock file in directory wiki.d on the test site.
> No change. I continue to be unable to access the site, because PmWiki
> complains it cannot acquire lockfile.
> I'm stuck. I have a production site running 2.1.27 which works fine, but I
> have a test site which has a copy of the production site which as been
> upgraded to 2.2.26. I can't access this site.
> Solution: leave production site running 2.1.27 and forget about upgrading.
> -- Rich
> On Sat, Jun 11, 2011 at 2:59 PM, Richard Talley <rich.talley at gmail.com>wrote:
>> Hi All,
>> I recently took over administration of a site using PmWiki 2.1.27, so it's
>> long overdue for an upgrade.
>> I carefully read through the release notes for all the changes from that
>> version up to the current version, 2.2.26.
>> It appears that the major change that would affect this site is
>> making $EnableRelativePageVars on by default.
>> First I copied the entire installation to a test site, changing $ScriptUrl
>> and $PubDirUrl appropriately. I double-checked that all file permissions and
>> ownerships were identical to the original site. Test site came up and
>> functioned correctly.
>> In looking at the installation, I determined that the only thing that
>> would be affected by the change in $EnableRelativePageVars would be
>> PageActions, so I edited all the PageActions to use *$FullName instead of
>> $FullName. Test site continued to function correctly.
>> I then applied the upgrade. Now I can't edit any page. I don't get asked
>> for the password.
>> If I go to the Site page, I get asked to give my Site Administration
>> password, but I can't edit anything there either.
>> Any suggestions?
>> -- Rich
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pmwiki-users