| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
These take into account the timezone offset (and convert it to UTC+0000)
rather than being in an unspecified timezone.
|
| |
|
|
|
|
| |
I'm not sure what the use-case is for formatted_time, and chrysn
pointed out that for display in HTML, [[!date "<TMPL_VAR time>"]]
would be nicer.
|
| |
|
|
|
|
|
|
| |
The `time` variable contains a fixed-format time, guaranteed suitable
for parsing by timedate.
The `formatted_time` variable contains the same time formatted by
IkiWiki::formattime.
|
| | |
|
| |
|
|
|
| |
If the template doesn't use <TMPL_VAR UUID> there's no point in
incurring any cost.
|
| |
|
|
|
|
|
|
|
|
|
| |
I want to make GUIDs for my RSS feeds that don't change when I move
pages around. To that end, I've used UUID::Tiny to generate a
version 4 (random) UUID that is presented in a `uuid` variable in
the template.
At that point, you can do something like this:
[[!meta guid="urn:uuid:<TMPL_VAR uuid>"]]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in the Try::Tiny man page, eval/$@ can be quite awkward in
corner cases, because $@ has the same properties and problems as C's
errno. While writing a regression test for definetemplate
in which it couldn't find an appropriate template, I received
<span class="error">Error: failed to process template
<span class="createlink">deftmpl</span> </span>
instead of the intended
<span class="error">Error: failed to process template
<span class="createlink">deftmpl</span> template deftmpl not
found</span>
which turned out to be because the "catch"-analogous block called
gettext before it used $@, and gettext can call define_gettext,
which uses eval.
This commit alters all current "catch"-like blocks that use $@, except
those that just do trivial things with $@ (string interpolation, string
concatenation) and call a function (die, error, print, etc.)
|
| | |
|
| |
|
|
| |
template for a new page.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
plovs reported a crash when templates were not installed properly,
with a non-useful error about the template object not being defined.
I've audited all uses of template_depends(), and template(), and it makes
sense for them to throw an error if the template cannot be found. All code
with a user-supplied template catches errors already, to handle template
parse failures.
It did not make sense for template_file to throw errors, as some code uses
it to probe if a template file is available.
|
| |
|
|
| |
array of things that need built. (Backwards compatability code keeps plugins using the old interface working.)
|
| |
|
|
| |
(still looks in old location for backwards compatability).
|
| |
|
|
| |
does not exist, so it can be easily created.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
for a wikilink (including eg, leading slashes).
Before, the htmllink would display the link to the template as if it were a
wikilink, but what was stored was not, which could lead to confusing
situations.
|
| |
|
|
| |
Also, this fixes 2 bugs in dependency info.
|
| |
|
|
|
| |
Simplify, change default content depends number to 1,
change interface to make more sense.
|
| |
|
|
| |
This one is unlikely to matter much, but yeah, it's contentless.
|
| | |
|
| | |
|
| |
|
|
| |
files rendered during page preview.
|
| |
|
|
|
|
|
|
|
|
| |
Upgrades to the new index format should be transparent.
The version field is 3, because 1 was the old textual index, 2 was the
pre-versioned format.
This also includes some efficiency improvements to index loading, by
not copying a hash and using a reference.
|
| | |
|
| |
|
|
|
| |
The template field is really a link, so needs to be converted to a page
name in stored state.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
* edittemplate: Default new page file type to the same type as the template.
(willu)
* edittemplate: Add "silent" parameter. (Willu)
* edittemplate: Link to template, to allow creating it. (Willu)
|
| | |
|
| |
|
|
| |
too many plugins.. brain exploding..
|
| | |
|
| | |
|
| |
|
|
| |
removed
|
| |
|
|
| |
formbuilder object
|
| |
|
|
|
|
| |
so that more than one plugin can use this hook.
I believe this is a safe change, since only passwordauth uses this hook.
(If some other plugin already used it, it would have broken passwordauth!)
|
| |
|
|
|
|
| |
It would be better if it were a formbuilder hook. But the formbuilder hook
is wacked.. I may need to change how that hook works, which would mean
changing the only current user of it, passwordauth).
|
| |
|