| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit 98cc9460ac67fee606437712882cfa1e5d259729)
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commits dcd57dd5c9f3265bb7a78a5696b90976698c43aa,
d4136aea8aa8968d2cd87b40e8d85301a3549323 and
d877b9644bcfbbfc5eaf3f7fc13cb96ecda946c9.
|
|
Conflicts:
IkiWiki/Plugin/po.pm
doc/plugins/po.mdwn
|
|
Not needed; lastupdate will be 0 for new feeds.
|
|
|
|
.ikiwiki/aggregatetime, to allow for more sophisticated cron jobs.
|
|
moderation queue.
|
|
Particularly important for floating images, which could before be placed
uncomfortably close to text.
|
|
Probably best to store it unsanitized and sanitize as needed on use.
And it already was for comments, leaving only the need to sanitize the
nickname when git committing, to ensure the email address is legal.
|
|
their name.
|
|
|
|
... after having audited the po4a Xml and Xhtml modules for security issues.
Signed-off-by: intrigeri <intrigeri@boum.org>
(cherry picked from commit a128c256a51392fcf752bf612d83a90e8c68027e)
|
|
(cherry picked from commit 4f44534d72c9a9a947bc38a3cb4987705c25bea5)
|
|
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.
|
|
Minor wording fix; changelog; etc.
|
|
(cherry picked from commit b225fdc44d4b3d2853db622d59aed7b59788aeec)
|
|
|
|
the git wrapper push to github in the background after ikiwiki runs.
|
|
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().
|
|
prevented actually rendering hnb files.
|
|
|
|
|
|
... 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
|
|
|
|
|
|
Renamed usershort => nickname.
Note that this means existing user login sessions will not have the nickname
recorded, and so it won't be used for those.
|
|
display of ugly google openids.)
|
|
|
|
There was some confusion about whether the filename was
relative to srcdir or not. Some test cases, and the bzr
plugin assumed it was relative to the srcdir. Most everything else
assumed it was absolute.
Changed it to relative, for consistency with the rest
of the rcs_ functions.
|
|
Using named parameters for these is overdue. Passing the session in a
parameter instead of passing username and IP separately will later allow
storing other session info, like username or part of the email.
Note that these functions are not part of the exported API,
and the prototype change will catch (most) skew, so I am not changing
API versions. Any third-party plugins that call them will need updated
though.
|
|
In the process, lost the commits from special usernames
when committing changed po files. Instead of trying to dummy up a session
object for the special username, I just don't pass one, and the commit will
appear to be from whatever user ikiwiki runs as.
|
|
Everywhere that REMOTE_ADDR was used, a session object is available, so
instead use its remote_addr method.
In IkiWiki::Receive, stop setting a dummy REMOTE_ADDR.
Note that it's possible for a session cookie to be obtained using one IP
address, and then used from another IP. In this case, the first IP will now
be used. I think that should be ok.
|
|
that may contain the username component of the email address of
the user making the commit.
|
|
Now the git plugin supports commits with author fields that look like:
Author: http://my.openid/ <me@web>
Then in recentchanges, the short username will be displayed, linking
to the openid.
Particularly useful for the horrible google openids, of course.
|
|
|
|
This way, an email-like link will be a mailto until a matching page
is created, then it will link to the page. And removing the page will
convert it back to a mailto.
|
|
At least two bugfixes in here. First, an old bug;
\[[foo#0]] was displayed as [[foo]], losing the anchor
as the anchor text was false. Secondly, a new bug;
an email like foo#bar@baz should not check bestlink("foo@baz").
|
|
Fully validating the email address is not necessary,
all that matters is not matching an url like http://foo@bar/
as an email address.
|
|
The following ways to create a link are supported now:
[[url]]
[[text|url]]
url can be one of the following:
- an internal wikilink: will be handled as before
- any other kind of URL, including mailto: proper links will be created:
<a href="url">url</a>
<a href="url">text</a>
- an email address:
<a href="mailto:url">url</a>
<a href="mailto:url">text</a>
|
