This is sorta unfortunate, but I don't want turning the plugin on the cause
php to be forked unnecessarily. And moving them back to the plugin page
doesn't make sense in this case.
The info about the cron job was lost (!), as was a paragraph about what
pages the calendar links to.
The CSS docs seems to fit better in the plugin page than the directive
page, moved it back.
As was noted, 'listdirectives' didn't include the underlay files that make
it really worthwhile. I've just gone through all the plugin
documentation, modified it to remove installation information and renamed
the files to match the directives rather than the plugins. This can now
serve as useful underlay.
I've only gone through plugins in the 'plugins' dir. I did not go through
the 'contrib' dir.
Reasons include:
- easier to type
- might want postprocessor directives again sometime, and listdirectives
can then use the directive/* files for either
- that it's done as a preprocessor step is an internal detail (and not a
very accurate one, really :-)
It makes no sense to have robots index these pages, so inform them that
they should not. We still tell them to follow the links, obviously.
Signed-off-by: martin f. krafft <madduck@madduck.net>
Add a prefix_directives option to the setup file to turn this syntax
on; currently defaults to false, for backward compatibility. Support
optional '!' prefix even with prefix_directives off, and use that in
the underlay to support either setting of prefix_directives. Add NEWS
entry with migration information.
* Plugins can add new directories to the search path with the add_underlay
function.
* Split out smiley underlay files into a separate underlay, so if the plugin
isn't used, the wiki isn't bloated with all those files.
Joey Hess
William Uther
martin f. krafft
Josh Triplett
Joey Hess
joey