00408: Why does `PmWiki handles uploads/ and wiki.d/ differently?
Description: Why does PmWiki handles uploads/ and wiki.d/ differently?
All files in in /uploads are neatly stored in their respective Group Directory whereas all wiki pages are dumped in single wiki.d/ directory. Shouldn't the method how the wiki engine looks-at/stores/retreives files be in a uniform or similar fashion. i.e All uploads under uplaods/Group/ and all wiki pages under wiki.d/Group/
To me files under uploads/ and wiki.d/ are just files. One is downloaded/uploaded while the other is read/written on wiki page itself (and ofcourse they differ in Mime).
I know its too late to bring this up. Kinda major architectural change ;-) plus lots of pmwiki Admins may not like such major change, But in which case lets have this PITS entry as a food for thought.
For more digestive minds, here are some benefits for having Group named directory in wiki.d/ :
- It eases admins work (easy backup and restore).
- Apache based locks would be possible for each wiki groups.
- Neater organization.
- Easy for cookbook receipe writers for handling specific group related issues.
- This would introduce a directory wiki.d/Category. Thus possibility for better logistics for handling/searching categories.
- .....did I miss something. :-)
Though way back there were some local based solutions given in v.1 days and in newsletters, but this probably has been never been brought under consideration for v.2. In contrast PITS.00281 relates to PmWiki.HierarchicalGroups, whereas this `PITS the way the existent wiki pages are stored in comparision to upload files.
Well, yes, you missed something. :-) First, uploads/ isn't required to be organized by groups -- an administrator can use $UploadPrefixFmt to change the organization to be sitewide or per-page -- see Cookbook:UploadGroups. So, we'd only be uniform as long as the administrator hasn't modified the default settings.
Second, an administrator is able to change the organization of wiki.d/ to use per-group subdirectories via the following line in local/config.php:
$WikiDir = new PageStore('wiki.d/$Group/$FullName');
This causes each WikiGroup to be given its own subdirectory within wiki.d/. This is commonly done on several very large PmWiki sites, where we hit the limits on the number of files that can be reasonably stored in a single directory (i.e., sites with >15,000 pages).
So, PmWiki really does what you want already, it's just not the default configuration. :-)
--Pm
- Backup/restore isn't much different between the two methods;
- Apache locks make absolutely no difference to PmWiki (and I can't imagine that people want to make the wiki.d/ files available directly via Apache);
- "neater organization" is a matter of preference -- some (i.e., me) find the one-directory version easier to work with;
- it doesn't (shouldn't) make a difference to Cookbook authors, who normally ReadPage() and WritePage() to access page files (not all PmWiki installations store their page files in wiki.d/ anyway)
- it doesn't currently help searching of categories, as all of the pages (in all groups) have to be searched to find category membership anyway