Wolf CMS - Stable Release: 0.7.5
You are not logged in. Please login or register.
Plugin - userDocumentation
Originally created for FrogCMS
----------------
userDocumentation
Current Version: 0.1
Updated: Sept 1.2010.
----------------
Some text in the backend to help web users to remember how to use your site. Alter and extend at your pleasure.
Hi Ben - thanks for this!
I just took a quick look, and here's a bit of quick feedback!
- I could see this being of value for providing some "in-admin" general help for "clients" of whatever kind when handing over a site.
- would it be worth actually providing something in the "sidebar.php" view, so that the plugin user has a base to work from? Have a look, for example, at Wolf's (core) "Skeleton" plugin which provides just this.
- it would be good to update this documentation plugin for Wolf 
Hope that helps!
Thanks for your reply,
This is my first plugin so appreciate the feedback, will look into it and give a v0.1.1 soon.
Does the wiki have (or plan to have) an API?
I was thinking of a similar documentation plugin, but it makes sense to at least provide access to a central documentation to help ensure that it is kept up-to-date!?
Last edited by BlueWolf (2010-09-06 14:22)
If it does not have a API we can allways use file_get_contents or some other means of getting remote data. At least that should insure that the documentation is up to date.
Last edited by Fortron (2010-09-06 18:48)
The wiki is running the Dokuwiki software. Not sure if that has a PHP api that allows external programs to retrieve content. (which is what you mean I suppose?)
Did a quick search, but couldn't find anything on it. Also, while I find it a reasonable idea... it would potentially create a lot of load on the system, or at least eat up bandwith. 
Which I don't particularly mind either by the way but since I'm still the only one funding the hosting, apart from one individual who made a small donation (thanks again by the way!), it would be considerate to ask. 
Edit: I found that Dokuwiki provides an experimental(!) xmlrpc interface. However, I'm not a big fan of using that since it would allow third-party systems to edit content. Which is quite something else than allowing edits through the Dokuwiki UI in terms of security.
Last edited by mvdkleijn (2010-09-07 13:33)
it would potentially create a lot of load on the system, or at least eat up bandwith
Hmm, perhaps it could cache the content to the local server/synch when first installed. Then only pull/update content if a basic date comparison doesn't match!? Just a performance idea to work around the load.
But generally, I hadn't even thought to take that into consideration, Martijn. Good call, as always.
Hmm, perhaps it could cache the content to the local server/synch when first installed. Then only pull/update content if a basic date comparison doesn't match!? Just a performance idea to work around the load.
But generally, I hadn't even thought to take that into consideration, Martijn. Good call, as always.
Well, when you work in a big web environment like I do, you tend to think of nasty things that might happen.
Anyway, a basic (date) comparison might work. Maybe some sort of hash value based on the page contents, dunno. Whatever comparison system is thought of, it'd have to be a server side thing since you'd only want to download the current date / hash / crc value or whatever, not the whole page.
A completely different approach (well sort of) would be to look at the possibility of dokuwiki creating some sort of local, static export. If possible, that cron job could be run once a day or even two days (the docs don't change that often after all) to create the static html pages. A second part of the cron job could create a simple list of pagename <=> hash/crc value combinations.
The plugin could then download that relatively small list and check the hash values it stored from previous updates to the most recent hash values. Upon detecting a difference, it'd download the relavant static page(s).
But this would require dokuwiki to generate static exports and include a 1-2 day delay in documentation updates.
Anyway, just some thoughts to take in.
Posts [ 8 ]