| Age | Commit message (Collapse) | Author |
|---|
|
|
|
$_ will be absolute then
|
|
Another bit of code that didn't realize that File::Find sets $_ to the
relative filename.
|
|
file_pruned now tests for that
|
|
In File::Find, $_ is relative to the current directory, so that is ok.
Also, the directory name doesn't need to be stripped from $_.
|
|
file_prune also fails on absolute filenames now
|
|
|
|
|
|
|
|
This is more accurate when a file that is not a page is what is removed.
|
|
|
|
Many calls to file_prune were incorrectly calling it with 2 parameters.
In cases where the filename being checked is relative to the srcdir,
that is not needed.
Made absolute filenames be pruned. (This won't work for the 2 parameter call
style.)
|
|
|
|
|
|
|
|
|
|
This is a slow implementation; it runs svn log once per file
still, rather than running svn log once on the whole srcdir.
I did it this way because in my experience, svn log, run on a directory,
does not always list every change to files inside that directory.
I don't know why, and I use svn as little as possible these days.
|
|
* Automatically run --gettime the first time ikiwiki is run on
a given srcdir.
* Optimise --gettime for git, so it's appropriatly screamingly
fast. (This could be done for other backends too.)
* However, --gettime for git no longer follows renames.
* Use above to fix up timestamps on docwiki, as well as ensure that
timestamps on basewiki files shipped in the deb are sane.
|
|
* Rename --getctime to --gettime. (The old name still works for
backwards compatability.)
* --gettime now also looks up last modification time.
* Add rcs_getmtime to plugin API; currently only implemented
for git.
|
|
The pagetemplate hook may be called multiple times, for example when pages
are inlined into a page. Sidebars were being calculated each time that
happened, only to be thrown away when the final pagetemplate hook was
called. Avoid this unnecessary work.
Remove stored sidebar content on use to save some memory.
|
|
|
|
Commit b7351daacd0d4a041a51b43d99b7bf589de54f53 introduced the bug.
|
|
|
|
This way, the example blog always has a sidebar on the index page,
but not the overhead of sidebars on all the other pages. And if a
user wants to, they can enable global_sidebars to switch to sidebars on
every page.
|
|
|
|
on a page.
|
|
|
|
|
|
* pagestats: Class parameter can be used to override default class for
custom styling.
* pagestats: Use style=list to get a list of tags, scaled by use like
in a tag cloud. This is useful to put in a sidebar.
* Rework example blog front page.
|
|
which pages to include on the calendar archive pages. (The pagespec can still also be specified on the ikiwiki-calendar command line.)
|
|
so filter out such a misconfiguration.
|
|
Conflicts:
IkiWiki/Plugin/meta.pm
|
|
master language.
|
|
|
|
Rebuild can be needed sometimes, but not always, so undef.
|
|
Conflicts:
debian/NEWS
|
|
|
|
This makes them consistent with the rest of the meta keys. A wiki rebuild
will be needed on upgrade to this version; until the wiki is rebuilt,
double-escaping will occur in the titles of pages that have not changed.
|
|
|
|
|
|
|
|
|
|
The meta title data set by comments needs to be encoded the same way that
meta encodes it. (NB The security implications of the missing encoding
are small.)
Note that meta's encoding of title, description, and guid data, and not
other data, is probably a special case that should be removed. Instead,
these values should be encoded when used. I have avoided doing so here
because that would mean forcing a wiki rebuild on upgrade to have the data
consitently encoded.
|
|
|
|
|
|
Variable renamed to be a bit more self-explanatory.
Probably more idiomatic perl to not use a hash ref when a hash can be used.
|
|
|
|
The output of "bzr log" seems to have changed a bit, so we change the
parsing accordingly. This has not been tested with earlier versions of
bzr.
Several problems seemed to occur, all in the bzr_log subroutine:
1. The @infos list would contain an empty hash, which would confuse the
rest of the program.
2. This was because bzr_log would push an empty anonymous hash to the
list whenever it thought a new record would start.
3. However, a new record marker (now?) also happens at th end of bzr log
output.
4. Now we collect the record to a hash that gets pushed to the list only
if it is not empty.
5. Also, sometimes bzr log outputs "revno: 1234 [merge]", so we catch only
the revision number.
6. Finally, there may be non-headers at the of the output, so we ignore
those.
|
|
Joey pointed out that sort=x usually takes a sort order.
|
|
I've left meta_title in, undocumented, as a possible replacement for
sort=title in IkiWiki 4.0 or something.
|
