[pmwiki-users] Blog feature request.
jo at durchholz.org
Sat Mar 18 16:28:52 CST 2006
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.
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".)
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
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.)
More information about the pmwiki-users