00901: pagelist and searchbox wont work anymore
Description:
Since Version 2.2.0-beta29 a normal pagelist doesn't work anymore, no results will be showed. But (:pagelist:) have to show every page, right?
Also the searchbox doesn't show any results.
It's also on a system with linux and PHP 4.4.2-0.dotdeb. Both wikis are not reachable from the outside.
What went wrong? On pmWiki.org searching and pagelist is ok. What has changed, that it won't work everywhere? In beta28 everything is ok.
A quick run through the codes leaves me thinking that the problem has to do with permissions.
In scripts/pagelist.php, line 240
if (!$page['=auth']['read']) $opt['=protectexclude'][$pn] = 1;
seems to flag every page as excluded - at least, commenting this line restores normal behaviour.
--ionos
Having the same problem here, using pmwiki with the standalone server from Cookbook.Standalone. Since beta29 there seems to be an experimental caching system for pagelists, which is probably the cause.
I made a dir named cache in the pmwiki dir, and typed $PageListCacheDir = 'cache/'; in config.php (see ReleaseNotes#ptvend) , and the specified directory does get filled with .txt files with pagelists in them. When I do some test searches I also see new files appear in the directory, containing the right pages for the searches, but still these searches all show 0 pages found in pmwiki.
After I refresh the page once the pagelist works afterwards, but as soon as I make a new page, again the pagelist shows 0 results until I do a new page refresh of the page containing the pagelist.
Lennert
Thanks, that seems to be it... I'm having the same problem here (but replied on PITS.00902, which is now copied above ThomasP)
I'm using UserAuth here, maybe that's causing it? Are you using this same recipe?
What I don't understand yet is that, like I said on PITS.00902, after a page refresh it also works as normal, even with this if-statement still active. (This behaviour is usually due to internal caching of page lists. ThomasP)
BTW, it would be better to merge PITS.00902 with this thread, because it's a doublepost, anybody knows whether this is possible without messing up PITS?
Lennert
Noticed the same problem. I will update UserAuth2 as soon as I know what has to be done.
ThomasP May 19, 2007, at 08:47 AM
This is resolved now by updating UserAuth2 to version 2.0-stable4. If you use UserAuth (i.e. the former module), there will be no fix. For this case I recommend either to switch to UserAuth2, or as a quick and slightly unsafe hack to add
$page['=auth']['read'] = 1; $page['=passwd']['read'] = 1;
to the page variable close to every return (look for ReadPage) in userauth.php.
ThomasP May 21, 2007, at 12:53 AM
If using the Cookbook.PerGroupSubDirectories recipe, pagelist with group=.. or name=Group.* no longer works at all!
It seems like the internal PageList function traverses the group subdirectories but fails to include the subdirectory name in the name of the found page, resulting in something that does not match the pattern constructed from the group= or name= attributes.
--krisku Aug 22, 2007
For some of the above discussion, I can't tell if there's still a bug in pagelist (either with or without the standalone server).
For the issue of the Cookbook.PerGroupSubDirectories recipe, the current recipe is wrong (2007-11-14). PmWiki doesn't support storing page files where the $Name and $Group components are separate, for precisely this reason. If someone can figure out an easy way to extract group and pagename from the a filename in the case where they are separate, let me know.
(The likely answer is that one would have to provide a match pattern to the PageStore object to tell it how to parse the resulting filename, or we'll have some lookups to figure it out.)
In the meantime I'm closing this ticket as being not a bug. Feel free to open a new ticket if there are still issues with pagelists.
-- Pm November 14, 2007, at 03:36 PM