img: add support for objects too

The primary intended use is for interactive SVGs and SVGs that depend on
external data, which would otherwise not render correctly in most modern
browsers because security.

Improved OpenGraph title

Preliminary OpenGraph support

memoize check for up in trail (untested)

trail: no 'up' page if it's a member of the trail

When a trail includes its index page among the members, the pages
before/after it will have “double links” to the index page (both as
next/prev and as 'up') and the index page will include an 'up' link to
itself.

Prevent this by not defining the appropriate template variables when the
index page is member of the trail itself. The default page template is
also adapted to skip the link at all in this case.

inline: fix spurious feed removal from nested inlining

Situation:

* page A has an inline directive that (directly) generates a feed F
* page B inlines A, thus (indirectly) generating F again
* page B is rendered after page A

Without this patch, F is rendered by both A and B. However, if a change
in B causes it to _not_ inline A anymore, the following would happen:

* page A is built, rendering F
* page B is built, _not_ rendering F (which it used to render)
* F is removed because it's not rendered by B anymore

With this patch, rendering of F is always controlled by A, preventing
the spurious feed removals from happening.

A wiki rebuild is necessary after this patch is included.

Note that although this issue is triggered by last year's changes
bb8f76a4a04686def8cc6f21bcca80cb2cc3b2c9 and
72c8f01b36c841b0e83a2ad7ad1365b9116075c5 (that allowed feed generation
from nested inlines, coalescing it to be page-based instead of
destpage-based), there is potential for it popping up in other cases.

Specifically, the generated pages removal logic curently relies on the
assumption that a given output has only one generator. This assumption
was violated for feeds with the introduction of the mentioned commits,
and is now being re-instated (for feeds) with this patch, but other
similar cases may pop up for other plugins in the future.

linkbase plugin

The linkbase plugin defines a directive to manage linkbases in the
document. These are typically defined in the linkbases file at the
document root, much like shortcuts.

linkbase feature

The linkbase feature allows pages to specify one or more (other)
locations in which link targets should be searched for. This may be
defined either for pagespecs (all pages matching the spec will have
that linkbase) or for specific pagenames.

IkiWiki: option to not inline images automatically

inline: define a pageid

inline: make baseurl available to the inlinepage template

inline: propagate inline mtime/ctime too

If page A inlines page B that inlines page C, then we want the inline
mtime of page A to match that of C if it's more recent than the mtime of
B.

inline: initialize mtime field with ctime

This ensures proper ordering when the mtime field is absent or bogus.

conditional: also trigger preprocessing during scan

This is necessary to correctly support directives that have a preprocess
hook with scan=>1 and which are nested inside an if directive.

While we're at it, we also properly propagate the preview state.

meta: ignore_mtime option

This option makes 'updated' fall back to the ctime instead of the mtime.

inline: add a couple of TODOs

inline: cope with addition/removal of file

Since the inline times must be updated during the scan of the inlining
(rather than of the inlined) document(s), we must find the inlining
pages before the scan phase (specifically, during the needsbuild
phase) and mark them as changed too.

Additionally, we must also consider if there are pages being removed,
and in the affirmative case we must know which ones they are so that
they be ignored during the scan phase.

inline: ctime and mtime sorting

Two new sort methods, inline([cm]time), are defined to allow sorting
pages by the mtime/ctime of their inlined pages rather than by their
own.

post-scan hooks

During the scan phase plugins can push anonymous functions into the
@post_scan array, to be called after all pages have been scanned.

This allows plugin to run actions between the scanning and building
phase, which is important for pre-render actions that e.g. need to
ensure that pagespec patterns will match correctly.

inline: improve feed title and description management

Move feed title generation outside of genfeed(), and allow it to be
customized by an appropriate parameter to the inline directive.

The feed description is also extended to base it on the page description
(if present), and defaulting to a configurable union of wiki name and
page title otherwise (rather than hard-coding it to the wiki name).

Specify that the URL should not have a trailing /

google: add google analytics

The code is based primarily on the flattr plugin.

google: add config to enable/disable sitesearch

In preparation for the inclusion of other Google services, make the
Google sitesearch inclusion configurable, to allow loading the google
plugin to use the other services without having to edit the default
templates to remove the search form.

A similar effect can be achieved by creating an empty
templates/googleform.tmpl, but we don't want to force people to hack
around automatic stuff this way.

I had the same problem somebody on the discussion page had so I changed the instructions so nobody else will.

libtext-csv-xs-perl not relevant

sigh, still broken, different error message.

libpel5

more info: libperl5, buster versus stretch

follow-up: sorry, I appreciate that wasn't as useful as it could have been

split done and not done patch list, remove patches from the other lists

explicitely tag this as a patch

Gentle ping on proposed branch

cannot reproduce new bug

Update changelog with schmonz's changes

bug remains for inline table case

bug report

Fix build with po4a 0.56 via consistent "\n" use.

Errors look like so:

PERL5LIB=.. ./po2wiki underlay.setup
Invalid po file
/var/folders/y5/k8bh4xsj75g4j1n631f2gqz80000gp/T/ikiwiki-po-filter-in.OPXJxZ0juW:
/var/folders/y5/k8bh4xsj75g4j1n631f2gqz80000gp/T/ikiwiki-po-filter-in.OPXJxZ0juW:293:
'msgid' and 'msgstr' entries do not both end with '\n'
/var/folders/y5/k8bh4xsj75g4j1n631f2gqz80000gp/T/ikiwiki-po-filter-in.OPXJxZ0juW:589:
'msgid' and 'msgstr' entries do not both end with '\n'
msgfmt: found 2 fatal errors

make[1]: *** [po2wiki_stamp] Error 255

not sure this is necessary

add link to auto-numbering on CSS

MultiMarkdown footnote un-inversion: done

Fix inverted footnote config with MultiMarkdown.

Bug spotted and fix from Giuseppe Bilotta <giuseppe.bilotta@gmail.com>.

Extend mdwn tests to cover MultiMarkdown, where applicable.

Please test sudo-mass-rebuild branch on Debian

Response: am trying sudo

rename bugs/MultiMarkdown_footnot_support_seems_to_be_broken.mdwn to bugs/MultiMarkdown_footnote_support_seems_to_be_broken.mdwn

Directive fix

I've not looked at Shake yet, thanks, I'll give it a look! — [[Jon]]

Suggest shake

some beginning code to migrate an ikiwiki to hakyll

lol

saw typesetter-css and was reminded of my appeal against the anti-theme as default

Adding my work-in-progress blog to the list

No longer hosting these on Branchable.

Merge branch 'master' of ssh://git.ikiwiki.info

Updated German program translation from Sebastian Kuhnert.

Fix link in previous.

Reply to fancypodcast question.

Updated German basewiki and directives translation from Sebastian Kuhnert.

Open up the discussion

Catch up to highlight 3.51 API change.

As of 3.51, searchFile() is no longer provided in highlight's Perl
bindings (at least on NetBSD and OS X, as built from pkgsrc). This
leaves us falling through to getConfDir(), which has been gone
rather longer.

From highlight git, it appears searchFile() and getFiletypesConfPath()
both originated in the 3.14 release. The latter is still available in
3.51, and returns the same result searchFile() used to. Switch to it.

Add my ikiwiki/blog

Response to jsewell's bug report.

add gitbranch template, prompted by Integeri. Thanks

Fix syntax.

Submit branch for review.

update my comment to reflect new commits on that branch

initial implementation (I was unable to use untrusted git push to add this comment)

Merge remote-tracking branch 'origin/master'

Announce 3.20190228 and 3.20170111.1

Add an anchor for /security/#cve-2019-9187

Prepare 3.20190228 for future release

doc: Document security issues involving LWP::UserAgent

Recommend the LWPx::ParanoidAgent module where appropriate.
It is particularly important for openid, since unauthenticated users
can control which URLs that plugin will contact. Conversely, it is
non-critical for blogspam, since the URL to be contacted is under
the wiki administrator's control.

Signed-off-by: Simon McVittie <smcv@debian.org>

useragent: Automatically choose whether to use LWPx::ParanoidAgent

The simple implementation of this, which I'd prefer to use, would be:
if we can import LWPx::ParanoidAgent, use it; otherwise, use
LWP::UserAgent.

However, aggregate has historically worked with proxies, and
LWPx::ParanoidAgent quite reasonably refuses to work with proxies
(because it can't know whether those proxies are going to do the same
filtering that LWPx::ParanoidAgent would).

Signed-off-by: Simon McVittie <smcv@debian.org>

useragent: Don't allow non-HTTP protocols to be used

This prevents the aggregate plugin from being used to read the contents
of local files via file:/// URLs.

Signed-off-by: Simon McVittie <smcv@debian.org>

This reverts commit 727147aa6e50229178fb853f26c9c340fa789799

useragent: Raise an exception if the LWP module can't be loaded

Signed-off-by: Simon McVittie <smcv@debian.org>

po: Always filter .po files

The input to filter hooks is meant to be the content of a source file
on disk. If we only filter once per (page, destpage) pair, and a page
is inlined into the same destpage more than once, then the second
occurrence will render as the result of htmlizing .po source as if
it was Markdown (or whatever the type of the corresponding master page
is), which is never going to end well.

The alreadyfiltered mechanism was added in commit 1e874b3f to avoid
preprocessing loops, but I'm not sure where it could lead to a loop:
filter hooks are only called from IkiWiki::filter, which is only called
on page content from disk or on proposed content being previewed.
According to <https://bugs.debian.org/911356#41>, deleting the
alreadyfiltered mechanism resolves the problem, as well as simplifying
the code.

Closes: #911356
Tested-by: intrigeri

Recommend against cvsps3 (haven't tried it).

Announce v3.20190207

Signed-off-by: Simon McVittie <smcv@debian.org>

Prepare new release

Signed-off-by: Simon McVittie <smcv@debian.org>

review

comment

tag as reviewed

respond

Exclude reviewed patches from this list

close

append javascript after CSS

Javascript resources should be presented to browsers after CSS, and
"after the fold" (ATF) according to the best practices:

https://developers.google.com/speed/docs/insights/mobile#PutStylesBeforeScripts

This change allows the browser to download Javascript files in
parallel, by including Javascript on the *closing* </body> tag instead
of the opening tag.

We also improve the regex to tolerate spaces before the body tag, as
some templates have (proper) indentation for the tag.

Remove unreachable git repositories

Signed-off-by: Simon McVittie <smcv@debian.org>