[pmwiki-users] Blog feature request.

[Joachim Durchholz]

Stirling Westrup schrieb:
> 
> Anyway, that said, I'd like to request a feature for the new blogging 
> software. [...]
> 
> It would be far preferable though, if I could have some sort of hidden 
> (author-access only) queue group

No problem with that - adding a group-specific password for 'read' is 
already built in.

 > to which I could pre-publish articles
> and from which they would automatically get pulled at regular intervals 
> and posted to the main site.

Executive summary:

It's doable, but hasn't been done.
Doing it would be major work. Don't hold your breath.
(Oh, and don't take my word for it. I'm looking at things from an 
engineering perspective, which means that I tend to overlook quick&dirty 
solutions that "just do the job".)


Details:

The standard way would be to set up a cron job and have it post the 
article at the pre-appointed time.
Problem 1: There's no cron on Windows. It would be good if the mechanism 
could do that.
Problem 2: Setting up cron is an additional dependency on external 
software, and requires additional administration skills. Again, a no-go 
for PmWiki (unless absolutely necessary).
Problem 3: PmWiki doesn't have a good way to feed articles from a script.

Problems 1 and 2 could be solved, based on the observation that it 
doesn't matter when exactly the article is published, it's enough if, 
say, the config.php script looks at the timetable, checks what scheduled 
actions should have run since it was last called, and runs them. 
(Possible problem here: if the scheduled tasks are many, we risk that 
PmWiki is killed because it uses too much time. In other words, any 
tasks scheduled should be restartable if they failed to complete. Hairy. 
Very hairy. The alternative would be to run the tasks in the background, 
which (1) would run into trouble on a safe_mode setup, and (2) quite 
likely make the current run of PmWiki see a (mostly) old version. Maybe 
we should simply ignore the problem, and tell people to increase CPU 
time limits if they really run into trouble.)

Problem 3 is something that should be solved anyway. PmWiki already has 
interfaces for getting at the data, most work would be documenting 
what's there and whipping up a recipe that describes all the steps 
necessary to programmatically make PmWiki dance (reading config.php, 
acquiring any locks, setting up the page store, reading and writing the 
data).
There might be also some improvements on the PmWiki code itself - I'm 
not sure that everything that's easy from the web interface is also easy 
from PHP. (Probably not. Scriptability hasn't been part of PmWiki's core 
mission. But PmWiki is already close enough that it should be doable 
with relatively little effort.)


Regards,
Jo