| Commit message (Collapse) | Author | Age |
... | |
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The po rescan hook re-runs the scan hooks, and runs the preprocess ones in scan
mode, both on the po-to-markup converted content. This way, plugins such as meta
are given a chance to gather correct information, rather than ugly/buggy escaped
data it did gather from unconverted PO files.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is needed for the po plugin vs. e.g. meta titles.
In order to get rid of the ugly "rebuilding all pages to fix meta titles" thing,
Joey suggested to make "po, at scan time, re-run the scan hooks, passing them
modified content (either converted from po to mdwn or with the escaped stuff
cheaply de-escaped)". This would unfortunately not work, as the meta plugin
gathers its data using the preprocess hook in scan mode: it would overwrite with
buggy data the correct data we would have forced it to gather in po's scan hook.
We then need a hook that runs *after* the preprocess hook has been run in scan
mode, but *before* any page rendering is started. Hence this one.
|
| |_|_|/
|/| | |
| | | |
| | | | |
allow for nonstandard installations.
|
| |_|/
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A missing smileys.mdwn caused the plugin to error out interrupting the
building process. Instead, we check for the file presence and warn without
erroring out in case it's missing, in a similar fashion as it's
currently done for the shortcut plugin.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 3ef8864122c2e665d41ed4d45baa50d4a5d21873.
Most aggregators block javascript and so it would display uglily.
Need to find a way to fallback to static buttons instead.
|
| | |
| | |
| | |
| | |
| | |
| | | |
This makes the javascript be added to rss feeds, which allows the buttons
to be displayed by aggregators. At least, if the aggregator does not
sanitize javascript.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Thanks to jaywalk for the initial implementation at a flattr plugin!
This one is less configurable, but simpler.
|
| | | |
|
| |/
|/|
| |
| | |
cannot identify a file.
|
|/
|
|
| |
simplify dependencies. Closes: #591040
|
|
|
|
| |
been disabled.
|
|
|
|
| |
clean up xapian db when plugin is disabled
|
|
|
|
|
| |
The wrapper is pointless in that configuration. Also, the code for it
doesn't compile w/o untrusted commiters to test. :)
|
|
|
|
|
|
|
|
| |
The idea here is that <meta name="foo" description="bar">
can be written like [[!meta name="foo" description="bar">.
Of course, [[!meta foo=bar]] is still supported; this new feature
provides some DWIM when trying to directly convert a meta tag into
a meta directive.
|
|
|
|
| |
jrayhawk)
|
|\ |
|
| | |
|
|/
|
|
|
| |
No need to use "keys %{$config{po_slave_languages}}" repeatedly:
the slave languages codes list is already cached in @slavelanguages.
|
|
|
|
| |
Backward compatibility is still supported.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 4cf185e781a5f94373b30ec9a0e10dfb626b6d86.
That commit broke t/po.t (probably the test case only is testing too
close the the old implementation and needs correcting).
Also, we have not decided how to want to represent it yet, so I'm not
ready for this change.
Conflicts:
IkiWiki/Plugin/po.pm
doc/plugins/po.mdwn
|
| |
|
|\ |
|
| | |
|
| | |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commits dcd57dd5c9f3265bb7a78a5696b90976698c43aa,
d4136aea8aa8968d2cd87b40e8d85301a3549323 and
d877b9644bcfbbfc5eaf3f7fc13cb96ecda946c9.
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
IkiWiki/Plugin/po.pm
doc/plugins/po.mdwn
|
| | | | |
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
doc/plugins/po.mdwn
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Set it to true every time IkiWiki::filter is called on a full page's content.
This is a much nicer solution, for the po plugin, than previous whitelisting
using caller().
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
... after having audited the po4a Xml and Xhtml modules for security issues.
Signed-off-by: intrigeri <intrigeri@boum.org>
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The protection against processing loops (i.e. the alreadyfiltered stuff) was
playing against us: the template plugin triggered a filter hooks run with the
very same ($page, $destpage) arguments pair that we use to identify a already
filtered page. Processing an included template could then mark the whole
translation page as already filtered, which prevented po_to_markup to be called
on the PO content.
This commit only runs the whole PO filter logic when our filter hook is run by
IkiWiki::render, which only happens when the full page needs to be filtered.
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
IkiWiki/Plugin/po.pm
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
(cherry picked from commit 98cc9460ac67fee606437712882cfa1e5d259729)
|
|\ \ \ \ \ \
| | |_|_|_|/
| |/| | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This better defines what the filter hook is passed, to only be the raw,
complete text of a page. Not some snippet, or data read in from an
unrelated template.
Several plugins that filtered text that originates from an (already
filtered) page were modified not to do that. Note that this was not
done very consistently before; other plugins that receive text from a
page called preprocess on it w/o first calling filter.
The template plugin gets text from elsewhere, and was also changed not to
filter it. That leads to one known regression -- the embed plugin cannot
be used to embed stuff in templates now. But that plugin is deprecated
anyway.
Later we may want to increase the coverage of what is filtered. Perhaps
a good goal would be to allow writing a filter plugin that filters
out unwanted words, from any input. We're not there yet; not only
does the template plugin load unfiltered text from its templates now,
but so can the table plugin, and other plugins that use templates (like
inline!). I think we can cross that bridge when we come to it. If I wanted
such a censoring plugin, I'd probably make it use a sanitize hook instead,
for the better coverage.
For now I am concentrating on the needs of the two non-deprecated users
of filter. This should fix bugs/po_vs_templates, and it probably fixes
an obscure bug around txt's use of filter for robots.txt.
|
| |_|_|_|/
|/| | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Not needed; lastupdate will be 0 for new feeds.
|