diff options
Diffstat (limited to 'doc')
58 files changed, 973 insertions, 72 deletions
diff --git a/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn b/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn index 6996a9fbf..0082eed4d 100644 --- a/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn +++ b/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn @@ -2,7 +2,7 @@ That one has bitten me for some time; here is the minimal testcase. There is also an equivalent (I suppose) problem when using another plugin, but I hope it's enough to track it down for this one. - $ tar -xj < [bug-dep_order.tar.bz2](http://www.thomas.schwinge.homeip.net/tmp/bug-dep_order.tar.bz2) + $ tar -xj < [bug-dep_order.tar.bz2](http://schwinge.homeip.net/~thomas/tmp/bug-dep_order.tar.bz2) $ cd bug-dep_order/ $ ./render_locally [...] diff --git a/doc/bugs/aggregate_generates_long_filenames.mdwn b/doc/bugs/aggregate_generates_long_filenames.mdwn new file mode 100644 index 000000000..fae8333ab --- /dev/null +++ b/doc/bugs/aggregate_generates_long_filenames.mdwn @@ -0,0 +1,37 @@ +the [[plugins/aggregate]] plugin mashes the `title` of an aggregated post into a filename. This results in long filenames. I have hit a filesystem length limitation on several occasions. Some (ab)uses of RSS, e.g., twitter, +generate long titles. Especially once you throw escaping into the mix: + + $ ikiwiki --setup testsetup --aggregate --refresh + failed to write ./test/lifestream/Hidden_Features_Of_Perl__44___PHP__44___Javascript__44___C__44___C++__44___C__35____44___Java__44___Ruby___46____46____46__._aggregated.ikiwiki-new: File name too long + aggregation failed with code 9216 + $ echo $? + 25 + +It would also appear this abrubtly terminates aggregate processing (if not ikiwiki itself). Only after moving my test repo to `/tmp` to shorten the filename did I see newer RSS feeds (from a totally different source) picked up. + + +-- [[Jon]] + +> I have to wonder what filesystem you have there where 147 characters +> is a long filename. Ikiwiki already uses `POSIX::pathconf` on the srcdir +> to look up `_PC_NAME_MAX` +> to see if the filename is too long, and shortens it, so it seems +> that, in additional to having a rather antique long filename limit, your +> system also doesn't properly expose it via pathconf. Not sure what +> ikiwiki can do here. --[[Joey]] + +>> This is an ext4 filesystem with default settings (which appears to mean +>> 256 bytes for pathnames). Despite the error saying file name, it's +>> definitely a path issue since moving my test repo to `/tmp`from +>> `/home/jon/wd/mine/www` hides the problem. I note the following comment +>> in `aggregate.pm`: + + # Make sure that the file name isn't too long. + # NB: This doesn't check for path length limits. + +>> I don't fully grok the aggregate source yet, but I wouldn't rule out +>> a bug in the path length checking, personally. I'm happy to try and +>> find it myself though :) -- [[Jon]] + +>>> Path length seems unlikely, since the max is 4096 there. +>>> --[[Joey]] diff --git a/doc/bugs/argument_isn__39__t_numeric:_mixing_templates_and_creation__95__date.mdwn b/doc/bugs/argument_isn__39__t_numeric:_mixing_templates_and_creation__95__date.mdwn new file mode 100644 index 000000000..ff98ba55f --- /dev/null +++ b/doc/bugs/argument_isn__39__t_numeric:_mixing_templates_and_creation__95__date.mdwn @@ -0,0 +1,62 @@ +I get the following error when building my wiki + + Argument "\x{3c}\x{54}..." isn't numeric in numeric eq (==) at /usr/share/perl5/IkiWiki.pm line 2547. + Argument "\x{3c}\x{54}..." isn't numeric in numeric eq (==) at /usr/share/perl5/IkiWiki.pm line 2547. + +that line corresponds to + + sub match_creation_year ($$;@) { + if ((localtime($IkiWiki::pagectime{shift()}))[5] + 1900 == shift) { <-- this one + return IkiWiki::SuccessReason->new('creation_year matched'); + } + +A git bisect shows that the offending commit introduced this hunk + + + --- /dev/null + +++ b/templates/all_entry.mdwn + @@ -0,0 +1,23 @@ + +## <TMPL_VAR year> + + + +There + +<TMPL_IF current> + +have been + +<TMPL_ELSE> + +were + +</TMPL_IF> + +[[!pagecount pages=" + +log/* and !tagged(aggregation) and !*/Discussion and !tagged(draft) + +and creation_year(<TMPL_VAR year>) + +and !*.png and !*.jpg + +"]] posts + +<TMPL_IF current> + +so far + +</TMPL_IF> + +in <TMPL_VAR year>. + + + +[[!inline pages=" + + log/* and !tagged(aggregation) and !*/Discussion and !tagged(draft) + + and creation_year(<TMPL_VAR year>) + + and !*.png and !*.jpg + + " archive=yes feeds=no]] + +The lines which feature creation_year(<TMPL_VAR year>) are most likely the culprits. That would explain why the error was repeated twice, and would tally with the file in `templates/` being rendered, rather than the inclusionists. + +A workaround is to move the template outside of the srcdir into the external templates directory and include the file suffix when using it, e.g. + + \[[!template id=all_entry.tmpl year=2010 current=true]] + +I believed (until I tested) that the [[ikiwiki/directive/if]] directive, with the `included()` test, would be an option here, E.g. + + \[[!if test="included()" then=""" + ...template... + """ else=""" + Nothing to see here. + """]] + +However this doesn't work. I assume "included" in this context means e.g. via an `inline` or `map`, not template trans-clusion. -- [[Jon]] + +> As far as I know, this bug was fixed in +> 4a75dee651390b79ce4ceb1d951b02e28b3ce83a on October 20th. [[done]] --[[Joey]] + +>> Sorry Joey, I'll make sure to reproduce stuff against master in future. [[Jon]] diff --git a/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn b/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn index f7138cba0..4b22fd06c 100644 --- a/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn +++ b/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn @@ -1,7 +1,7 @@ Consider this: - $ wget http://www.thomas.schwinge.homeip.net/tmp/cutpaste_filter.tar.bz2 - $ wget http://www.thomas.schwinge.homeip.net/tmp/cutpaste_filter.patch + $ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.tar.bz2 + $ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.patch $ tar -xj < cutpaste_filter.tar.bz2 $ cd cutpaste_filter/ diff --git a/doc/bugs/inline_action_buttons_circumvent_exclude_criteria_from_edittemplate__39__s_match__61____34____34___pagespec.mdwn b/doc/bugs/inline_action_buttons_circumvent_exclude_criteria_from_edittemplate__39__s_match__61____34____34___pagespec.mdwn new file mode 100644 index 000000000..45481bf21 --- /dev/null +++ b/doc/bugs/inline_action_buttons_circumvent_exclude_criteria_from_edittemplate__39__s_match__61____34____34___pagespec.mdwn @@ -0,0 +1,13 @@ +ikiwiki verison: 3.20100815.2 + +If I instruct editemplate to only match the top level pages in a directory using + + match="foo/* and !foo/*/* and !foo/*/*/*" + +everything works as expected for pages created via links on other wiki pages. So, if I open foo/bar (or any other page on the wiki) and create a link to foo/bar/bug, edittemplate appropriately does not insert any text into the new page. + +However, if I use an inline directive like the following + + !inline pages="page(foo/bar/*)" rootpage="foo/bar" postform=yes actions=yes + +every page created via the action buttons incorrectly pulls in the text from the edittemplate registration. Changing the order of the conditions in the match="" pagespec has no impact. diff --git a/doc/bugs/logout_in_ikiwiki.mdwn b/doc/bugs/logout_in_ikiwiki.mdwn new file mode 100644 index 000000000..d9b6df677 --- /dev/null +++ b/doc/bugs/logout_in_ikiwiki.mdwn @@ -0,0 +1,31 @@ +It looks like there is no way to logout of ikiwiki at present, meaning that if you edit the ikiwiki in, say, a cybercafe, the cookie remains... is there some other security mechanism in place that can check for authorization, or should I hack in a logout routine into ikiwiki.cgi? + +> Click on "Preferences". There is a logout button there. --liw + +> It would be nice if it were not buried there, but putting it on the +> action bar statically would be confusing. The best approach might be to +> use javascript. --[[Joey]] + + +>> I agree that javascript seems to be a solution, but my brain falls +>> off the end of the world while looking at ways to manipulate the DOM. +>> (I'd argue also in favor of the openid_provider cookie expiring +>> in less time than it does now, and being session based) + +>>> (The `openid_provider` cookie is purely a convenience cookie to +>>> auto-select the user's openid provider the next time they log +>>> in. As such, it cannot be a session cookie. It does not provide any +>>> personally-identifying information so it should not really matter +>>> when it expires.) --[[Joey]] + +>> It would be nice to move navigational elements to the upper right corner +>> of the page... + +>> I have two kinds of pages (wiki and blog), and three classes of users + +>> anonymous users - display things like login, help, and recentchanges, + +>> non-admin users - on a per subdir basis (blog and !blog) display +>> logout, help, recentchanges, edit, comment + +>> admin users - logout, help, recentchanges, edit, comment, etc diff --git a/doc/bugs/more_and_RSS_generation.mdwn b/doc/bugs/more_and_RSS_generation.mdwn new file mode 100644 index 000000000..00ab43fa2 --- /dev/null +++ b/doc/bugs/more_and_RSS_generation.mdwn @@ -0,0 +1,20 @@ +I'd like the more plugin and RSS to play better together. In the case of the html generation of the main page of a blog, I'd like to get the first paragraph out, but keep RSS as a full feed. + +Maybe there is a different plugin (I also tried toggle)? + +> I am not a fan of the more directive (thus the rant about it sucking +> embedded in its [[example|ikiwiki/directive/more]]). But I don't think +> that weakening it to not work in rss feeds is a good idea, if someone +> wants to force users to go somewhere to view their full content, +> they should be able to do it, even though it does suck. +> +> The toggle directive will degrade fairly well in an rss feed to +> display the full text. (There is an annoying toggle link that does +> nothing when embedded in an rss feed). --[[Joey]] + +I also note, that at least currently, more seems to break on a few pages, not being parsed at all when aggregated into the front page. + +> It's just a simple directive, it should work anywhere any directive will, +> and does as far as I can see. Details? --[[Joey]] + +see also: [[/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields/]] diff --git a/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn b/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn index 48c168997..0a435cea3 100644 --- a/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn +++ b/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn @@ -34,3 +34,19 @@ For Atom, at least, I believe adding `type="xhtml"` to the title element will wo > Update: Ok, I've fixed this for titles, as a special case, but the > underlying problem remains for other fields in rss feeds (such as > author), so I'm leaving this bug report open. --[[Joey]] + +>> I'm curious if there has been any progress on better RSS output? +>> I've been prototyping a new blog and getting good RSS out of it +>> seems important as the bulk of my current readers use RSS. +>> I note, in passing that the "more" plugin doesn't quite do what +>> I want either - I'd like to pass a full RSS feed of a post and only +>> have "more" apply to the front page of the blog. Is there a way to do that? +>> -- [[dtaht]] +>> +>>> To be clear, the RSS spec sucks to such an extent that, as far as +>>> I know, there is no sort of title escaping that will work in all +>>> RSS consumers. Titles are currently escaped in the way +>>> that tends to break the fewest according to what I've read. +>>> If you're unlucky enough to +>>> have a "&" or "<" in your **name**, then you may still run into +>>> problems with how that is escaped in rss feeds. --[[Joey]] diff --git a/doc/examples/blog.mdwn b/doc/examples/blog.mdwn index b25601227..5f8f6c3ce 100644 --- a/doc/examples/blog.mdwn +++ b/doc/examples/blog.mdwn @@ -10,8 +10,8 @@ Some additional configuration you might want to do, if not using * Make sure to configure ikiwiki to generate RSS or Atom feeds. -* Make sure you have the tag plugin enabled, and the `tagbase` set to - "tags". Tag pages will then automatically be created. +* Make sure you have the [[tag|plugins/tag]] plugin enabled, and the + `tagbase` set to "tags". Tag pages will then automatically be created. An example of how to tag a post is: \[[!tag life]] diff --git a/doc/forum/Blog_posting_times_and_ikiwiki_state.mdwn b/doc/forum/Blog_posting_times_and_ikiwiki_state.mdwn new file mode 100644 index 000000000..0c1da5b97 --- /dev/null +++ b/doc/forum/Blog_posting_times_and_ikiwiki_state.mdwn @@ -0,0 +1,28 @@ +What I wanted +------------- + +I thought to myself it would be nice to see from the console the dates that my ikiwiki blog posts were published. Especially as I would like to know the order of my todo list without having to view the webpage. + +What I discovered +----------------- + +Looked at the code and saw the functions for grabbing the ctime from git but couldn't reconcile them to the "Posted" date in the RSS feed. Some more reading and I figured out that the Posted time is taken from the UNIX ctime when first uploaded into the repository and this information is stored in the page state via a Perl storable database - indexdb. (I'm sure most know this but to be clear in UNIX ctime is *not* the actual creation time of a file. UNIX has no facility for recording the actual creation time - however on first upload to the wiki it's good enough). + +Wrote a Perl script to query and sort indexdb. Now I can list my todos or blog posts in the order they appear on the web. Handy. + +However the ikiwiki state is specifically excluded via '.gitignore'. I work a lot on trains and not having this file in my cloned wiki means I can't list published posts or my todos in the proper order. I can get an approximation from git logs but, dam it, I want it the same! + +What can I do? +-------------- + +Is it a spectacularly bad idea to include the ikiwiki state file in my cloned repo (I suspect it is). What else could be done? Can I disable pagestate somehow or force ikiwiki to always use git commit times for Posted times? + +> Have you tried running ikiwiki with the `--gettime` option on your laptop, +> to force it to retrieve initial commit times from git? You should only +> need to do that once, and it'll be cached in the pagestate thereafter. +> +> Because that functionality is slow on every supported VCS except git, +> ikiwiki tries to avoid using it unless it's really needed. [[rcs]] +> lists it as "fast" for git, though, so depending how fast it really is +> and how large your wiki is, you might be able to get away with running +> ikiwiki with `--gettime` all the time? --[[smcv]] diff --git a/doc/forum/Blog_posting_times_and_ikiwiki_state/comment_1_87304dfa2caea7e526cdb04917524e8c._comment b/doc/forum/Blog_posting_times_and_ikiwiki_state/comment_1_87304dfa2caea7e526cdb04917524e8c._comment new file mode 100644 index 000000000..62bae02b0 --- /dev/null +++ b/doc/forum/Blog_posting_times_and_ikiwiki_state/comment_1_87304dfa2caea7e526cdb04917524e8c._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmwYptyV5ptNt8LCbMYsmpcNkk9_DRt-EY" + nickname="Matt" + subject="comment 1" + date="2010-11-04T11:52:53Z" + content=""" +Perhaps I have a different setup from you but on my laptop I don't have ikiwiki installed - only a clone of the git repo. You mean to run --gettime on the post-update git hook? +"""]] diff --git a/doc/forum/How_to_list_new_pages__44___inline__63__.mdwn b/doc/forum/How_to_list_new_pages__44___inline__63__.mdwn new file mode 100644 index 000000000..f28e8b99b --- /dev/null +++ b/doc/forum/How_to_list_new_pages__44___inline__63__.mdwn @@ -0,0 +1,5 @@ +Hi, I'd love to include a "New posts" list into my front page, like at <http://danhixon.github.com/> for example. + +It should be different from recent changes in that it shouldn't show modifications of existing pages, and in that it would be inside a page with other content. + +Thanks, Thomas diff --git a/doc/forum/Moving_wiki.git_folder__63__.mdwn b/doc/forum/Moving_wiki.git_folder__63__.mdwn new file mode 100644 index 000000000..77d1da1ee --- /dev/null +++ b/doc/forum/Moving_wiki.git_folder__63__.mdwn @@ -0,0 +1,17 @@ +Hi folks, I created a simple wiki to keep notes and references for projects, it's worked quite nice so far. I decided to use git as it's what I use daily to manage code, and it's available on all my machines. + +Anyway, I wanted to move all the wiki source stuff into a subfolder so that it stops cluttering up my ~ directory. However, there seems to be a problem with moving wiki.git (I moved wiki, wiki.git and wiki.setup) and I'm not sure where to tell ikiwiki that the git directory has been moved. I changed + + srcdir => '/home/pixel/.notebook/wiki', + git_wrapper => '/home/pixel/.notebook/wiki.git/hooks/post-update', + +and that seems to be fine. However when I go to run ikiwiki --setup things go wrong: + + pixel@tosh: [~ (ruby-1.9.2-p0)] ➔ ikiwiki -setup .notebook/wiki.setup + successfully generated /home/pixel/public_html/wiki/ikiwiki.cgi + successfully generated /home/pixel/.notebook/wiki.git/hooks/post-update + fatal: '/home/pixel/wiki.git' does not appear to be a git repository + fatal: The remote end hung up unexpectedly + 'git pull origin' failed: at /usr/share/perl5/IkiWiki/Plugin/git.pm line 193. + +I've gone through wiki.setup and nothing has jumped out as the place to set this, have I missed something? diff --git a/doc/forum/Moving_wiki.git_folder__63__/comment_1_05238461520613f4ed1b0d02ece663bd._comment b/doc/forum/Moving_wiki.git_folder__63__/comment_1_05238461520613f4ed1b0d02ece663bd._comment new file mode 100644 index 000000000..d654591c0 --- /dev/null +++ b/doc/forum/Moving_wiki.git_folder__63__/comment_1_05238461520613f4ed1b0d02ece663bd._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="http://users.itk.ppke.hu/~cstamas/openid/" + ip="212.183.140.47" + subject="comment 1" + date="2010-10-27T22:45:28Z" + content=""" +I think you want to edit + + .git/config + +"""]] diff --git a/doc/forum/Moving_wiki.git_folder__63__/comment_2_72b2b842dfa0cfaf899fe7af12977519._comment b/doc/forum/Moving_wiki.git_folder__63__/comment_2_72b2b842dfa0cfaf899fe7af12977519._comment new file mode 100644 index 000000000..f2e7ece18 --- /dev/null +++ b/doc/forum/Moving_wiki.git_folder__63__/comment_2_72b2b842dfa0cfaf899fe7af12977519._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://pixel.dreamwidth.org/" + ip="65.29.14.21" + subject="comment 2" + date="2010-10-28T02:54:15Z" + content=""" +That did it thanks! + +Should I make some sort of edit in the setup page? I've used git for a while and for whatever reason it never occurred to me that this was from git, not from ikiwiki itself. +"""]] diff --git a/doc/forum/Need_something_more_powerful_than_Exclude.mdwn b/doc/forum/Need_something_more_powerful_than_Exclude.mdwn new file mode 100644 index 000000000..5e8043258 --- /dev/null +++ b/doc/forum/Need_something_more_powerful_than_Exclude.mdwn @@ -0,0 +1,5 @@ +When I originally looked at the "exclude" option, I thought it meant that it excluded pages completely, but it apparently doesn't. What I've found in practice is that a file which matches the "exclude" regex is excluded from *processing*, but it is still copied over to the destination directory. Thus, for example, if I have "^Makefile$" as the exclude pattern, and I have a file `src/foo/Makefile`, then that file is copied unaltered into `dest/foo/Makefile`. However, what I want is for `src/foo/Makefile` to be completely ignored: that it is not only not processed, but not even *copied* into the destination directory. + +I'm not sure if the current behaviour is a bug or a feature, but I would like a "totally ignore this file" feature if it's possible to have one. + +-- [[KathrynAndersen]] diff --git a/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_0019cd6b34c8d8678b2532de57a92d15._comment b/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_0019cd6b34c8d8678b2532de57a92d15._comment new file mode 100644 index 000000000..7842caeac --- /dev/null +++ b/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_0019cd6b34c8d8678b2532de57a92d15._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://smcv.pseudorandom.co.uk/" + nickname="smcv" + subject="expression anchored too closely?" + date="2010-11-23T10:43:21Z" + content=""" +It looks as though you might only be excluding a top-level Makefile, and not a Makefile in subdirectories. Try excluding `(^|/)Makefile$` instead, for instance? (See `wiki_file_prune_regexps` in `IkiWiki.pm` for hints.) + +The match operation in `&file_pruned` ends up a bit like this: + + \"foo/Makefile\" =~ m{…|…|…|(^|/)Makefile$} +"""]] diff --git a/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_f577ab6beb9912471949d8d18c790267._comment b/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_f577ab6beb9912471949d8d18c790267._comment new file mode 100644 index 000000000..bd964d540 --- /dev/null +++ b/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_f577ab6beb9912471949d8d18c790267._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="http://kerravonsen.dreamwidth.org/" + ip="60.241.8.244" + subject="Missed It By That Much" + date="2010-11-25T02:55:20Z" + content=""" +I discovered that I not only needed to change the regexp, but I also needed to delete .ikiwiki/indexdb because `file_pruned` only gets called for files that aren't in the `%pagesources` hash, and since the file in question was already there because it had been put there before the exclude regex was changed, it wasn't even being checked! + +[[KathrynAndersen]] + +"""]] diff --git a/doc/forum/PageSpec_results_from_independent_checkout.mdwn b/doc/forum/PageSpec_results_from_independent_checkout.mdwn index 6b2fd6df0..693287d2b 100644 --- a/doc/forum/PageSpec_results_from_independent_checkout.mdwn +++ b/doc/forum/PageSpec_results_from_independent_checkout.mdwn @@ -3,3 +3,6 @@ I'd like to be able to do PageSpec matches independent of the Ikiwiki checkout, perl -MIkiWiki -le '$config{wikistatedir}=".ikiwiki"; IkiWiki::loadindex(); print foreach pagespec_match_list("", shift)' "bugs/*" I get the impression there's a way to build up enough state to run pagespec matches without doing any rendering, but I don't know how. Any ideas? -- JoeRayhawk + +> It's not possible to build up enough state without at a minimum +> performing the scan pass of rendering on every page. --[[Joey]] diff --git a/doc/forum/cutpaste.pm_not_only_file-local.mdwn b/doc/forum/cutpaste.pm_not_only_file-local.mdwn index 3563e3e01..0c5221cc9 100644 --- a/doc/forum/cutpaste.pm_not_only_file-local.mdwn +++ b/doc/forum/cutpaste.pm_not_only_file-local.mdwn @@ -3,7 +3,7 @@ has \[[!cut id=foo text="foo"]], and fileB does \[[!absorb pagenames=fileA]], and can then use \[[!paste id=foo]]. Therefore, I've written an [*absorb* directive / -plugin](http://www.thomas.schwinge.homeip.net/tmp/absorb.pm), which is meant to +plugin](http://schwinge.homeip.net/~thomas/tmp/absorb.pm), which is meant to absorb pages in order to get hold of their *cut* and *copy* directives' contents. This does work as expected. But it also absorbs page fileA's *meta* values, like a *meta title*, etc. How to avoid / solve this? diff --git a/doc/forum/field_and_forms/comment_1_a0e976cb79f03dcff5e9a4511b90d160._comment b/doc/forum/field_and_forms/comment_1_a0e976cb79f03dcff5e9a4511b90d160._comment new file mode 100644 index 000000000..3e10dbbd9 --- /dev/null +++ b/doc/forum/field_and_forms/comment_1_a0e976cb79f03dcff5e9a4511b90d160._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="http://kerravonsen.dreamwidth.org/" + ip="60.241.8.244" + subject="Limitations" + date="2010-11-23T02:18:52Z" + content=""" +I'd already had a look at this idea before you posted this suggestion, and I ran into difficulties. +So far as I can see, it makes most sense to use the mechanisms already in place for editing pages, and enhance them. +Unfortunately, the whole edit-page setup expects a template file (by default, when editing pages, editpage.tmpl) +and anything apart from \"submit\" buttons must have a placeholder in the template file, or it doesn't get displayed at all in the form. +At least, that's what I've found - I could be mistaken. + +But if it's true, that rather puts the kybosh on dynamically generated forms, so far as I can see. +I mean, if you knew beforehand what all your fields were going to be, you could make a copy of editpage.tmpl, add in your fields where you want, and then make a plugin that uses that template instead of editpage.tmpl, but that's very limited. + +If someone could come up with a way of making dynamic forms, that would solve the problem, but I've come up against a brick wall myself. Joey? Anyone? + +-- [[KathrynAndersen]] +"""]] diff --git a/doc/forum/ikiwiki_+_mathjax.mdwn b/doc/forum/ikiwiki_+_mathjax.mdwn new file mode 100644 index 000000000..1279a2c80 --- /dev/null +++ b/doc/forum/ikiwiki_+_mathjax.mdwn @@ -0,0 +1 @@ +Is it possible to use [mathjax](http://www.mathjax.org/) in ikiwiki to typeset math formulas? If so, is this compatible with the [wmd](http://ikiwiki.info/plugins/wmd/) plugin? diff --git a/doc/ikiwiki/directive/if.mdwn b/doc/ikiwiki/directive/if.mdwn index 2cbf70cdf..492adf499 100644 --- a/doc/ikiwiki/directive/if.mdwn +++ b/doc/ikiwiki/directive/if.mdwn @@ -43,6 +43,8 @@ with the following additional tests: * included() - Tests whether the page is being included onto another page. + Tests whether the page is being included onto another page, for example + via [[inline]] or [[map]]. Note that pages inserted into other pages + via [[template]] are not matched here. [[!meta robots="noindex, follow"]] diff --git a/doc/ikiwiki/directive/more.mdwn b/doc/ikiwiki/directive/more.mdwn index 506551910..bda1427f3 100644 --- a/doc/ikiwiki/directive/more.mdwn +++ b/doc/ikiwiki/directive/more.mdwn @@ -11,6 +11,11 @@ leads to the full version of the page. Use it like this: If the `linktext` parameter is omitted it defaults to just "more". +An optional `pages` parameter can be used to specify a +[[ikiwiki/PageSpec]], and then the "more" link will only be displayed +when the page is inlined into a page matching that PageSpec, and otherwise +the full content shown. + Note that you can accomplish something similar using a [[toggle]] instead. [[!meta robots="noindex, follow"]] diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn index 2836d96e5..699eeda7d 100644 --- a/doc/ikiwikiusers.mdwn +++ b/doc/ikiwikiusers.mdwn @@ -159,6 +159,9 @@ Personal sites and blogs * [weakish](http://weakish.github.com) * [Thomas Kane](http://planetkane.org/) * [Marco Silva](http://marcot.eti.br/) a weblog + wiki using the [darcs](http://darcs.net) backend +* [NeX-6](http://nex-6.taht.net/) ikiwiki blog and wiki running over ipv6 +* [Jason Riedy](http://lovesgoodfood.com/jason/), which may occasionally look funny if I'm playing with my branch... +* [pmate](http://pmate.nfshost.com)'s homepage and [blog](http://pmate.nfshost.com/blog/) Please feel free to add your own ikiwiki site! diff --git a/doc/news/openid.mdwn b/doc/news/openid.mdwn index 025a07802..87f640321 100644 --- a/doc/news/openid.mdwn +++ b/doc/news/openid.mdwn @@ -10,4 +10,4 @@ log back in, try out the OpenID signup process if you don't already have an OpenID, and see how OpenID works for you. And let me know your feelings about making such a switch. --[[Joey]] -[[!poll 67 "Accept only OpenID for logins" 21 "Accept only password logins" 37 "Accept both"]] +[[!poll 67 "Accept only OpenID for logins" 21 "Accept only password logins" 41 "Accept both"]] diff --git a/doc/news/version_3.20100815.mdwn b/doc/news/version_3.20100815.mdwn deleted file mode 100644 index 1073933a1..000000000 --- a/doc/news/version_3.20100815.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -ikiwiki 3.20100815 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * Fix po test suite to not assume ikiwiki's underlay is already installed. - Closes: #[593047](http://bugs.debian.org/593047)"""]]
\ No newline at end of file diff --git a/doc/news/version_3.20100831.mdwn b/doc/news/version_3.20100831.mdwn deleted file mode 100644 index 152e3c2f7..000000000 --- a/doc/news/version_3.20100831.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -ikiwiki 3.20100831 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * filecheck: Fall back to using the file command if the freedesktop - magic file cannot identify a file. - * flattr: New plugin. (Thanks to jaywalk for the initial implementation - at a flattr plugin! This one is less configurable, but simpler.) - * smiley: warn instead of error for missing smileys (Giuseppe Bilotta) - * openid: Syntax tweak to the javascript code to make it work with MSIE 7 - (and MSIE 8 in compat mode). Thanks to Iain McLaren for reporting - the bug and providing access to debug it. - * style.css: Use relative, not absolute font sizes. Thanks, Giuseppe Bilotta. - * htmlscrubber: Do not scrub url anchors that contain colons. - * Danish translation update. Closes: #[594673](http://bugs.debian.org/594673) - * highlight: Make location of highlight's files configurable in setup - file to allow for nonstandard installations. - * Allow "link(.)" and similar PageSpecs. Thanks, Giuseppe Bilotta. - * Run the preprocess hooks in scan mode *before* the scan hooks. - This allows the po plugin to register a scan hook that runs - last and rescans pages after all data from the first scan pass is - completed. This avoids the po plugin needing to rebuild some pages. - (intrigeri) - * po: Fix some bugs that affected l10n.ikiwiki.info's unusual - setup. (intrigeri) - * t/bazaar.t: Work around bzr 2.2.0's new requirement to configure - bzr whoami before committing. - * httpauth: Avoid redirecting the user to the cgiauthurl if - they already have a login session."""]]
\ No newline at end of file diff --git a/doc/news/version_3.20101023.mdwn b/doc/news/version_3.20101023.mdwn new file mode 100644 index 000000000..44bed6be6 --- /dev/null +++ b/doc/news/version_3.20101023.mdwn @@ -0,0 +1,4 @@ +ikiwiki 3.20101023 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * Fix typo that broke anonymous git push. + * Fix web reversion when the srcdir is in a subdir of the git repo."""]]
\ No newline at end of file diff --git a/doc/news/version_3.20101112.mdwn b/doc/news/version_3.20101112.mdwn new file mode 100644 index 000000000..ad591445f --- /dev/null +++ b/doc/news/version_3.20101112.mdwn @@ -0,0 +1,17 @@ +ikiwiki 3.20101112 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * txt: Fix display when used inside a format directive. + * highlight: Ensure that other, more-specific format plugins, + like txt are used in preference to this one in case of ties. + * htmltidy, sortnaturally: Add missing checkconfig hook + registration. Closes: #[601912](http://bugs.debian.org/601912) + (Thanks, Craig Lennox and Tuomas Jormola) + * git: Use author date, not committer date. Closes: #[602012](http://bugs.debian.org/602012) + (Thanks, Tuomas Jormola) + * Fix htmlscrubber\_skip to be matched on the source page, not the page it is + inlined into. Should allow setting to "* and !comment(*)" to scrub + comments, but leave your blog posts unscrubbed, etc. + * comments: Make postcomment() pagespec work when previewing a comment, + including during moderation. + * comments: Make comment() pagespec also match comments that are being + posted."""]]
\ No newline at end of file diff --git a/doc/plugins/autoindex/discussion.mdwn b/doc/plugins/autoindex/discussion.mdwn index 2d6b6f1f0..76d09cd3c 100644 --- a/doc/plugins/autoindex/discussion.mdwn +++ b/doc/plugins/autoindex/discussion.mdwn @@ -1,6 +1,13 @@ Would it be possible to add an option to only generate the index files for the html output and not place the markdown files in the wiki source? +> Or better still, add a mechanism for ikiwiki to hold transient source +> pages in memory and render them as if they existed, without actually +> writing them out, as [[JoeRayhawk]] suggests below? I think +> add_autofile would be the way to do this. +> I've added this to [[todo]] as [[todo/autoindex should use add__95__autofile]] +> and [[todo/transient_pages]]. --[[smcv]] + The reason being that I have a lot of directories which need to be autoindexed, but I would prefer if the index files didn't clutter up my git repository. @@ -15,6 +22,8 @@ If you just don't want to clutter your git repo, below it's a patch does the fol * If you set autoindex_commit to 1 (this is the default), auto-generated index files will be put in the repo provided you enabled rcs backend. +[[!toggle id="patch-for-autoindex_commit" text="patch for autoindex_commit"]] +[[!toggleable id="patch-for-autoindex_commit" text=""" <pre> --- autoindex.pm.orig 2009-10-01 17:13:51.000000000 +0800 +++ autoindex.pm 2009-10-01 17:21:09.000000000 +0800 @@ -58,6 +67,18 @@ If you just don't want to clutter your git repo, below it's a patch does the fol gettext("automatic index generation"), undef, undef); </pre> - +"""]] Warning: I guess this patch may work, but I *haven't tested it yet*. -- [[weakish]] + +------ + +`autoindex_commit => 0` would be nice, but uncommited files are definitely not. +<pre> +remote: From /srv/git/test3 +remote: 3047077..1df636c master -> origin/master +remote: error: Untracked working tree file 'test.mdwn' would be overwritten by merge. Aborting +remote: 'git pull --prune origin' failed: at /usr/share/perl5/IkiWiki/Plugin/git.pm line 201. +</pre> + +It'd be nice if we were able to notice directories with no associated compilable markup files and compile a simple map directive straight to HTML without any intermediate markup file being involved at all. -- JoeRayhawk diff --git a/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn b/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn index b9ad3cc8e..16c147b68 100644 --- a/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn +++ b/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn @@ -6,9 +6,9 @@ Someone was just asking for it and I had written these two plugins already some months ago, so I'm now publishing them here. -[`copyright.pm`](http://www.schwinge.homeip.net/~thomas/tmp/copyright.pm) +[`copyright.pm`](http://schwinge.homeip.net/~thomas/tmp/copyright.pm) and -[`license.pm`](http://www.schwinge.homeip.net/~thomas/tmp/license.pm) +[`license.pm`](http://schwinge.homeip.net/~thomas/tmp/license.pm) Usage instructions are found inside the two plugin files. @@ -45,3 +45,10 @@ by ikiwiki are likewise fine. --[[tschwinge]] > and can extend beyond just copyright and license, but has the disadvantage > that it doesn't support setting defaults for a given "subdirectory" > only. --[[smcv]] + +[[!template id=gitbranch branch=smcv/contrib/defcopyright author="[[tschwinge]]"]] + +> For `./gitremotes` convenience (taking the Linus approach to backups :-) ) +> I've added this to my git repository as a branch. No review, approval or +> ownership is implied, feel free to replace this with a branch in any other +> repository --[[smcv]] diff --git a/doc/plugins/contrib/ikiwiki/directive/ymlfront.mdwn b/doc/plugins/contrib/ikiwiki/directive/ymlfront.mdwn index bb4a58fc6..1a01834f8 100644 --- a/doc/plugins/contrib/ikiwiki/directive/ymlfront.mdwn +++ b/doc/plugins/contrib/ikiwiki/directive/ymlfront.mdwn @@ -14,4 +14,4 @@ There is one argument to this directive. The YAML-format data. This should be enclosed inside triple-quotes to preserve the data correctly. If more than one ymlfront directive is given per page, the result is undefined. -Likewise, it is inadvisable to try to mix the "---" ymlfront format with the directive form of the data. +Likewise, it is inadvisable to try to mix the non-directive ymlfront format with the directive form of the data. diff --git a/doc/plugins/contrib/texinfo.mdwn b/doc/plugins/contrib/texinfo.mdwn index 595bd27aa..a2769166d 100644 --- a/doc/plugins/contrib/texinfo.mdwn +++ b/doc/plugins/contrib/texinfo.mdwn @@ -8,7 +8,7 @@ This plugin is not neccessarily meant to enable people to write arbitrary wiki pages in the Texinfo format (even though that is possible, of course), but rather to ease collaboration on existing Texinfo documents. -The plugin is available at <http://www.schwinge.homeip.net/~thomas/tmp/texinfo.pm>. +The plugin is available at <http://schwinge.homeip.net/~thomas/tmp/texinfo.pm>. It's very basic at the moment, but will be improved over time. diff --git a/doc/plugins/contrib/ymlfront.mdwn b/doc/plugins/contrib/ymlfront.mdwn index a2c649044..2805be04f 100644 --- a/doc/plugins/contrib/ymlfront.mdwn +++ b/doc/plugins/contrib/ymlfront.mdwn @@ -10,6 +10,9 @@ IkiWiki::Plugin::ymlfront - add YAML-format data to a page # activate the plugin add_plugins => [qw{goodstuff ymlfront ....}], + # configure the plugin + ymlfront_delim => [qw(--YAML-- --YAML--)], + ## DESCRIPTION This plugin provides a way of adding arbitrary meta-data (data fields) to any @@ -25,23 +28,57 @@ This plugin is meant to be used in conjunction with the [[field]] plugin. ## DETAILS -If one is not using the ymlfront directive, the YAML-format data in a page -must be placed at the start of the page and delimited by lines containing -precisely three dashes. The "normal" content of the page then follows. +There are three formats for adding YAML data to a page. These formats +should not be mixed - the result is undefined. -For example: +1. ymlfront directive + + See [[ikiwiki/directive/ymlfront]] for more information. - --- - title: Foo does not work - Urgency: High - Status: Assigned - AssignedTo: Fred Nurk - Version: 1.2.3 - --- - When running on the Sprongle system, the Foo function returns incorrect data. +2. default YAML-compatible delimiter + + By default, the YAML-format data in a page is placed at the start of + the page and delimited by lines containing precisely three dashes. + This is what YAML itself uses to delimit multiple documents. + The "normal" content of the page then follows. + + For example: + + --- + title: Foo does not work + Urgency: High + Status: Assigned + AssignedTo: Fred Nurk + Version: 1.2.3 + --- + When running on the Sprongle system, the Foo function returns incorrect data. + + What will normally be displayed is everything following the second line of dashes. That will be htmlized using the page-type of the page-file. + +3. user-defined delimiter + + Instead of using the default "---" delimiter, the user can define, + in the configuration file, the **ymlfront_delim** value, which is an + array containing two strings. The first string defines the markup for + the start of the YAML data, and the second string defines the markip + for the end of the YAML data. These two strings can be the same, or + they can be different. In this case, the YAML data section is not + required to be at the start of the page, but as with the default, it + is expected that only one data section will be on the page. + + For example: + + --YAML-- + title: Foo does not work + Urgency: High + Status: Assigned + AssignedTo: Fred Nurk + Version: 1.2.3 + --YAML-- + When running on the Sprongle system, the Foo function returns incorrect data. -What will normally be displayed is everything following the second line of dashes. -That will be htmlized using the page-type of the page-file. + What will normally be displayed is everything outside the delimiters, + both before and after. That will be htmlized using the page-type of the page-file. ### Accessing the Data diff --git a/doc/plugins/htmlscrubber.mdwn b/doc/plugins/htmlscrubber.mdwn index c59b46e14..080575c46 100644 --- a/doc/plugins/htmlscrubber.mdwn +++ b/doc/plugins/htmlscrubber.mdwn @@ -32,10 +32,11 @@ other HTML-related functionality, such as whether [[meta]] allows potentially unsafe HTML tags. The `htmlscrubber_skip` configuration setting can be used to skip scrubbing -of some pages. Set it to a [[ikiwiki/PageSpec]], such as "!*/Discussion", -and pages matching that can have all the evil CSS, JavsScript, and unsafe -html elements you like. One safe way to use this is to use [[lockedit]] to -lock those pages, so only admins can edit them. +of some pages. Set it to a [[ikiwiki/PageSpec]], such as +"posts/* and !comment(*) and !*/Discussion", and pages matching that can have +all the evil CSS, JavsScript, and unsafe html elements you like. One safe +way to use this is to use [[lockedit]] to lock those pages, so only admins +can edit them. ---- diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn index c665e67f0..df9d688b8 100644 --- a/doc/sandbox.mdwn +++ b/doc/sandbox.mdwn @@ -1,3 +1,5 @@ +Hello, world! + This is the [[SandBox]], a page anyone can edit to try out ikiwiki (version [[!version ]]). diff --git a/doc/sandbox/D-Liberative.wiki b/doc/sandbox/D-Liberative.wiki new file mode 100644 index 000000000..b8c94f310 --- /dev/null +++ b/doc/sandbox/D-Liberative.wiki @@ -0,0 +1 @@ +For now its just a concept... what if a community could map its deliberative capacity? diff --git a/doc/sandbox/Mooooo.mdwn b/doc/sandbox/Mooooo.mdwn new file mode 100644 index 000000000..6f11d357c --- /dev/null +++ b/doc/sandbox/Mooooo.mdwn @@ -0,0 +1 @@ +Hrm. diff --git a/doc/sandbox/Testing_blog_entry.mdwn b/doc/sandbox/Testing_blog_entry.mdwn new file mode 100644 index 000000000..aa5fa5b20 --- /dev/null +++ b/doc/sandbox/Testing_blog_entry.mdwn @@ -0,0 +1,7 @@ +# Be cool, this is a test! + +Hello guys, this is *just a test* entry. + +* Did I say +* that I love +* bulleted lists? diff --git a/doc/security.mdwn b/doc/security.mdwn index 34a005239..4fa531eb1 100644 --- a/doc/security.mdwn +++ b/doc/security.mdwn @@ -440,3 +440,16 @@ with the release of ikiwiki 3.20100312. A fix was also backported to Debian etch, as version 2.53.5. I recommend upgrading to one of these versions if your wiki can be edited by third parties. + +## javascript insertation via insufficient htmlscrubbing of comments + +Kevin Riggle noticed that it was not possible to configure +`htmlscrubber_skip` to scrub comments while leaving unscubbed the text +of eg, blog posts. Confusingly, setting it to "* and !comment(*)" did not +scrub comments. + +Additionally, it was discovered that comments' html was never scrubbed during +preview or moderation of comments with such a configuration. + +These problems were discovered on 12 November 2010 and fixed the same +hour with the release of ikiwiki 3.20101112. ([[!cve CVE-2010-1673]]) diff --git a/doc/setup/byhand.mdwn b/doc/setup/byhand.mdwn index 86cff5af4..75a5648d5 100644 --- a/doc/setup/byhand.mdwn +++ b/doc/setup/byhand.mdwn @@ -104,7 +104,7 @@ is ok, run `ikiwiki --setup ikiwiki.setup`, and you're done! There are lots of other configuration options in ikiwiki.setup that you can uncomment, configure, and enable by re-running `ikiwiki --setup ikiwiki.setup`. Be sure to browse through all the -[[plugins]].. +[[plugins]]. ## Put your wiki in revision control. diff --git a/doc/tips/nearlyfreespeech.mdwn b/doc/tips/nearlyfreespeech.mdwn index 4b3b02eac..a3d1ec678 100644 --- a/doc/tips/nearlyfreespeech.mdwn +++ b/doc/tips/nearlyfreespeech.mdwn @@ -14,7 +14,8 @@ After you [get an account](https://www.nearlyfreespeech.net/about/start.php), create a site using their web interface. Mine is named `ikiwiki-test` and I used their DNS instead of getting my -own, resulting in <http://ikiwiki-test.nfshost.com/> +own, resulting in <http://ikiwiki-test.nfshost.com/>. (Not being kept up +anymore.) They gave me 2 cents free funding for signing up, which is enough to pay for 10 megabytes of bandwidth, or about a thousand typical page views, at diff --git a/doc/tips/nearlyfreespeech/discussion.mdwn b/doc/tips/nearlyfreespeech/discussion.mdwn index a003760b9..b76432566 100644 --- a/doc/tips/nearlyfreespeech/discussion.mdwn +++ b/doc/tips/nearlyfreespeech/discussion.mdwn @@ -9,3 +9,14 @@ BEGIN failed--compilation aborted at (eval 19) line 2. perl is 5.8.9 > This is fixed in 3.1415926. --[[Joey]] + + +Hi!<br /> +How can i upgrade my nearlyfreespeech installation of ikiwiki? To install it i have followed your instructions here.<br> +But now if I want to upgrade it to a newer version?<br /> +Thanks for your incredible work! + +> You can move `~/ikiwiki` out of the way and then re-download and install +> it ikiwiki. --[[Joey]] + +Thanks a lot Joey. :-) diff --git a/doc/todo/Add_nicer_math_formatting.mdwn b/doc/todo/Add_nicer_math_formatting.mdwn index 6e082c102..3a5e94a14 100644 --- a/doc/todo/Add_nicer_math_formatting.mdwn +++ b/doc/todo/Add_nicer_math_formatting.mdwn @@ -21,4 +21,6 @@ It would be nice to add nicer math formatting. I currently use the > I've posted a question about this to its forum: --[[Joey]] > <https://sourceforge.net/projects/jsmath/forums/forum/592273/topic/3831574> +I think [mathjax](http://www.mathjax.org/) would be the best option. This is the math rendering engine used in mathoverflow. + [[!tag wishlist]] diff --git a/doc/todo/Improving_the_efficiency_of_match__95__glob.mdwn b/doc/todo/Improving_the_efficiency_of_match__95__glob.mdwn new file mode 100644 index 000000000..4e1df3381 --- /dev/null +++ b/doc/todo/Improving_the_efficiency_of_match__95__glob.mdwn @@ -0,0 +1,228 @@ +[[!template id=gitbranch branch=smcv/ready/glob-cache + author="[[KathrynAndersen]], [[smcv]]"]] +[[!tag patch]] + +I've been profiling my IkiWiki to try to improve speed (with many pages makes speed even more important) and I've written a patch to improve the speed of match_glob. This matcher is a good one to improve the speed of, because it gets called so many times. + +Here's my patch - please consider it! -- [[KathrynAndersen]] + +> It seems to me as though changing `glob2re` to return qr/$re/, and calling +> `memoize(glob2re)` next to the other memoize calls, would be a less +> verbose way to do this? --[[smcv]] + +>> I think so, yeah. Anyway, do you have any benchmark results handy, +>> Kathryn? --[[Joey]] + +>>> See below. +>>> Also, would it make more sense for glob2re to return qr/^$re$/i rather than qr/$re/? Everything that uses glob2re seems to use + $foo =~ /^$re$/i +>>> rather than /$re/ so I think that would make sense. +>>> -- [[KathrynAndersen]] + +>>>> Git branch `smcv/ka-glob-cache` has Kathryn's patch. Git +>>>> branch `smcv/memoize-glob2re` does as I suggested, which +>>>> is less verbose than Kathryn's patch but also not as +>>>> fast; I'm not sure why, tbh. --[[smcv]] + +>>>>> I think it's because my patch focuses on match_glob while the memoize patch focuses on `glob2re`, and `glob2re` is called in `filecheck`, `meta` and `po` as well as in `match_glob` and `match_user`; thus the memoized `glob2re` is dealing with a bigger set of globs to look up, and thus could be just that little bit slower. -- [[KathrynAndersen]] + +>>>>>> What may be going on is that glob2re is already a fairly fast +>>>>>> function, so the overhead of memoizing it with the very generic +>>>>>> `_memoizer` (see its source) swamps the memoization gain. Note +>>>>>> that the few functions memoized with the Memoizer before were much +>>>>>> more expensive, so that little overhead was acceptable then. +>>>>>> +>>>>>> It also may be that Kathryn's patch is slightly faster due to using +>>>>>> the construct `$foo =~ $regexp` rather than `$foo =~ /$regexp/` +>>>>>> (probably avoids a copy or something like that internally) -- +>>>>>> this despite checking both `exists` and `defined` on the hash, which +>>>>>> should be reundant AFAICS. +>>>>>> +>>>>>> My guess is that the best of both worlds would be to move +>>>>>> the byhand memoization to glob2re and have it return a compiled +>>>>>> `/^/i` regexp that can be used without further modifiction in most +>>>>>> cases. --[[Joey]] + +>>>>>>> Done, see `smcv/ready/glob-cache` and `smcv/glob-cache-too-far`. +>>>>>>> +>>>>>>> Kathryn's patch is a significant improvement; my first patch on top of +>>>>>>> that is a trivial cleanup that speeds it up a little, and the next two +>>>>>>> patches (using precompiled regexes) have surprisingly little effect +>>>>>>> (they don't slow it down either though, so either omit them or merge +>>>>>>> them, whichever). Detailed benchmark results below. +>>>>>>> +>>>>>>> Moving the memoization to `glob2re` actually seems to slow things down +>>>>>>> again - I suspect the docwiki has few enough mentions of `user()` etc. +>>>>>>> that caching them is a waste of time, but perhaps it's not the most +>>>>>>> representative. +>>>>>>> --[[smcv]] + +[[done]] --[[Joey]] + +-------------------------------------------------------------- + +[[!toggle id="smcv-benchmark" text="current benchmarks"]] + +[[!toggleable id="smcv-benchmark" text=""" +master at time of branch: + + time elapsed (wall): 29.6348 + time running program: 24.9212 (84.09%) + time profiling (est.): 4.7136 (15.91%) + number of calls: 1360181 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 13.24 3.2986 3408 0.000968 Text::Balanced::_match_tagged + 10.94 2.7253 79514 0.000034 IkiWiki::PageSpec::match_glob + 3.19 0.7952 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +`Improve the speed of match_glob`: + + time elapsed (wall): 27.9755 + time running program: 23.5293 (84.11%) + time profiling (est.): 4.4461 (15.89%) + number of calls: 1280875 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 14.56 3.4257 3408 0.001005 Text::Balanced::_match_tagged + 7.82 1.8403 79514 0.000023 IkiWiki::PageSpec::match_glob + 3.27 0.7698 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +`match_glob: streamline glob cache slightly`: + + time elapsed (wall): 27.5753 + time running program: 23.1714 (84.03%) + time profiling (est.): 4.4039 (15.97%) + number of calls: 1280875 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 14.09 3.2637 3408 0.000958 Text::Balanced::_match_tagged + 7.74 1.7926 79514 0.000023 IkiWiki::PageSpec::match_glob + 3.30 0.7646 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +`glob2re: return a precompiled, anchored case-insensitiv...`: + + time elapsed (wall): 27.5656 + time running program: 23.1464 (83.97%) + time profiling (est.): 4.4192 (16.03%) + number of calls: 1282189 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 14.21 3.2891 3408 0.000965 Text::Balanced::_match_tagged + 7.72 1.7872 79514 0.000022 IkiWiki::PageSpec::match_glob + 3.32 0.7678 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +`make use of precompiled regex objects`: + + time elapsed (wall): 27.5357 + time running program: 23.1289 (84.00%) + time profiling (est.): 4.4068 (16.00%) + number of calls: 1281981 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 14.17 3.2776 3408 0.000962 Text::Balanced::_match_tagged + 7.70 1.7814 79514 0.000022 IkiWiki::PageSpec::match_glob + 3.35 0.7756 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +`move memoization from match_glob to glob2re`: + + time elapsed (wall): 28.7677 + time running program: 23.9473 (83.24%) + time profiling (est.): 4.8205 (16.76%) + number of calls: 1360181 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 13.98 3.3469 3408 0.000982 Text::Balanced::_match_tagged + 8.85 2.1194 79514 0.000027 IkiWiki::PageSpec::match_glob + 3.24 0.7750 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +--[[smcv]] +"""]] + +-------------------------------------------------------------- + +[[!toggle id="ka-benchmarks" text="Kathryn's benchmarks"]] + +[[!toggleable id="ka-benchmarks" text=""" +Benchmarks done with Devel::Profile on the same testbed IkiWiki setup. I'm just showing the start of the profile output, since that's what's relevant. + +Before: +<pre> +time elapsed (wall): 27.4173 +time running program: 22.5909 (82.40%) +time profiling (est.): 4.8264 (17.60%) +number of calls: 1314729 +number of exceptions: 65 + +%Time Sec. #calls sec/call F name +11.05 2.4969 62333 0.000040 IkiWiki::PageSpec::match_glob + 4.10 0.9261 679 0.001364 Text::Balanced::_match_tagged + 2.72 0.6139 59812 0.000010 IkiWiki::SuccessReason::merge_influences +</pre> + +After: +<pre> +time elapsed (wall): 26.1843 +time running program: 21.5673 (82.37%) +time profiling (est.): 4.6170 (17.63%) +number of calls: 1252433 +number of exceptions: 65 + +%Time Sec. #calls sec/call F name + 7.66 1.6521 62333 0.000027 IkiWiki::PageSpec::match_glob + 4.33 0.9336 679 0.001375 Text::Balanced::_match_tagged + 2.81 0.6057 59812 0.000010 IkiWiki::SuccessReason::merge_influences +</pre> + +Note that the seconds per call for match_glob in the "after" case has gone down by about a third. + +K.A. +"""]] + +-------------------------------------------------------------- + +[[!toggle id="ka-patch" text="Kathryn's original patch"]] + +[[!toggleable id="ka-patch" text=""" + +<pre> +diff --git a/IkiWiki.pm b/IkiWiki.pm +index 08a3d78..c187b98 100644 +--- a/IkiWiki.pm ++++ b/IkiWiki.pm +@@ -2482,6 +2482,8 @@ sub derel ($$) { + return $path; + } + ++my %glob_cache; ++ + sub match_glob ($$;@) { + my $page=shift; + my $glob=shift; +@@ -2489,8 +2491,15 @@ sub match_glob ($$;@) { + + $glob=derel($glob, $params{location}); + +- my $regexp=IkiWiki::glob2re($glob); +- if ($page=~/^$regexp$/i) { ++ # Instead of converting the glob to a regex every time, ++ # cache the compiled regex to save time. ++ if (!exists $glob_cache{$glob} ++ or !defined $glob_cache{$glob}) ++ { ++ my $re=IkiWiki::glob2re($glob); ++ $glob_cache{$glob} = qr/^$re$/i; ++ } ++ if ($page =~ $glob_cache{$glob}) { + if (! IkiWiki::isinternal($page) || $params{internal}) { + return IkiWiki::SuccessReason->new("$glob matches $page"); + } +</pre> +"""]] +-------------------------------------------------------------- diff --git a/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn b/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn index 61b19d302..b3804d652 100644 --- a/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn +++ b/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn @@ -4,7 +4,7 @@ to the [[`meta`_plugin|plugins/meta]]. > [[done]], with some changes --[[Joey]] Find the most recent version at -<http://www.schwinge.homeip.net/~thomas/tmp/meta_forward.patch>. +<http://schwinge.homeip.net/~thomas/tmp/meta_forward.patch>. I can't use `scrub(...)`, as that will strip out the forwarding HTML command. How to deal with that? diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 92c3b7695..16dc78fb2 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -260,5 +260,8 @@ required to implement [[todo/alias directive]], which couldn't be easily done by writing to the RCS as the page's contents can change depending on which other pages claim it as an alias. --[[chrysn]] +I agree with [[chrysn]]. In fact, is there any good reason that the core tag plugin doesn't do this? The current usability is horrible, to the point that I have gone 2.5 years with Ikiwiki and haven't yet started using tags. -- + +> See [[todo/transient_pages]] for progress on this. --[[smcv]] [[!tag done]] diff --git a/doc/todo/autoindex_should_use_add__95__autofile.mdwn b/doc/todo/autoindex_should_use_add__95__autofile.mdwn new file mode 100644 index 000000000..19c5004f8 --- /dev/null +++ b/doc/todo/autoindex_should_use_add__95__autofile.mdwn @@ -0,0 +1,4 @@ +`add_autofile` is a generic version of [[plugins/autoindex]]'s code, +so the latter should probably use the former. --[[smcv]] + +> See [[todo/transient_pages]] for progress on this. --[[smcv]] diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn index 29f28ca32..556240964 100644 --- a/doc/todo/passwordauth:_sendmail_interface.mdwn +++ b/doc/todo/passwordauth:_sendmail_interface.mdwn @@ -35,7 +35,7 @@ in the ikiwiki source code, where emailing is done. OK, so I'll have a look at replacing all email handling with *Email::Send*. [[!tag patch]] -*<http://www.thomas.schwinge.homeip.net/tmp/ikiwiki-sendmail.patch>* +*<http://schwinge.homeip.net/~thomas/tmp/ikiwiki-sendmail.patch>* Remaining TODOs: diff --git a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn index c4e78ca0b..d55fc0aa8 100644 --- a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn +++ b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn @@ -5,9 +5,14 @@ features and thus makes it rather hard to give an ikiwiki site a consistent look. If you browse the templates provided in the tarball, you'll notice that more than one of them contain the `<html>` tag, which is unnecessary. +> Note that is no longer true, and I didn't have to do such an intrusive +> change to fix it either. --[[Joey]] + Maybe it's just me, I also find HTML::Template cumbersome to use, due in part to its use of capital letters. +> Its entirely optional use of capital letters? --[[Joey]] + Finally, the software seems unmaintained: the mailing list and searchable archives linked from <http://html-template.sourceforge.net/html_template.html#frequently%20asked%20questions> @@ -58,3 +63,25 @@ Yes, Template::Toolkit is very powerful. But I think it's somehow overkill for a I'd have to agree that Template::Toolkit is overkill and personally I'm not a fan, but it is very popular (there is even a book) and the new version (3) is alleged to be much more nimble than current version. --[[ajt]] HTML::Template's HTML-like markup prevents me from editing templates in KompoZer or other WYSIWYG HTML editors. The editor tries to render the template markup rather than display it verbatim, and large parts of the template become invisible. A markup syntax that doesn't confuse editors (such as Template::Toolkit's "[% FOO %]") may promote template customization. The ability to replace the template engine would be within the spirit of ikiwiki's extensibility. --Rocco + + +I agree that being able to replace the template toolkit would be a great piece of modularity, and one I would use. If I could use the slot-based filling and the conditional logic from Template::Toolkit, we could build much more flexible inline and archivepage templates that would look different depending on where in the wiki we use them. Some of this can currently be accomplished with separate templates for each use case and a manual call to the right template in the !inline directive, but this is limited, cumbersome, and makes it difficult to reuse bits of formatting by trapping all of that information in multiple template files. -Ian + +> I don't wish HTML::Template to be *replaced* by Template::Toolkit - as +> others have said above, it's overkill for my needs. However, I also +> agree that HTML::Template has its own problems too. The idea of making +> the template system modular, with a choice of which backend to use - I +> really like that idea. It would enable me to use some other template +> system I like better, such as Text::Template or Text::NeatTemplate. But I +> think it would be a lot of work to implement, though perhaps no more work +> than making the revision-control backend modular, I guess. One would +> need to write an IkiWiki template interface that didn't care what the +> backend was, and yet is somehow still flexible enough to take advantage +> of special features of different backends. There are an *awful lot* of +> things that use templates - not just the `pagetemplate` and `template` +> plugins, but a number of others which have specialized templates of their +> own. -- [[KathrynAndersen]]a + +>> A modular template system in ikiwiki is unlikely, as template objects +>> are part of the API, notably the `pagetemplate` hook. Unless the other +>> system has a compatible template object. --[[Joey]] diff --git a/doc/todo/selective_more_directive.mdwn b/doc/todo/selective_more_directive.mdwn new file mode 100644 index 000000000..2a9998205 --- /dev/null +++ b/doc/todo/selective_more_directive.mdwn @@ -0,0 +1,28 @@ +I'm setting up a blog for NaNoWriMo and other story-writing, which means long posts every day. I want to have excerpts on the front page, which link to the full length story posts. I also want a dedicated page for each story which inlines the story in full and in chronological order. I can use the "more" directive to achieve this effect on the front page but then it spoils the story page. My solution was to add a pages= parameter to the more directive to make it more selective. + + --- /usr/share/perl5/IkiWiki/Plugin/more.pm 2010-10-09 00:09:24.000000000 +0000 + +++ .ikiwiki/IkiWiki/Plugin/more.pm 2010-11-01 20:24:59.000000000 +0000 + @@ -26,7 +26,10 @@ + + $params{linktext} = $linktext unless defined $params{linktext}; + + - if ($params{page} ne $params{destpage}) { + + if ($params{page} ne $params{destpage} && + + (! exists $params{pages} || + + pagespec_match($params{destpage}, $params{pages}, + + location => $params{page}))) { + return "\n". + htmllink($params{page}, $params{destpage}, $params{page}, + linktext => $params{linktext}, + +I can now call it as + + \[[!more pages="index" linktext="Chapter 1" text=""" + etc + """]] + +I'm not entirely happy with the design, since I would rather put this information in the inline directive instead of in every story post. Unfortunately I found no way to pass parameters from the inline directive to the inlined page. + +-- [[dark]] + +> Me neither, but nor do I see a better way, so [[applied|done]]. --[[Joey]] diff --git a/doc/todo/transient_pages.mdwn b/doc/todo/transient_pages.mdwn new file mode 100644 index 000000000..9c1be7362 --- /dev/null +++ b/doc/todo/transient_pages.mdwn @@ -0,0 +1,74 @@ +On [[todo/auto-create_tag_pages_according_to_a_template]], [[chrysn]] +suggests: + +> Instead of creating a file that gets checked in into the RCS, the +> source files could be left out and the output files be written as +> long as there is no physical source file (think of a virtual underlay). +> Something similar would be required to implement alias directive, +> which couldn't be easily done by writing to the RCS as the page's +> contents can change depending on which other pages claim it as an alias. + +`add_autofile` could be adapted to do this, or a similar API could be +added. + +This would also be useful for autoindex, as suggested on +[[plugins/autoindex/discussion]]. I'd also like to use it for +[[plugins/contrib/album]]. + +One refinement I'd suggest is that if the transient page is edited, +its transient contents are evaluated and used as the initial +content for the edit box; after that, it'd become a static page. --[[smcv]] + +-------------------------- + +[[!template id=gitbranch branch=smcv/transient author="[[smcv]]"]] +[[!tag patch]] + +I had a look at implementing this. It turns out to be harder than I thought +to have purely in-memory pages (several plugins want to be able to access the +source file as a file), but I did get this proof-of-concept branch +to write tag and autoindex pages into an underlay. + +This loses the ability to delete the auto-created pages (although they don't +clutter up git this way, at least), and a lot of the code in autoindex is +probably now redundant, so this is probably not quite ready for merge, but +I'd welcome opinions. + +Usage: set `tag_underlay` and/or `autoindex_underlay` to an absolute path, +which you must create beforehand. I suggest *srcdir* + `/.ikiwiki/transient`. + +Refinements that could be made if this approach seems reasonable: + +* make these options boolean, and have the path always be `.ikiwiki/transient` +* improve the `remove` plugin so it also deletes from this special underlay + +>> Perhaps it should be something more generic, so that other plugins could use it (such as "album" mentioned above). +>> The `.ikiwiki/transient` would suit this, but instead of saying "tag_underlay" or "autoindex_underlay" have "use_transient_underlay" or something like that? +>> Or to make it more flexible, have just one option "transient_underlay" which is set to an absolute path, and if it is set, then one is using a transient-underlay. +>> --[[KathrynAndersen]] + +>>> What I had in mind was more like `tag_autocreate_transient => 1` or +>>> `autoindex_transient => 1`; you might conceivably want tags to be +>>> checked in but autoindices to be transient, and it's fine for each +>>> plugin to make its own decision. Going from that to one boolean +>>> (or just always-transient if people don't think that's too +>>> astonishing) would be trivial, though. +>>> +>>> I don't think relocating the transient underlay really makes sense, +>>> except for prototyping: you only want one, and `.ikiwiki` is as good +>>> a place as any (ikiwiki already needs to be able to write there). +>>> +>>> For [[plugins/contrib/album]] I think I'd just make the photo viewer +>>> pages always-transient - you can always make a transient page +>>> permanent by editing it, after all. +>>> +>>> Do you think this approach has enough potential that I should +>>> continue to hack on it? Any thoughts on the implementation? --[[smcv]] + +>>>> Ah, now I understand what you're getting at. Yes, it makes sense to put transient pages under `.ikiwiki`. +>>>> I haven't looked at the code, but I'd be interested in seeing whether it's generic enough to be used by other plugins (such as `album`) without too much fuss. +>>>> The idea of a transient underlay gives us a desirable feature for free: that if someone edits the transient page, it is made permanent and added to the repository. +>>>> +>>>> I think the tricky thing with removing these transient underlay pages is the question of how to prevent whatever auto-generated the pages in the first place from generating them again - or, conversely, how to force whatever auto-generated those pages to regenerate them if you've changed your mind. +>>>> I think you'd need something similar to `will_render` so that transient pages would be automatically removed if whatever auto-generated them is no longer around. +>>>> -- [[KathrynAndersen]] diff --git a/doc/todo/use_secure_cookies_for_ssl_logins.mdwn b/doc/todo/use_secure_cookies_for_ssl_logins.mdwn new file mode 100644 index 000000000..a91a15b98 --- /dev/null +++ b/doc/todo/use_secure_cookies_for_ssl_logins.mdwn @@ -0,0 +1,12 @@ +[[!template id=gitbranch branch=smcv/ready/sslcookie-auto author="[[smcv]]"]] +[[!tag patch]] + +At the moment `sslcookie => 0` never creates secure cookies, so if you log in +with SSL, your browser will send the session cookie even over plain HTTP. +Meanwhile `sslcookie => 1` always creates secure cookies, so you can't +usefully log in over plain http. + +This branch adds `sslcookie => 0, sslcookie_auto => 1` as an option; this +uses the `HTTPS` environment variable, so if you log in over SSL you'll +get a secure session cookie, but if you log in over HTTP, you won't. +(The syntax for the setup file is pretty rubbish - any other suggestions?) diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn index 20d22b9ab..264eb9688 100644 --- a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn +++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn @@ -165,14 +165,17 @@ whether `url` and `cgiurl` are on the same server with the the same URL scheme. In theory you could use things like `//static.example.com/wiki/` and `//dynamic.example.com/ikiwiki.cgi` to preserve choice of http/https while switching server, but I don't know how consistently browsers -suppot that. +support that. "local" here is short for "locally valid", because these URLs are neither fully relative nor fully absolute, and there doesn't seem to be a good name for them... -I've tested this on a demo website with the CGI enabled, and it seems to +I've tested this on a demo website with the CGI enabled, and it seemed to work nicely (there might be bugs in some plugins, I didn't try all of them). +The branch at [[todo/use secure cookies for SSL logins]] goes well with +this one. + The `$config{url}` and `$config{cgiurl}` are both HTTP, but if I enable `httpauth`, set `cgiauthurl` to a HTTPS version of the same site and log in via that, links all end up in the HTTPS version. @@ -181,15 +184,93 @@ New API added by this branch: * `urlto(x, y, 'local')` uses `$local_url` instead of `$config{url}` + > Yikes. I see why you wanted to keep it to 3 parameters (4 is too many, + > and po overrides it), but I dislike overloading the third parameter + > like that. + > + > There are fairly few calls to `urlto($foo, $bar)`, so why not + > make that always return the semi-local url form, and leave the third + > parameter for the cases that need a true fully-qualified url. + > The new form for local urls will typically be only a little bit longer, + > except in the unusual case where the cgiurl is elsewhere. --[[Joey]] + + >> So, have urlto(x, y) use `$local_url`? There are few calls, but IMO + >> they're for the most important things - wikilinks, img, map and + >> other ordinary hyperlinks. Using `$local_url` would be fine for + >> webserver-based use, but it does stop you browsing your wiki's + >> HTML over `file:///` (unless you set that as the base URL, but + >> then you can't move it around), and stops you moving simple + >> outputs (like the docwiki!) around. + >> + >> I personally think breaking the docwiki is enough to block that. + >> + >>> Well, the docwiki doesn't have an url configured at all, so I assumed + >>> it would need to fall back to current behavior in that case. I had + >>> not thought about browsing wiki's html files though, good point. + >> + >> How about this? + >> + >> * `urlto($link, $page)` with `$page` defined: relative + >> * `urlto($link, undef)`: local, starts with `/` + >> * `urlto($link)`: also local, as a side-effect + >> * `urlto($link, $anything, 1)` (but idiomatically, `$anything` is + >> normally undef): absolute, starts with `http[s]://` + >> + >> --[[smcv]] + >> + >>> That makes a great deal of sense, bravo for actually removing + >>> parameters in the common case while maintaining backwards + >>> compatability! --[[Joey]] + >>> + >>>> Done in my `localurl` branch; not tested in a whole-wiki way + >>>> yet, but I did add a regression test. I've used + >>>> `urlto(x, undef)` rather than `urlto(x)` so far, but I could + >>>> go back through the codebase using the short form if you'd + >>>> prefer. --[[smcv]] + >>> + >>> It does highlight that it would be better to have a + >>> `absolute_urlto($link)` (or maybe `absolute(urlto($link))` ) + >>> rather than the 3 parameter form. --[[Joey]] + >>> + >>> Possibly. I haven't added this. + * `IkiWiki::baseurl` has a new second argument which works like the third argument of `urlto` + > I assume you have no objection to this --[[smcv]] + + >> It's so little used that I don't really care if it's a bit ugly. + >> (But I assume changes to `urlto` will follow through here anyway.) + >> --[[Joey]] + + >>> I had to use it a bit more, as a replacement for `$config{url}` + >>> when doing things like referencing stylesheets or redirecting to + >>> the top of the wiki. + >>> + >>> I ended up redoing this without the extra parameter. Previously, + >>> `baseurl(undef)` was the absolute URL; now, `baseurl(undef)` is + >>> the local path. I know you objected to me using `baseurl()` in + >>> an earlier branch, because `baseurl().$x` looks confusingly + >>> similar to `baseurl($x)` but has totally different semantics; + >>> I've generally written it `baseurl(undef)` now, to be more + >>> explicit. --[[smcv]] + * `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1` + > Now changed to always use the `$local_cgiurl`. --[[smcv]] + * `IkiWiki::cgiurl` omits the trailing `?` if given no named parameters except `cgiurl` and/or `local_cgiurl` -Bugs: + > I assume you have no objection to this --[[smcv]] + > + >> Nod, although I don't know of a use case. --[[Joey]] + + >>> The use-case is that I can replace `$config{cgiurl}` with + >>> `IkiWiki::cgiurl()` for things like the action attribute of + >>> forms. --[[smcv]] + +Fixed bugs: * I don't think anything except `openid` calls `cgiurl` without also passing in `local_cgiurl => 1`, so perhaps that should be the default; @@ -199,9 +280,29 @@ Bugs: `cgiurl(cgiurl => $config{cgiurl}, ...)`, although that does look a bit strange + > I agree that makes sense. --[[Joey]] + + >> I'm not completely sure whether you're agreeing with "perhaps do this" + >> or "that looks too strange", so please disambiguate: + >> would you accept a patch that makes `cgiurl` default to a local + >> (starts-with-`/`) result? If you would, that'd reduce the diff. --[[smcv]] + + >>> Yes, I absolutely think it should default to local. (Note that + >>> if `absolute()` were implemented as suggested above, it could also + >>> be used with cgiurl if necessary.) --[[Joey]] + + >>>> Done (minus `absolute()`). --[[smcv]] + +Potential future things: + * It occurs to me that `IkiWiki::cgiurl` could probably benefit from being exported? Perhaps also `IkiWiki::baseurl`? + > Possibly, see [[firm_up_plugin_interface]]. --[[Joey]] + + >> Not really part of this branch, though, so wontfix (unless you ask me + >> to do so). --[[smcv]] + * Or, to reduce use of the unexported `baseurl` function, it might make sense to give `urlto` a special case that references the root of the wiki, with a trailing slash ready to append stuff: perhaps `urlto('/')`, @@ -210,3 +311,11 @@ Bugs: do_something(baseurl => urlto('/', undef, local)`); do_something_else(urlto('/').'style.css'); IkiWiki::redirect(urlto('/', undef, 1)); + + > AFACIS, `baseurl` is only called in 3 places so I don't think that's + > needed. --[[Joey]] + + >> OK, wontfix. For what it's worth, my branch has 6 uses in IkiWiki + >> core code (IkiWiki, CGI, Render and the pseudo-core part of editpage) + >> and 5 in plugins, since I used it for things like redirection back + >> to the top of the wiki --[[smcv]] diff --git a/doc/users/dark.mdwn b/doc/users/dark.mdwn new file mode 100644 index 000000000..e1d06d0b0 --- /dev/null +++ b/doc/users/dark.mdwn @@ -0,0 +1,3 @@ +[[!meta title="Richard Braakman"]] + +Lars Wirzenius convinced me to try ikiwiki for blogging :) diff --git a/doc/users/harishcm.mdwn b/doc/users/harishcm.mdwn index 164711022..292a3bfad 100644 --- a/doc/users/harishcm.mdwn +++ b/doc/users/harishcm.mdwn @@ -1 +1 @@ -Using ikiwiki for my yet to be published personal website :) +Using ikiwiki for my personal website <http://harish.19thsc.com> diff --git a/doc/users/tschwinge.mdwn b/doc/users/tschwinge.mdwn index 944105349..435208a71 100644 --- a/doc/users/tschwinge.mdwn +++ b/doc/users/tschwinge.mdwn @@ -1,8 +1,8 @@ [[!meta title="Thomas Schwinge"]] # Thomas Schwinge -<tschwinge@gnu.org> -<http://www.thomas.schwinge.homeip.net/> +<thomas@schwinge.name> +<http://schwinge.homeip.net/~thomas/> I have converted the [GNU Hurd](http://www.gnu.org/software/hurd/)'s previous web pages and previous wiki pages to a *[[ikiwiki]]* system; and all that while |