PmWiki
Talk about easy...
I've got some projects I want to do, and one of them requires a simple CMS. When I heard about PmWiki, my heart nearly skipped a beat -- here was an open source, PHP v4-compatible, and flat-file based wiki!
I just had to try it!
I did some checking around on the PmWiki website. Unlike a lot of open source projects, this one is pretty well documented -- one of the benefits of a project built for people who want to write documentation, I guess!
The feature-set looked pretty thorough; it has the features I was looking for, and then some. Due to the deliberate modular design, PmWiki has a wide variety of "plug-ins" or "add-ons"; in PmWiki parlance, they're called "recipes". And of course, recipes belong in a cookbook. Here you'll find a variety of items, including CMS, blogging, multimedia tools, RSS recipes, and one I'm anxious to investigate even more, security and authentication recipes.
Another subset of the cookbook is the skins area -- one thing I think is really important with just about any modern web site or project. This area is full of a lot of creativity.
So, last night I tried installing it. Download kits are available in both tar.gz and zip formats (I grabbed the zip). Unzipping the file (using Info-Zip's 6.0 beta, which handily deals with ODS-5 volumes and extended file names) resulted in a subdirectory with the kit's version number (with lots of periods) in the name. I changed the name to shorten it, then launched my browser pointing at the pmwiki.php file therein.
I went through the initial setup, creating the [.wiki^.d] subdirectory (the first time through, I forgot to apply an ACL to allow Apache access. Tappity-tap, refresh, and poof, no errors! Since this contains the wiki itself, don't forget to make this directory writable.) I copied the config.php file to the [.local] directory as suggested, did some edits, but couldn't see the appropriate changes. You guessed it (well, maybe you did) -- I needed to set an ACL on this file, too.
I then grabbed a skin as a test. This time, I rememberd to set the ACL before it became a problem, and things worked as advertised. Skin management is a simple matter of creating a new directory in the [.pub.skins] subdirectory, then editing a single line in the config.php file to point to the new skin. That's how things should be!
You can view the installation in my playground here. No guarantees that this link will remain up for long, but feel free to kick the tires on it if you want.
To give you some idea of performance, this system's an AS800 5/400 with 256MB of RAM, and the net connection is about 350Kbps. Don't expect too much as far as performance, but that said, PmWiki still performs admirably.
Throughout this entire process, I didn't come across a single error or U*X-ism that caused me grief. If you're looking for a quick and simple wiki for documentation or CMS that you want hosted on OpenVMS, I give PmWiki 5 stars!
19 comments:
Impressive indeed. I’ll chack it out.
SYSMGR (URL) - 06-Mar-2008 - 02:01
Can you specify which version of PMWiki you used for your test ?\nI have used 2.1.27 and not had the same success (it creates the basic wiki page, but not all the links down the side to the documentation and it is not editable).\nDid you use the latest beta version ?\n
Chris - 04-Nov-2008 - 23:39
Hi Chris. Looks like I’m running 2.1.27, too. The trick to make the files editable is to check the security settings—not just of the files, but also the parent directory. So, for example, I had to set an ACL on .flock (and other files) to allow Apache$WWW R+W+E+D+C (the C is required for the ubiquitous U*X chmod commands), and also on the parent [.wiki^d], set it to R+W+E. I didn’t bother setting the protection mask (World is too coarse a granularity for my taste), just an ACL.
BTW, be sure to set version limits on files like .flock—they can quickly generate hundreds of versions if you’re not careful. Plus, on an active system, you could quickly reach 32767, so renaming the file to lower version numbers on a regular basis would be advised.
[Aaron] () (URL) - 06-Nov-2008 - 21:44
Thanks for that Aaron.
I didn’t have the “C”ontrol access, so I tried that but still no luck.
I tried starting from scratch, ensuring the security settings were ok and still no luck.
I don’t get any errors, but when the pmwiki.php script runs, it presents the basic screen with the Pmwiki icon in top left hand corner, then just the “Edit” “History” etc. options along the bottom. None of the cookbook stuff etc shows up. When I select “Edit” option, nothing happens.
I am obviously missing something else, but not sure what.
Chris - 08-Nov-2008 - 21:16
Did you set the local.dir and wiki^.d.dir directories to allow R+W+E+D access in the ACLs? (+C for those items therein where the code tries to do a chmod, obviously.) Note you’ve got to set the protections on the directories, not just the contents.
What version of PHP and which webserver? I’ve run this under 2 versions of PHP 1.3 now, the latest being the most current version. I’m running Apache 2.latest here.
[Aaron] () (URL) - 08-Nov-2008 - 21:31
I had forgotten the local.dir, but after fixing this, still no joy.
We are running Itanium versions of the latest CSWS211_UPDATE V2.0 and CSWS_PHP13_UPDATE V2.0
Not really sure how you determine which files the code tries to do a chmod on, so I have made CONTROL the default for all files create in local.dir and wiki^.d.dir. In fact apache$www is the owner of the directories, and has full rights (RWEDC) to directory file as well. I have done this all the way back up to the [000000] level directory.
Chris - 08-Nov-2008 - 21:59
Well, it might be time to wheel out the big guns and enable audit alarms for file access failures to see what’s blowing up. In my case, I had the files in my personal [.Public_HTML] dir, and since I was the owner, had to set ACLs explicitly for Apache$WWW to access the files.
And as far as figuring out which files needed C access for chmods, it’s primarily any file that the sw creates for configuration purposes. You can tell for sure by the errors returned—you’ll see errors just like those described above.
[Aaron] () (URL) - 08-Nov-2008 - 22:44
Thanks for all your help so far Aaron.
Unfortunately, I still don’t seem any closer.
I turned on alarms as per “set audit/alarm/enable=(access=failure)” and after that “set audit/alarm/enable=(create) and tried things. This did not show up anything untoward.
A couple of questions on a different tack..
– what should I see on the pmwiki page straight after running the pmwiki.php for the first time ? (I have assumed I should see more than almost a blank screen and something more like what is in your playground area mentioned in the blog)
– what PHP modules do you have turned on ? (perhaps I am missing something here)
Chris - 11-Nov-2008 - 21:05
Yes indeed—there should be a lot more than just a blank screen. The default page, while not exactly like what I have, is close. You did run through the entire setup process, right? Especially the “Initial Setup Tasks”?
The php modules I’ve got loaded are:
- php_exif
- php_gd
- php_pcre
- php_session
- php_xml
[Aaron] () (URL) - 12-Nov-2008 - 11:14
I did go through the “Initial Setup Tasks” way back when I first tried, but realised that this was just allowing me to change how the wiki displayed incorrectly. I figured that after doing the initial create of [.wiki.d] directory, the basic screen should already be there, instead of just a couple of menu items. Once the initial pmwiki.php execution has happened, I am getting the [.wiki.d] directory created with 1 or more .flock files in it, but nothing else…I have assumed that this is incorrect…but is it ?
Also I noticed I don’t have the php_exif module loaded, so I uncommented this in php.ini. No difference.
The other one I don’t have is php_gd, which isn’t even in my php.ini. Is this something I need to pick up outside of the standard HP distribution ?
Chris - 12-Nov-2008 - 17:44
EXIF and GD are for image processing, and probably not at all pertinent to PmWiki. The GD module was added in 1.3, and that was the only version ported to Itanium, so I’m not sure why the GD module’s not showing up in your .ini file. I’ve got to consider this some more—I may email you offline…
[Aaron] () (URL) - 13-Nov-2008 - 10:06
Have solved the GD issue. The .EXE is there, it just wasn’t in my php.ini file – I imagine I missed it when I compared new wuth my old. I have added in now.
I have also noticed that when I access the pmwiki.php file ie http://myserver/mydir/pmwiki.php it logs a 404 error in access_log.; although no errors display in the browser. I would guess it is getting so far in the pmwiki.php script and then trying to access a file that it can’t find or can’t access, hence I am only getting a partial screen displayed. I think I may have to look at the script to see if I can spot something….
Chris - 13-Nov-2008 - 20:07
Yeah—thanks for the heads-up on the pr0n. Fixed that. The site has a default site.sidebar, so all I had to do was delete the pr0n-filled one, and it regenerated a new one next time I tried to edit it. I then set the security on all the files to prevent any more editing.
Like I said, this was just a test-bed, and I deliberately left it unprotected knowing that someone would eventually find it and take advantage of it. Glad to have learned something!
[Aaron] () (URL) - 15-Nov-2008 - 09:33
I have finally worked out my problem. Hooray !
I used Unzip (Info-Zip) version 5.52 to unzip the files to their directories. It doesn’t seem to handle directory names with a ”.” in them, or perhaps I didn’t have parse=extended bfore I did it. Anyway, the unzip created a directory called “wikilib_d” instead of “wikilib^.d”, hence pmwiki couldn’t see any of the standard files.
Once I renamed the directory accordingly, everything started to work.
It’s amazing what a couple of weeks off can do for you !
Cheers,
Chris
Chris - 14-Dec-2008 - 23:36
Hi, I am also suffering from a configuration issue with PMWIKI. When I try to access pmwiki.php via my web browser, I see the error message:
Fatal error: Call to undefined function: preg_match() in /www$root/pmwiki/pmwiki.php on line 41
I have checked my directories, permissions etc, but am scratching my head now to find out where I am going wrong. Can you suggest anything?
Thanks,
Mark
Mark - 15-Jan-2009 - 08:07
Hi Mark,
In the apache$root:[php]php.ini file, make sure that the php_pcre module is uncommented – I think the preg_match function comes from this module. While you are at it, look at the pmwiki install guide and check which other modules need to be uncommented…I reckon there was one or 2 others I had to do (as well as one or 2 I couldn’t find!).
Cheers,
chris
Chris - 15-Jan-2009 - 16:38
Yes, that did the trick. I had ‘uncommented’ the line in one php.ini file, but missed another php.ini in the site specific directory.
It’s working ok now.
Thanks for your help.
Cheers,
Mark
Mark - 16-Jan-2009 - 03:21
Has anybody tried to run PmWiki (or another wiki) on WASD? It seems it doesn’t handle wiki.d as a single directory name, but as wiki/d.. so I’ve tried to change all wiki.d references in source to wiki_d. Now I’m getting flock problems 
Any idea? Is there any VMS-friendly kit that is already patched to work properly?
tmr - 28-Feb-2009 - 08:54
I would say that you probably have a WASD configuration issue in regards to it not handling the directory name properly, and would approach it from that angle, rather than change the pmwiki code.
Having said that I have not used WASD to be able to suggest anything pertinent…
You can find contact info here http://wasd.vsm.com.au/
cheers,
chris
Chris - 02-Mar-2009 - 21:34
No trackbacks: