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.)
Simple podcast feeds didn't have content tags and I made sure to
keep it that way. This may be unnecessarily conservative. Changing
the behavior to include empty content tags might be fine, but I
don't want to think about it right now, I just want my tests to
keep passing!
The new fancy-podcast tests are copy-pasted-edited from the
simple-podcast tests. These tests shall be refactored.
bestlink returns '' if no existing page matches a link. This propigated
through inline and other plugins, causing uninitialized value warnings, and
in some cases (when filecheck was enabled) making the whole directive fail.
Skipping the empty results fixes that, but this is papering over another
problem: If the missing page is later added, there is not dependency
information to know that the inline needs to be updated. Perhaps smcv will
fix that later.
This allows per-form/feedlink group customization without having to
resort to counting.
(cherry picked from commit b134feb0dc2d9a8ff7ae447537fa8bc02811aabd)
The default templates are also updated to make use of this information.
The rel="alternate" attribute is also inserted, for completeness.
(cherry picked from commit 618ade535e6a7967a510d9e210edaef3d37cc9bc)
There seems no need to allow selecting a location when creating a page this
way; the user should always want it to appear in the inline whose form they
submitted.
Use the included page name rather than the including page name. This
allows us to allow feeds in nested inlines without duplicating feeds
with the same content under different (and stupid) names.
and support all elements that HTML::Tagset knows about.
(Which doesn't include html5 just yet, but then the old version didn't either.)
Bonus: 4 times faster than old regexp method.
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.
Note that I put comment-header in a <header> despite it being
below the comment. Using a <footer> would be confusing given
the class name. Also, the content is semantically closer to
a header than a footer.
This entailed changing template_params; it no longer takes the template
filename as its first parameter.
Add template_depends to api and replace calls to template() with
template_depends() in appropriate places, where a dependency should be
added on the template.
Other plugins don't use template(), so will need further work.
Also, includes are disabled for security. Enabling includes only when using
templates from the templatedir would be nice, but would add a lot of
complexity to the implementation.
This makes them consistent with the rest of the meta keys. A wiki rebuild
will be needed on upgrade to this version; until the wiki is rebuilt,
double-escaping will occur in the titles of pages that have not changed.
Speedup of about 25% for small inlines; could be much larger for inlines of
many, or complex pages.
Not bloating memory with excessive memoization data was the key to this.
The method chosen does not squeeze out every erg of speed possible when
inlines are nested, but that's rare. It uses less memory than other
optimisation hacks (I'm looking at you,
f937c1fb80 !) already used in inline.pm.
My experience is that when inlines are nested, the old behavior of
generating feeds for the nested inlines was never really desired. Since the
feeds were numbered sequentially, the numbers could easily change, and it did
not make sense to subscribe to or use those feeds. And generating those nested
feeds often meant a lot of unnecessary calculation, and data being written.
So, I dropped them.
Looking back, nested feeds originally were a free side effect of properly
handing multiple feeds on one page. Of course, that is still supported.
Simon McVittie
Joey Hess
Amitai Schlair
Paul Wise
Giuseppe Bilotta
Joey Hess