If the server has a clock running a bit ahead of the web browsing client,
relativedate could cause somewhat confusing displays like "3 seconds from now"
for just posted things.
As a hack, avoid displaying times in the future if they're less than a
small slip forward. I chose 30 minutes because both client and server could
be wrong in different directions, while it's still close enough that "just
now" is not horribly wrong.
This adds support for gecko and newer versions of opera
to call onload once the DOM is ready, rather than waiting for
all images in the page to load. Makes relativedate behave
somewhat better.
Dealing with this means jumping into the browser
incompatability waters that I prefer to avoid.
Full solutions for most of the major browsers are listed here:
http://dean.edwards.name/weblog/2006/06/again/
However, no *license* is listed there, so I can't use that code. Also, the more
involved code appears to have various issues (such as the inline IE code not
working via https). So I only added the simple call to a hook needed
for gecko/opera.
It seems that the only standards-compliant way to do this is using the
`defer` attribute to a `script` tag, using an external script that will be
loaded once the DOM is ready, and can call onload. However, that has
browser compatability issues of its own, since not all browsers honor
`defer`.
Perhaps I should really just be using one of the javascript frameworks, that
include code to solve this for the major browsers. But something about them
still puts me off, and this issue is minor enough that I'm willing to live
with incomplete support for now.
* Add an underlay for javascript, and add ikiwiki.js containing some utility
code.
* toggle: Stop embedding the full toggle code on each page using it, and
move it to toggle.js in the javascript underlay.
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
Joey Hess
Joey Hess
William Uther
martin f. krafft
Josh Triplett
joey