Age | Commit message (Collapse) | Author |
|
The fix for colons involved adding "./" to some urls. Due to the weird way
inline called urlto, these snuck into feed urls and permalinks. Fix it by
adding an optional third parameter to urlto.
|
|
|
|
with [[!meta guid="..."]], which also outputs an Atom <id>
|
|
This is often the same as the feed's <link> (in which case it can be omitted) but sometimes it's a urn:uuid: URN instead.
|
|
|
|
|
|
|
|
a page, then pass it into the rssitem/atomitem templates
|
|
* The editpage form now uses the raw page name, not the page title, in its
'page' cgi parameter. Using the title was ambiguous and made it
impossible to tell between some pages, like "foo/bar" and "foo__47__bar",
sometimes causing the wrong page to be edited.
* This change means that some edit links need to be updated.
Force a rebuild on upgrade to this version.
* Above change also allowed really fixing escaped slashes from the blogpost
form.
|
|
Because the search plugin needed it, also because it's one of the few
plugins that didn't already have it.
I also considered adding it to htmlize, but I really cannot imagine caring
what the destpage is when htmlizing. (I'll probably be poven wrong later.)
|
|
avoid overoptimising.
|
|
just expanded to nothing.
|
|
number of system calls in half. (Still room for improvement.)
|
|
|
|
Also, simplified finding the url to the top of the site.
|
|
tag 473987 +patch
thanks
Hi,
The issue is that we need to convert relative links to absolute
ones for atom and rss feeds -- but there are two types of
relative links. The first kind, relative to the current
document ( href="some/path") is handled correctly. The second
kind of relative url is is relative to the http server
base (href="/semi-abs/path"), and that broke.
It broke because we just prepended the url of the current
document to the href (http://host/path/to/this-doc/ + link),
which gave us, in the first place:
http://host/path/to/this-doc/some/path [correct], and
http://host/path/to/this-doc//semi-abs/path [wrong]
The fix is to calculate the base for the http server (the base of
the wiki does not help, since the base of the wiki can be
different from the base of the http server -- I have, for example,
"url => http://host.name.mine/blog/manoj/"), and prepend that to
the relative references that start with a /.
This has been tested.
Signed-off-by: Manoj Srivastava <srivasta@debian.org>
|
|
for "show".
|
|
|
|
|
|
Markdown is slow. Especially if it has to process an enormous page. The
most common enormous page is currently the recentchanges page, which gets
processed a lot, and contains very little actual markdown. Most of it is a
big <div>, which markdown skips ... slowly.
This is a rather sick optimisation to work around markdown's speed issues.
Now inline inserts a small, dummy div, allows markdown to quickly render
the actual page content, then replaces the dummy with the actual inlined
pages later.
Results: Rendering just a recentchanges page, with diffs included, dropped
from 4.5 seconds to 2.7 seconds on my laptop. Building the entire wiki
dropped from 46.6 seconds to 39.5 seconds.
(It would be better if inline were a *post*-processor directive.)
|
|
Closes: #470530
|
|
such urls.
|
|
which forced a scan of the page to make available metadata that
appeared after the inline directive. Problem is that scan made it forget
about any other files rendered due to the page. The scan also turns out
to be unnecessary now, since meta persistently stores state and it's
always available. So it was just removed.
|
|
|
|
|
|
used if you want a wiki that doesn't default to generating rss or atom
feeds, but that does allow them to be turned on for specific blogs.
|
|
just avoid actually writing the files. This is necessary because ikiwiki
saves state after a preview (in case it actually *did* write files),
and if will_render isn't called its security checks will get upset
when the page is saved. Thanks to Edward Betts for his help tracking this
tricky bug down.
|
|
set for the first and last inlined page. Useful for templates that build
tables and the like.
|
|
meta link.
* Fix support for the case where metadata appears after an inline directive.
This was broken in version 2.16.
|
|
|
|
|
|
|
|
|
|
|
|
inlined pages is displayed. Closes: #451019
|
|
|
|
single page containing two different feeds.
* Also fixed some places in inline that failed to use destpage correctly.
|
|
but not inline the pages.
|
|
gmtime for these since a time zone is not specified.
|
|
|
|
atom feeds, and also changing the publication time for a feed to the
newest modiciation time (was newest creation time).
* The patch also adds dcterms:creator to rss items that have a known author.
|
|
|
|
once more.
|
|
|
|
ESCAPE=HTML for titles in the templates for these feeds, and instead
escape the title going in to the template. Previously, the title was
sometimes double-escaped in a feed (if set via meta title), and sometimes
not (if set from the page filename).
* In the meta plugin, when a title is set, encode the html entities in it
numerically. This works better in the current landscape of a rss spec that
doesn't specify encoding, and variously broken feed consumers, according
to <http://www.rssboard.org/rss-profile#data-types-characterdata>.
|
|
* Fix links to smilies generated by the smiley plugin for inlined pages. The
old links were often wrong, but often still worked by accident.
|
|
for extended pagespecs. The old calling convention will still work for
back-compat for now.
* The calling convention for functions in the IkiWiki::PageSpec namespace
has changed so they are passed named parameters.
* Plugin interface version increased to 2.00 since I don't anticipate any
more interface changes before 2.0.
|
|
old posts from feeds when permalinks change.
|
|
effect. Note that this changes permalinks, so if you are already using
usedirs you'll have to deal with that on upgrade to this version.
|
|
|