| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The file passed to rcs_getctime is already absolute, and it was
trying to stick the srcdir on the front.
Also, eliminated potentially unsafe shelling.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
For now, a rebuild is the only way to ensure the changed theme is used.
Ikiwiki normally will not realize style.css has changed, since themes
tend to have the same timestamp for the file.
|
| | | |
|
| | | |
|
| |/
|
|
| |
run_or_die returns a status code in scalar context
|
| |
|
|
| |
file name.
|
| |
|
|
|
| |
In passing, fixed a bug where the srcdir was in a subdir of a repository
named "0".
|
| |
|
|
| |
Bugfix in passing: New files not treated as such when no rcs is used.
|
| |\
| |
| |
| | |
and fix underlaydir override attack guard when srcdir is non-absolute
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A short story:
Once there was a unicode string, let's call him Srcdir.
Along came a crufy old File::Find, who went through a tree and pasted each
of the leaves in turn onto Srcdir. But this 90's relic didn't decode the
leaves -- despite some of them using unicode! Poor Srcdir, with these
leaves stuck on him, tainted them with his nice unicode-ness. They didn't
look like leaves at all, but instead garbage.
(In other words, perl's unicode support sucks mightily, and drives
us all to drink and bad storytelling. But we knew that..)
So, srcdir is not normally flagged as unicode, because typically it's pure
ascii. And in that case, things work ok; File::Find finds filenames, which
are not yet decoded to unicode, and appends them to the srcdir, and then
decode_utf8 happily converts the whole thing.
But, if the srcdir does contain utf8 characters, that breaks. Or, if a Yaml
setup file is used, Yaml::Syck's implicitunicode sets the unicode flag of
*all* strings, even those containing only ascii. In either case, srcdir
has the unicode flag set; a non-decoded filename is appended, and the flag
remains set; and decode_utf8 sees the flag and does *nothing*. The result
is that the filename is not decoded, so looks valid and gets skipped.
File::Find only sticks the directory and filenames together in no_chdir
mode .. but we need that mode for security. In order to retain the
security, and avoid the problem, I made it not pass srcdir to File::Find.
Instead, chdir to the srcdir, and pass ".". Since "." is ascii, the problem
is avoided.
Note that chdir srcdir is safe because we check for symlinks in the srcdir
path.
Note that it takes care to chdir back to the starting location. Because
the user may have specified relative paths and so staying in the srcdir
might break. A relative path could even be specifed for an underlay dir, so
it chdirs back after each.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A short story:
Once there was a unicode string, let's call him Srcdir.
Along came a crufy old File::Find, who went through a tree and pasted each
of the leaves in turn onto Srcdir. But this 90's relic didn't decode the
leaves -- despite some of them using unicode! Poor Srcdir, with these
leaves stuck on him, tainted them with his nice unicode-ness. They didn't
look like leaves at all, but instead garbage.
In other words, perl's unicode support sucks mightily, and drives
us all to drink and bad storytelling. But we knew that..
So, srcdir is not normally flagged as unicode, because typically it's pure
ascii. And in that case, things work ok; File::Find finds filenames, which
are not yet decoded to unicode, and appends them to the srcdir, and then
decode_utf8 happily converts the whole thing.
But, if the srcdir does contain utf8 characters, that breaks. Or, if a Yaml
setup file is used, Yaml::Syck's implicitunicode sets the unicode flag of
*all* strings, even those containing only ascii. In either case, srcdir
has the unicode flag set; a non-decoded filename is appended, and
decode_utf8 sees the flag and does *nothing*. The result is that the
filename is not decoded, so looks valid and gets skipped.
File::Find only sticks the directory and filenames together in no_chdir
mode .. but we need that mode for security. In order to retain the
security, and avoid the problem, I made it not pass srcdir to File::Find.
Instead, chdir to the srcdir, and pass ".". Since "." is ascii, the problem
is avoided.
Note that it takes care to chdir back to the starting location. Because
the user may have specified relative paths and so staying in the srcdir
might break. A relative path could even be specifed for an underlay dir, so
it chdirs back after each.
|
| | |
|
| |
|
|
| |
(Thanks, privat)
|
| |
|
|
|
|
| |
Removing a plugin from add_plugins is not always enough to disable it.
It may have been redundantly added there and also pulled in via goodstuff.
Always add didabled plugins to disable_plugins.
|
| |
|
|
|
|
|
|
| |
The bug here was that disabling a plugin included thru goodstuff, like
htmlscrubber, caused it to be added to disable_plugins, and those plugins
were never loaded, so could not be re-enabled. Fix by allowing them to be
force loaded when appropriate. (Also that allows disabled plugins to still
record their setup options when dumping a setup file.)
|
| |
|
|
| |
plugin is enabled.
|
| | |
|
| |
|
|
| |
(still looks in old location for backwards compatability).
|
| |
|
|
| |
does not exist, so it can be easily created.
|
| | |
|
| | |
|
| |
|
|
|
| |
While those files cannot be removed or renamed, this allows easy
downloading of them, and a new version can after all be uploaded.
|
| | |
|
| |
|
|
| |
a few edge case setups.
|
| |
|
|
|
|
| |
* calendar: Shorten day names, and improve styling of month calendar.
* style.css: Reduced sidebar width back to 20ex from 30; the month calendar
will now fit in the smaller width, and 30 was feeling too large.
|
| | |
|
| |
|
|
|
| |
This is a slow, safe, stupid approach. Could make deep copies of the data
structures as backups instead of re-loading the index from disk.
|
| | |
|
| |
|
|
|
| |
On second thought, only display a page's personal sidebar when previewing
it, not when editing normally.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
In particular, perl warns if a qw{} contains a #, but openids can.
If the setup file has 'use warnings', it will turn warning messages back
on, so it seems reasonable to squelch them by default.
|
| | |
|
| |
|
|
|
|
| |
I've seen user(http://*) confuse someone who didn't know pagespecs to think
that just http://* would moderate all comments to every page, or something
like that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
pages that had contained them.
Problem is that by the time rendering calls render_dependent, %pagesources
has had deleted files removed from it. So match_comment's lookup of
files in there to see if they had the _comment extension failed.
I had to introduce a hash that temporarily holds filenames of deleted pages
to fix this.
Note that unlike comment(), internal() had avoided this pitfall by being
defined to match both internal and non-internal pages.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This reverts commit 4a6d5330e5b9554f1bd25b9025dd96200c6519c7.
That was too ugly, the DYNAMIC test on page.tmpl will avoid the problem
anyway -- just needs to be added.
|
| |
|
|
|
|
|
| |
If the site is configured to allow comments on *, then the comment post
interface was being added to cgi pages like signin and prefs. This fixes it
w/o requiring more page.tmpl changes. The pagetemplate hook is called by
misctemplate with an empty page name for dynamic pages.
|
| |
|
|
|
| |
Suppress disiplay of small search for on search results page, and of
Prefrences link on prefs page.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
On second thought, misctemplate can use pagetemplate hooks to provide
it, so it's better to keep back-compat, and allow full customisation
of how it's displayed via the template.
|