| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Flattened the wrapper setup, as this lets it be handled better by the
setup generation code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The fix for colons involved adding "./" to some urls. Due to the weird way
inline called urlto, these snuck into feed urls and permalinks. Fix it by
adding an optional third parameter to urlto.
|
|
Previous fix mised a few cases.
|
|
|
|
|
|
* Renamed to parentlinks every single variable or function called
pedigree
* Removed the parentlinks function from Render.pm
* Enabled the new parentlinks plugin by default
* Adapted testsuite and documentation to reflate the above facts
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
error() from such hooks; it will cause a nicely formatted error message to be inserted into the page.
|
|
|
|
|
|
|
|
This reverts commit 810a355308d276ef922ff4312bff0c7935676633.
I double-checked, and the change seems ok after all, actually.
|
|
This reverts commit e25c3a0a7caa9783c657efe86611929ecb7bd4a3.
I didn't think that through far enough; beautify_url may be called on full
urls, which don't start with "/"!
Conflicts:
debian/changelog
|
|
|
|
So the problem is that ikiwiki would generate a relative link like
href="colon:problem", which web browsers treat as being in the "colon:"
uri scheme.
The best fix seems to be to make url beautification fix this, by slapping
a "./" in front.
|
|
* The editpage form now uses the raw page name, not the page title, in its
'page' cgi parameter. Using the title was ambiguous and made it
impossible to tell between some pages, like "foo/bar" and "foo__47__bar",
sometimes causing the wrong page to be edited.
* This change means that some edit links need to be updated.
Force a rebuild on upgrade to this version.
* Above change also allowed really fixing escaped slashes from the blogpost
form.
|
|
|
|
|
|
Make it a config setting, this way subtle load order issues don't come into
play. (As much?)
|
|
This special case crops up when generating the parentlink to the toplevel
index page. urlto("") had been generating a link to "./" (or "../" etc)
for that, which is fine, if the web server redirects that to the toplevel
index.html. It's less fine if there is no web server.
I actually ran into the problem first when using gopher. (Yes, yes, don't
laugh.. see upcoming tip.) But it also crops up when browsing local wiki
files.
Of course, the index.html is stripped back off if usedirs is enabled.
|
|
Because the search plugin needed it, also because it's one of the few
plugins that didn't already have it.
I also considered adding it to htmlize, but I really cannot imagine caring
what the destpage is when htmlizing. (I'll probably be poven wrong later.)
|
|
I think this will give better results overall.
I made %IkiWiki::preprocessing accessible and used it to avoid indexing
at unnecessary points.
|
|
on the cgi following edit links.
|
|
Also improve error message when a pagespec fails to parse.
|
|
such as TZ or PATH.
|
|
number of system calls in half. (Still room for improvement.)
|
|
<mxey> I have a weird problem with Ikiwiki on FreeBSD: When rendering this page <http://rafb.net/p/zmfROX86.html>, I get "ikiwiki.setup: Modification of a read-only value attempted at /usr/local/lib/perl5/site_perl/5.8.8/IkiWiki.pm line 1300.".
And converting the constructors to not operate on the parameters directly
but use lexical variables fixed it. Not sure exactly when this occurs.
|
|
srcfile now has an optional second parameter to avoid it throwing an error
if the source file does not exist.
|
|
This manifested as wikis with no locked pages treating them all as locked.
The bug was introduced in version 2.41.
Medium urgency upload due to above fix.
|
|
|
|
on the same filesystem and the wiki includes large media files, which would normally be copied, wasting time and space.
|
|
This saves space, and stores the data under the right keys.
|
|
|
|
|
|
During refresh of a wiki with 800 files, loadindex was using more total
time than any other function, and saveindex was also in the top ten.
Rewriting them to use Storable makes them three times as fast.
0.7 seconds is saved on my laptop in profiling mode.
|
|
About 12% of ikiwiki runtime was spent in pagespec_match. It was evaling
the same pagespec code over and over again. This changes pagespec_translate
to return memoized, precompiled functions that can be called to match against
a given pagespec.
This also allows getting rid of the weird variable scoping trick that had
to be in effect for pagespec_translate to be called -- the variables are
now just fed into the function it returns.
On my laptop, this drops build time for the docwiki from about 60 to 50
seconds.
|
|
|
|
as that can result in a broken merged pagespec that matches nothing.
|
|
|
