diff options
| author | Joey Hess <joey@gnu.kitenet.net> | 2009-07-19 12:36:01 +0200 |
|---|---|---|
| committer | Joey Hess <joey@gnu.kitenet.net> | 2009-07-19 12:36:01 +0200 |
| commit | ec965fc92cd41f597c6e8e88584b9a688407c8c6 (patch) | |
| tree | 410173c14f66ae62a6436ea00b73bb470c9d1dda /doc | |
| parent | 86edd73d169600875a10a635ef8df4a644545b0d (diff) | |
| parent | fa2c3a3dba2a4589b63cf445ec9e33ec19be627e (diff) | |
Merge branch 'master' into po
Conflicts:
debian/changelog
Diffstat (limited to 'doc')
72 files changed, 1330 insertions, 110 deletions
diff --git a/doc/bugs/CGI_problem_with_some_webservers.mdwn b/doc/bugs/CGI_problem_with_some_webservers.mdwn index a40a454c1..e4b0fd448 100644 --- a/doc/bugs/CGI_problem_with_some_webservers.mdwn +++ b/doc/bugs/CGI_problem_with_some_webservers.mdwn @@ -67,3 +67,42 @@ Why do they appear two times with conflicting values in the very same hashes? >>>> (reported as [[!debbug 437927]] and [[!debbug 437932]]) --[[JeremieKoenig]] Marking [[done]] since it's not really an ikiwiki bug. --[[Joey]] + +---- + +I'm using boa and getting some odd behaviour if I don't set the `umask` +option in the config file. Editing a page through the web interface and +hitting "Save Page" regenerates the `index.html` file with no world-read +permissions. As a result, the server serves a "403 - Forbidden" error page +instead of the page I was expecting to return to. + +There are only two ways I found to work around this: adding a `umask 022` +option to the config file, or re-compiling the wiki from the command line +using `ikiwiki --setup`. Setting up a git back-end and re-running `ikiwiki +--setup` from inside a hook had no effect; it needed to be at the terminal. +--Paul + +> Since others seem to have gotten ikiwiki working with boa, +> I'm guessing that this is not a generic problem with boa, but that +> your boa was started from a shell that had an unusual umask and inherited +> that. --[[Joey]] + +>> That's right; once I'd worked out what was wrong, it was clear that any +>> webserver should have been refusing to serve the page. I agree about the +>> inherited umask; I hadn't expected that. Even if it's unusual, though, it +>> probably won't be uncommon - this was a stock Ubuntu 9.04 install. --Paul + +(I'm new to wiki etiquette - would it be more polite to leave these details +on the wiki, or to remove them and only leave a short summary? Thanks. +--Paul) + +> Well, I just try to keep things understandable and clear, whether than +> means deleting bad old data or not. That said, this page is a bug report, +> that was already closed. It's generally better to open a new bug report +> rather than edit an old closed one. --[[Joey]] + +>> Thanks for the feedback, I've tidied up my comment accordingly. I see +>> your point about the bug; sorry for cluttering the page up. I doubt it's +>> worth opening a new page at this stage, but will do so if there's a next +>> time. The solution seems worth leaving, though, in case anyone else in my +>> situation picks it up. --Paul diff --git a/doc/bugs/Filenames_with_colons_cause_problems_for_Windows_users.mdwn b/doc/bugs/Filenames_with_colons_cause_problems_for_Windows_users.mdwn index 0fccd1dcb..7559e6d0a 100644 --- a/doc/bugs/Filenames_with_colons_cause_problems_for_Windows_users.mdwn +++ b/doc/bugs/Filenames_with_colons_cause_problems_for_Windows_users.mdwn @@ -68,3 +68,8 @@ Windows does not support filenames containing any of these characters: `/ \ * : >>> ikiwiki on windows, including its assumption that the directory >>> separator is "/". Windows will be supported when someone sends me a >>> comprehansive and not ugly or performance impacting patch. :-) --[[Joey]] + +> Speaking of Windows filename problems, how do I keep directories ending in a +> period from being created? The following didn't seem to work. +> `wiki_file_chars => "-[:alnum:]+/._",` +> `wiki_file_regex => '[-[:alnum:]+_]$',` diff --git a/doc/bugs/Renaming_a_file_via_the_web_is_failing_when_using_subversion.mdwn b/doc/bugs/Renaming_a_file_via_the_web_is_failing_when_using_subversion.mdwn new file mode 100644 index 000000000..1a737df0a --- /dev/null +++ b/doc/bugs/Renaming_a_file_via_the_web_is_failing_when_using_subversion.mdwn @@ -0,0 +1,28 @@ +I'm using ikiwiki 3.12 on Mac OS X (installed via mac ports) + +When trying to rename a file via the web interface (using the rename plugin) I get the following error: + +Error: Undefined subroutine &IkiWiki::Plugin::svn::dirname called at /opt/local/lib/perl5/vendor_perl/5.8.9/IkiWiki/Plugin/svn.pm line 246. + +Applying the following patch fixed it: + + --- IkiWiki/Plugin/svn.pm.orig 2009-07-08 12:25:23.000000000 -0400 + +++ IkiWiki/Plugin/svn.pm 2009-07-08 12:28:36.000000000 -0400 + @@ -243,10 +243,10 @@ + + if (-d "$config{srcdir}/.svn") { + # Add parent directory for $dest + - my $parent=dirname($dest); + + my $parent=IkiWiki::dirname($dest); + if (! -d "$config{srcdir}/$parent/.svn") { + while (! -d "$config{srcdir}/$parent/.svn") { + - $parent=dirname($dest); + + $parent=Ikiwiki::dirname($dest); + } + if (system("svn", "add", "--quiet", "$config{srcdir}/$parent") != 0) { + warn("svn add $parent failed\n"); + + +> Thank you very much for the patch, which I've applied. I wonder how +> that snuck in (aside from the obvious, that the svn plugin is not often +> used and the code was added w/o being tested..). [[done]] --[[Joey]] diff --git a/doc/bugs/img_with_alt_has_extra_double_quote.mdwn b/doc/bugs/img_with_alt_has_extra_double_quote.mdwn new file mode 100644 index 000000000..81bbe7fb5 --- /dev/null +++ b/doc/bugs/img_with_alt_has_extra_double_quote.mdwn @@ -0,0 +1,32 @@ +The [[ikiwiki/directive/img]] directive emits an extra double quote if alt=x is +specified (as is necessary for valid HTML). This results in malformed HTML, +like this: + + <img src="U" width="W" height="H"" alt="A" /> + ^ + +This [[patch]] is available from the img-bugfix branch in my git repository: + + commit a648c439f3467571374daf597e9b3a659ea2008f + Author: Simon McVittie <smcv@ http://smcv.pseudorandom.co.uk/> + Date: 2009-06-16 17:15:06 +0100 + + img plugin: do not emit a redundant double-quote before alt attribute + + diff --git a/IkiWiki/Plugin/img.pm b/IkiWiki/Plugin/img.pm + index a697fea..a186abd 100644 + --- a/IkiWiki/Plugin/img.pm + +++ b/IkiWiki/Plugin/img.pm + @@ -121,7 +121,7 @@ sub preprocess (@) { + my $imgtag='<img src="'.$imgurl. + '" width="'.$im->Get("width"). + '" height="'.$im->Get("height").'"'. + - (exists $params{alt} ? '" alt="'.$params{alt}.'"' : ''). + + (exists $params{alt} ? ' alt="'.$params{alt}.'"' : ''). + (exists $params{title} ? ' title="'.$params{title}.'"' : ''). + (exists $params{class} ? ' class="'.$params{class}.'"' : ''). + (exists $params{id} ? ' id="'.$params{id}.'"' : ''). + +--[[smcv]] + +[[done]] --[[Joey]] diff --git a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn new file mode 100644 index 000000000..ceedbbdaa --- /dev/null +++ b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn @@ -0,0 +1,49 @@ +[[!tag plugins/map patch]] + +input: + + before. + \[[!map pages="sdfsdfsdfsd/*"]] + after. + +Presuming that the pagespec does not match, output: + + <p>before. + <div class="map"> + <ul> + </div></p> + +The UL element is not closed. + +Patch: + + --- /usr/share/perl5/IkiWiki/Plugin/map.pm 2009-05-06 00:56:55.000000000 +0100 + +++ IkiWiki/Plugin/map.pm 2009-06-15 12:23:54.000000000 +0100 + @@ -137,11 +137,11 @@ + $openli=1; + $parent=$item; + } + - while ($indent > 0) { + + while ($indent > 1) { + $indent--; + $map .= "</li>\n</ul>\n"; + } + - $map .= "</div>\n"; + + $map .= "</ul>\n</div>\n"; + return $map; + } + + +-- [[Jon]] + +> Strictly speaking, a `<ul>` with no `<li>`s isn't valid HTML either... +> could `map` instead delay emitting the first `<ul>` until it determines that +> it will have at least one item? Perhaps refactoring that function into +> something easier to regression-test would be useful. --[[smcv]] + +>> You are right (just checked 4.01 DTD to confirm). I suspect refactoring +>> the function would be wise. From my brief look at it to formulate the +>> above I thought it was a bit icky. I'm not a good judge of what would +>> be regression-test friendly but I might have a go at reworking it. With +>> this variety of problem I have a strong inclination to use HOFs like map, +>> grep. - [[Jon]] diff --git a/doc/bugs/nested_raw_included_inlines.mdwn b/doc/bugs/nested_raw_included_inlines.mdwn new file mode 100644 index 000000000..33433e235 --- /dev/null +++ b/doc/bugs/nested_raw_included_inlines.mdwn @@ -0,0 +1,34 @@ +I have the following structure: + +## page0 + # Page 0 + \[[!inline raw="yes" pages="page1"]] + +## page1 + # Page 1 + \[[!inline pages="page2"]] + +## page2 + # Page 2 + test + +In this situation, a change in page 2 will trigger a rebuild of page1 but not of page0. + + refreshing wiki.. + scanning page2.mdwn + rendering page2.mdwn + rendering page1.mdwn, which depends on page2 + done + +In my real world situation, page1 is actually listing all pages that match a certain tag and page0 is the home page. +Whenever a page got tagged, it will appear on page1 but not on page0. + +Am I missing something? Is this a bug or Ikiwiki not supposed to support this use case? + +> Perhaps the inline plugin isn't being clever enough about dependencies - +> strictly speaking, when a page is inlined with full content, the inlining +> page should probably inherit all the inlined page's dependencies. +> That might be prohibitively slow in practise due to the way IkiWiki +> currently merges pagespecs, though - maybe the patches I suggested for +> [[separating_and_uniquifying_pagespecs|todo/should_optimise_pagespecs]] +> would help? --[[smcv]] diff --git a/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn b/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn new file mode 100644 index 000000000..85a206bc0 --- /dev/null +++ b/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn @@ -0,0 +1,17 @@ +The git commit (in my `openid` branch) says it all: + + Update IkiWiki::openiduser to work with Net::OpenID 2.x + + openiduser previously used a constructor that no longer works in 2.x. + However, all we actually want is the (undocumented) DisplayOfURL function + that is invoked by the display method, so try to use that. + +This bug affects ikiwiki.info (my commits show up in [[RecentChanges]] as http://smcv.pseudorandom.co.uk/ rather than smcv [pseudorandom.co.uk]). + +> Cherry picked, thanks. --[[Joey]] + +Relatedly, the other commit on the same branch would be nice to have +(edited to add: I've now moved it, and its discussion, to +[[todo/pretty-print_OpenIDs_even_if_not_enabled]]). --[[smcv]] + +[[!tag done]] diff --git a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn index 042d6a20c..be14e5126 100644 --- a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn +++ b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn @@ -1,3 +1,5 @@ +[[!tag patch plugins/inline patch/core]] + The `IkiWiki::pagetitle` function does not respect title changes via `meta.title`. It really should, so that links rendered with `htmllink` get the proper title in the link text. --[[madduck]] @@ -5,7 +7,7 @@ The `IkiWiki::pagetitle` function does not respect title changes via `meta.title ---- It is possible to set a Page-Title in the meta-plugin, but that one isn't -reused in parentlinks. This [[patch]] may fix it. +reused in parentlinks. This patch may fix it. <ul> <li> I give pagetitle the full path to a page. @@ -132,7 +134,7 @@ diff -c /usr/share/perl5/IkiWiki/Plugin/meta.pm.distrib /usr/share/perl5/IkiWiki > >> It was actually more complicated than expected. A working prototype is >> now in my `meta` branch, see my userpage for the up-to-date url. ->> Thus tagging [[patch]]. --[[intrigeri]] +>> Thus tagging patch. --[[intrigeri]] >> >>> Joey, please consider merging my `meta` branch. --[[intrigeri]] diff --git a/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn b/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn new file mode 100644 index 000000000..430d65a3f --- /dev/null +++ b/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn @@ -0,0 +1,32 @@ +Prettydate creates strings like this: _Last edited in the wee hours of Tuesday night, July 1st, 2009_. However, July 1st is a Wednesday, so either date or Weekday should be modified. In the spirit is probably _Tuesday night, June 30th_. --ulrik + +> The default prettydate times are fairly idiosyncratic to +> how [[Joey]] thinks about time. Specifically, it's still +> Tuesday night until he wakes up Wednesday morning -- which +> could be in the afternoon. :-P But, Joey also realizes +> that dates change despite his weird time sense, and so +> July 1st starts at midnight on Tuesday and continues +> through Tuesday night and part of Wednesday. +> +> (This might not be as idiosyncratic as I make it out to be.. +> I think that many people would agree that in the wee hours +> of New Years Eve, when they're staggering home ahead of +> the burning daylight, the date is already January 1st.) +> +> I think the bug here is that prettydate can't represent +> all views of time. While the times +> of day can be configured, and it's possible to configure it +> to call times after midnight "Wednesday morning, July 1st", +> it is not possible to configure the date or weekday based +> on the time of day. +> +> In order to do so, prettydate's timetable would need to be +> extended to include the "%B %o, %Y" part, and that extended +> to include "%B-", "%o-", and "%Y-" to refer to the day +> before. +> +> --[[Joey]] + +>> fair enough, I think I can get converted to a warped time perspective. --ulrik + +>>> Perhaps we can consider this [[done]], then? --[[smcv]] diff --git a/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn b/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn index dace2ca19..08af5fe2c 100644 --- a/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn +++ b/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn @@ -11,7 +11,7 @@ It seems like gettext only searches for locale information in /usr/share/locale, return $gettext_obj->get(shift); } -[[!tag patch]] +[[!tag patch patch/core]] -- [[ThomasBleher]] > According to my testing, this patch makes ikiwiki's localisation fail for diff --git a/doc/bugs/support_for_openid2_logins.mdwn b/doc/bugs/support_for_openid2_logins.mdwn index 1d99370f6..139a53760 100644 --- a/doc/bugs/support_for_openid2_logins.mdwn +++ b/doc/bugs/support_for_openid2_logins.mdwn @@ -15,3 +15,8 @@ However both Perl OpenID 2.x implementations have not been released and are inco > an OpenID 2 implementation (it's the second of the projects > above). I've filed a bug in Debian asking for the package to be > updated. --[[smcv]] + +> Net::OpenID::Consumer 1.x is now in Debian unstable --[[dom]] + +> I've tested with yahoo, and it works with the updated module. Sweet and +> [[done]] --[[Joey]] diff --git a/doc/download.mdwn b/doc/download.mdwn index 448bdeeb9..015c87f1b 100644 --- a/doc/download.mdwn +++ b/doc/download.mdwn @@ -21,7 +21,7 @@ There is a backport of a recent version of ikiwiki for Debian 4.0 at Fedora versions 8 and newer have RPMs of ikiwiki available. -There is also an unofficial backport of ikiwiki for Ubuntu Intrepid, provided by +There is also an unofficial backport of ikiwiki for Ubuntu Jaunty, provided by [[Paweł_Tęcza|users/ptecza]], at [http://gpa.net.icm.edu.pl/ubuntu/](http://gpa.net.icm.edu.pl/ubuntu/index-en.html). diff --git a/doc/forum/Accessing_meta_values_in_pages__63__.mdwn b/doc/forum/Accessing_meta_values_in_pages__63__.mdwn new file mode 100644 index 000000000..78594f912 --- /dev/null +++ b/doc/forum/Accessing_meta_values_in_pages__63__.mdwn @@ -0,0 +1,8 @@ +If I set a meta value on a page (lets say \[[!meta author="Adam Shand"]] is there some way to retrieve the value of author and put it somewhere visible on the page? Eg. can I write: + +author: $author + +I know I can update the raw templates but it'd be nice to be able to do this in the pages them selves. + +Cheers, +Adam. diff --git a/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn b/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn new file mode 100644 index 000000000..7599e71e5 --- /dev/null +++ b/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn @@ -0,0 +1,69 @@ +I've just finished an upgrade to 3.141 and am trying to give myself admin rights to play with the new webadmin features. My login is via OpenID but from reading on the wiki I believe that OpenID users should be able to be granted admin rights. However I'm obviously doing something wrong as when I click on the "Preferences" link at the top of the page I don't see any admin features. + +My login is: http://adam.shand.net/ + +In .ikiwiki/userdb I see: + +> adam@shand.net +> email <br> +> password <br> +> locked_pages <br> +> banned <br> +> 1229722296 <br> +> regdate <br> +> http://adam.shand.net/ <br> + +And in my config file I have: + +> adminuser => [qw{http://adam.shand.net/}], + +Any pointers to what I'm doing wrong would be much appreciated. + +Thanks, +Adam. + +> This is certianly supposed to work. For example, the admin +> user on my ikiwikis is `http://joey.kitenet.net/` +> +> The only caveat I know of to make it work is that the +> adminuser openid url has to exactly match the openid url that +> ikiwiki sees when you log in. Including any trailing slash, +> and the `http://`. --[[Joey]] + +>> Hrm, it's not working. I'm sure I've made a silly mistake somewhere but +>> I've looked and looked and just can't find it. Any suggestions on where +>> to look for debugging information would be much appreciated. -- [[Adam]] + +>>> Well, you could use this patch to add debugging info about admin +>>> username comparisons: + +<pre> +diff --git a/IkiWiki/UserInfo.pm b/IkiWiki/UserInfo.pm +index 0bf100a..77b467a 100644 +--- a/IkiWiki/UserInfo.pm ++++ b/IkiWiki/UserInfo.pm +@@ -71,6 +71,8 @@ sub userinfo_setall ($$) { + sub is_admin ($) { + my $user_name=shift; + ++ print STDERR "is_admin test @{$config{adminuser}} vs $user_name: ".(grep { $_ eq $user_name } @{$config{adminuser}})."\n"; ++ + return grep { $_ eq $user_name } @{$config{adminuser}}; + } + +</pre> + +>>>> After applying that change to what is probably +>>>> `/usr/share/perl5/IkiWiki/UserInfo.pm` on your system, +>>>> when you go to the preferences page it should log in your web server's +>>>> error.log, something like this: + + [Wed Jul 08 12:54:35 2009] [error] [client 127.0.1.1] is_admin test http://joey.kitenet.net/ vs http://joey.kitenet.net/: 1 + +>>>> So you can see if the two usernames/openids match. If the end is "0", +>>>> they don't match. If nothing is logged, you have not enabled the websetup plugin. +>>>> If the end if "1" you should see the "Wiki Setup" button, if not the +>>>> problem is not in determining if you're an admin, but elsewhere.. +>>>> --[[Joey]] + +I was being incredibly stupid and missed that websetup is a **plugin** and thus needed to be enabled. Many thanks for your patient assistance, by helping me eliminate the unlikely it eventually led me to the obvious. Cheers. -- [[Adam]] diff --git a/doc/forum/is_it_possible_to_NOT_add_openid2_meta_tags.mdwn b/doc/forum/is_it_possible_to_NOT_add_openid2_meta_tags.mdwn new file mode 100644 index 000000000..e952263a3 --- /dev/null +++ b/doc/forum/is_it_possible_to_NOT_add_openid2_meta_tags.mdwn @@ -0,0 +1,67 @@ +### "meta openid" problems + +I have add the followning to _index.mdwn_ on my site. + + \[[!meta openid="http://certifi.ca/lunix" + server="http://certifi.ca/_serve"]] + +This resulted in the following being added to my site + + <link href="http://certifi.ca/_serve" rel="openid.server" /> + <link href="http://certifi.ca/_serve" rel="openid2.provider" /> + <link href="http://certifi.ca/lunix" rel="openid.delegate" /> + <link href="http://certifi.ca/lunix" rel="openid2.local_id" /> --> + +Perhaps I have done something wrong but this fails to work when I try to log in to several sites using my sites url as my login. +If I edit index.html and remove the two openid2 lines all works fine. +**Is there a way to only add openid version 1 tags to my index.html ? +Or a way to make it work the way it is ?** --[Mick](http://www.lunix.com.au) + +> Before I think about adding a way to not add the openid 2 tags, +> I'd like to know what the problem is. Is there something +> wrong with the tags? Does your openid provider not support +> openid 2, and the site you are logging into sees the openid 2 tags +> and uses it, not falling back to openid 1? +> +> Since certifi.ca is a public openid provider (run by a +> guy I know even!), I should be +> able to reproduce your problem if you can tell me what +> site(s) you are trying to log into. --[[Joey]] + +---------- + +I was using _phpMyID_ and its not _openid2_ compliant so I switched to certifi.ca to counteract that but I really +want to go back to running my own provider. +I can't login to identi.ca.unless I comment out the openid2 lines.(this may be there problem, I get sent to certifi.ca's site and redirected back to identi.ca) +I will test all the different openid enabled sites I log into today and see what happens. +It seems that since I have moved my site to its final location and made it live over night I am able to login to most places now. +I do not have a proper understanding of the inner workings of openid so not exactly sure what part is failing but I think the problem +lays with the consumers not falling back to the openid1 tags when they are openid1 only consumers. --[Mick](http://www.lunix.com.au) + +> So, just to clarify, certifi.ca works ok (I verified this, logging into identi.ca using it). +> You had the problem running your own openid provider which did not support 2.0, in which case, +> consumers seem justified in not falling back (guess; I don't know the 2.0 spec). +> The only way this seems fixable is to add an option to meta to allow disabling openid 2. Which +> should be easy enough to do. --[[Joey]] + +I can't log into identi.ca with openid2 tags. strange. I will look at that again today. +Having the option to disable openid2 tags would be perfect. +Thanks Joey. --[Mick](http://www.lunix.com.au) + +>> Actually, it seems that identi.ca / certifi.ca do +>> not interoperate when using openid2. It actually +>> fails half the time, and succeeds half the time; +>> seems to be picking openid1 and openid2 randomly and failing +>> on the latter. I have emailed Evan Prodromou about this weird behavior. +>> Not clear to me if identi.ca or certifi.ca is at fault, +>> but luckily he runs both.. +>> --[[Joey]] + +Ahh so it's not just me. +It's handy having contacts in the _right_ places. --[Mick](http://www.lunix.com.au) + +>> ikiwiki's next release will allow adding 'delegate=1' to the +>> meta directive to only delegate to openid1. --[[Joey]] + +## awesome. +--[Mick](http://www.lunix.com.au) diff --git a/doc/forum/speeding_up_ikiwiki.mdwn b/doc/forum/speeding_up_ikiwiki.mdwn new file mode 100644 index 000000000..0b2164238 --- /dev/null +++ b/doc/forum/speeding_up_ikiwiki.mdwn @@ -0,0 +1,91 @@ +My website takes a fairly long time to render. It takes a long time to do +things like add pages, too. I'd like to try and understand what takes the +time and what I might be able to do to speed things up. + +I have 1,234 objects on my site (yikes!). 717 are items under "/log" which +I think might be the main culprit because there are some complex pagespecs +operating in that area (e.g. log/YYYY/MM/DD, YYYY/MM and YYYY for YYYY >= +2003, YYYY <= 2008 which include every page under log/ which was modified +in the corresponding YYYY or YYYY/MM or YYYY/MM/DD). There is very little +linking between the world outside of /log and that within it. + +I was interested in generating a graphical representation of ikiwiki's idea of +page inter-dependencies. I started by looking at the '%links' hash using the +following plugin: + + #!/usr/bin/perl + package IkiWiki::Plugin::deps; + + use warnings; + use strict; + use IkiWiki 3.00; + + + sub import { + hook(type => "format", id => "deps", call => \&fooble); + } + + my $hasrun = 0; + + sub fooble ($$) { + if(0 == $hasrun) { + $hasrun = 1; + open MYFILE, ">/home/jon/deps.dot"; + foreach my $key (keys %links) { + my $arrref = $links{$key}; + foreach my $page (@$arrref) { + print MYFILE "$key -> $page;\n"; + } + } + close MYFILE; + } + } + + 1 + +The resulting file was enormous: 2,734! This turns out to be because of the following code in scan() in Render.pm: + + if ($config{discussion}) {$ + # Discussion links are a special case since they're + # not in the text of the page, but on its template. + $links{$page}=[ $page."/".gettext("discussion") ]; + +Worst case (no existing discussion pages) this will double the number of link +relationships. Filtering out all of those, the output drops to 1,657. This +number is still too large to really visualize: the graphviz PNG and PDF output +engines segfault for me, the PS one works but I can't get any PS software to +render it without exploding. + +Now, the relations in the links hash are not the same thing as IkiWiki's notion of dependencies. Can anyone point me at that data structure / where I might be able to add some debugging foo to generate a graph of it? + +Once I've figured out that I might be able to optimize some pagespecs. I +understand pagespecs are essentially translated into sequential perl code. I +might gain some speed if I structure my complex pagespecs so that the tests +which have the best time complexity vs. "pages ruled out" ratio are performed +first. + +I might also be able to find some dependencies which shouldn't be there and +remove the dependency. + +In general any advice people could offer on profiling ikiwiki would be great. +I did wonder about invoking the magic profiling arguments to perl via the CGI +wrapper. + + +-- [[Jon]] + +> Dependencies go in the `%IkiWiki::depends` hash, which is not exported. It +> can also be dumped out as part of the wiki state - see [[tips/inside_dot_ikiwiki]]. +> +> It's a map from page name to increasingly complex pagespec, although +> the `optimize-depends` branch in my git repository changes that to a +> map from a page name to a *list* of pagespecs which are automatically +> or'd together for use (this at least means duplicates can be weeded out). +> +> See [[todo/should_optimise_pagespecs]] for more on that. +> +> I've been hoping to speed up IkiWiki too - making a lot of photo albums +> with my [[plugins/contrib/album]] plugin makes it pretty slow. +> +> One thing that I found was a big improvement was to use `quick=yes` on all +> my `archive=yes` [[ikiwiki/directive/inline]]s. --[[smcv]] diff --git a/doc/ikiwiki/directive/img.mdwn b/doc/ikiwiki/directive/img.mdwn index 1d1f29bea..66efd008e 100644 --- a/doc/ikiwiki/directive/img.mdwn +++ b/doc/ikiwiki/directive/img.mdwn @@ -18,9 +18,9 @@ making the image smaller than the specified size. You can also specify only the width or the height, and the other value will be calculated based on it: "200x", "x200" -You can also pass `alt`, `title`, `class` and `id` parameters. These are -passed through unchanged to the html img tag. If you include a `caption` -parameter, the caption will be displayed centered beneath the image. +You can also pass `alt`, `title`, `class`, `align` and `id` parameters. +These are passed through unchanged to the html img tag. If you include a +`caption` parameter, the caption will be displayed centered beneath the image. The `link` parameter is used to control whether the scaled down image links to the full size version. By default it does; set "link=somepage" to link diff --git a/doc/ikiwiki/directive/inline/discussion.mdwn b/doc/ikiwiki/directive/inline/discussion.mdwn index e301190bf..be0665d04 100644 --- a/doc/ikiwiki/directive/inline/discussion.mdwn +++ b/doc/ikiwiki/directive/inline/discussion.mdwn @@ -11,7 +11,7 @@ take it as far as implementing "replies" to other comments. -- Marcelo -> See [[todo/discussion_page_as_blog]] for some of my own thoughts on this +> See [[plugins/comments]] > --[[Joey]] --- @@ -30,3 +30,97 @@ Is there a simple way to exclude images, stylesheets, and other > The [[plugins/filecheck]] plugin adds a 'ispage()' pagespec test that can do that. > --[[Joey]] + +--- + +## Documentation for parameter `template`? + +I would be especially interested in a list of variables which can be used in such a template. + +> I try to keep ikiwiki's templates self-documenting, so if you take +> a look at a template used by inline, such as the default `/usr/share/ikiwiki/template/inlinepage.tmpl`, +> you can see all or nearly all the template variables in use in it. + +I have a page template with some structured information as parameters. For +example `location="nowhere"` and `price="20"`. Is there a possibility to +extract those information, i. e. access the parameters, to compose the item +for the inline directive from these information? For example the line »Go +to nowhere for 20 bugs.« is shown inlined. + +--[[PaulePanter]] + +> Let's not confuse the template directive with the templates used by inline. +> When a page is inlined, any template directives in it are first expanded, +> using the user-defined templates for that. Then, the inline directive's +> template is used to insert it into the inlining page. +> +> So no, you can't reference template directive parameters inside inline's +> template, because it's already expanded at that point. --[[Joey]] + +>> Thank you for the explanation. Can you think of another way to accomplish +>> my goals? +>> +>> Right now, I only see the option to edit the title with the +>> `[[/ikiwiki/directive/meta]]` directive and the field `title`. +>> +>> How could a solution look like? +>> +>> 1. The possibility to add custom fields to the `meta` directive. +>> 1. The possibility to specify in a page, how the page should be displayed +>> when used by inlined. That could be done by a new directive `cinlined` +>> (for »custom inlined«) which is chosen by the `inline` directive to +>> display if told to do so. +>> +>> [[!cinlined text="""Text which can also use Parameter, bla blubb …"""]] +>> --[[PaulePanter]] +>>> You can make the body of a page change depending on whether it's being +>>> inlined, with the [[ikiwiki/directive/if]] directive from the +>>> [[plugins/conditional]] plugin: +>>> +>>> \[[!if test="inlined()" +>>> then="""[[!template id=productsummary +>>> location="Warehouse 23" price=20 +>>> ]]""" +>>> else="""[[!template id=productdetail +>>> location="Warehouse 23" price=20 +>>> description="Every home should have one" +>>> ]]""" +>>> ]] +>>> +>>> Perhaps that does some of what you want? +>>> +>>> If you want to go beyond that, my inclination would be to write +>>> a simple plugin to deal with whatever it is you want to do (bug +>>> metadata or product metadata or whatever) rather than prematurely +>>> generalizing. --[[smcv]] + +## meta parameters are not enough + +I think I have the same problem as Paule, as I want extra arbitary parameters in my template. + +This is what I am doing currently, which makes my skin crawl. In `wgts/foo.mdwn` +I have resorted to using AUTHORURL as the location of this widgets icon: + + [[!meta authorurl="/ico/aHR0cDovL2JvbmRpLm9tdHAub3JnL3dpZGdldHMvYmF0dGVyeQ==.png" ]] + +In templates I have a file called `wgtlist.tmpl`: + + <div class="widget"> + <TMPL_IF NAME="AUTHORURL"> + <img src="<TMPL_VAR AUTHORURL>" /> + </TMPL_IF> + <TMPL_IF NAME="PERMALINK"> + <a href="<TMPL_VAR PERMALINK>"><TMPL_VAR TITLE></a><br /> + <TMPL_ELSE> + <a href="<TMPL_VAR PAGEURL>"><TMPL_VAR TITLE></a><br /> + </TMPL_IF> + Posted <TMPL_VAR CTIME> + </div> + +My index page has: + + [[!inline pages="./wgts/*" show=5 feeds=no actions=no rootpage="wgts" archive="yes" template=wgtlist]] + +Else can you please suggest a smarter way of getting certain data out from pages for a inline index? + +--[[hendry]] diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn index f29a118bf..000f461c9 100644 --- a/doc/ikiwiki/directive/meta.mdwn +++ b/doc/ikiwiki/directive/meta.mdwn @@ -68,11 +68,16 @@ Supported fields: * openid Adds html <link> tags to perform OpenID delegation to an external - OpenID server (for `openid` and `openid2`). An optional `xrds-location` + OpenID server. This lets you use an ikiwiki page as your OpenID. + + By default this will delegate for both `openid` and `openid2`. To only + delegate for one, add a parameter such as `delegate=openid`. + + An optional `xrds-location` parameter lets you specify the location of any [eXtensible Resource DescriptorS](http://www.windley.com/archives/2007/05/using_xrds.shtml). - This lets you use an ikiwiki page as your OpenID. Example: + Example: \\[[!meta openid="http://joeyh.myopenid.com/" server="http://www.myopenid.com/server" diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn index fdae9c047..56f407a41 100644 --- a/doc/ikiwikiusers.mdwn +++ b/doc/ikiwikiusers.mdwn @@ -45,6 +45,7 @@ Projects & Organizations * [Cosin Homepage](http://cosin.ch) uses an Ikiwiki with a subversion repository. * [Bosco Free Orienteering Software](http://bosco.durcheinandertal.ch) * The [GNU Hurd](http://www.gnu.org/software/hurd/)'s web pages +* The [Free Software Foundation](http://fsf.org) uses it for their internal wiki, with subversion. Personal sites and blogs ======================== @@ -118,13 +119,15 @@ Personal sites and blogs * [Per Bothner's blog](http://per.bothner.com/blog/) * [Bernd Zeimetz (bzed)](http://bzed.de/) * [Gaudenz Steinlin](http://gaudenz.durcheinandertal.ch) -* [Simon Kjika'qawej C.](http://simonraven.kisikew.org/ikiwiki/) Please note it might change location at any time (likely wiki.k.o or under /wiki/ at simonraven.k.o). +* [Simon Kjika'qawej C.](http://simonraven.kisikew.org/) - several other sites, too. * [NeoCarz Wiki](http://www.neocarz.com/wiki/) Yes - its actually Ikiwiki behind that! I'm using Nginx and XSL to transform the ikiwiki renderings thanks to the valid XHTML output of ikiwiki. Great work Joey!! * [Natalian - Kai Hendry's personal blog](http://natalian.org/) +* [Mick Pollard aka \_lunix_ - Personal sysadmin blog and wiki](http://www.lunix.com.au) +* [tumashu's page](http://tumashu.github.com) This is my personal site in github created with ikiwiki and only a page,you can get the [source](http://github.com/tumashu/tumashu/tree/master) Please feel free to add your own ikiwiki site! -See also: [Debian ikiwiki popcon graph](http://popcon.debian.org/~igloo/popcon-graphs/index.php?packages=ikiwiki) +See also: [Debian ikiwiki popcon graph](http://qa.debian.org/popcon.php?package=ikiwiki) and [google search for ikiwiki powered sites](http://www.google.com/search?q=%22powered%20by%20ikiwiki%22). While nothing makes me happier than knowing that ikiwiki has happy users, dropping some change in the [[TipJar]] is a nice way to show extra appreciation. diff --git a/doc/install/discussion.mdwn b/doc/install/discussion.mdwn index c1129a435..02cdb29c9 100644 --- a/doc/install/discussion.mdwn +++ b/doc/install/discussion.mdwn @@ -228,3 +228,44 @@ For ubuntu 8.04: I was just trying to get the latest version. In any case, thanks for the help, and thanks for the superb software. I really like it a lot. + +--- + +## Prerequisite modules not found for non-root user +Hi, I'm a non-root user trying to use IkiWiki on an academic webserver with Perl 5.8.8 but several missing modules, so I grab them from CPAN (edited): + + cd ~; PERL5LIB=`pwd`/ikiwiki:`pwd`/ikiwiki/cpan:`pwd`/lib/perl5 PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'CPAN::Shell->install("Bundle::IkiWiki")' + +That puts a lot of files in ~/.cpan. Then when I go into the directory where I untarred IkiWiki and try to run the Perl makefile: + + cd ~/ikiwiki; perl Makefile.PL PREFIX=$HOME/ikiwiki + +I get warnings that all the modules needed were not found: + +Warning: prerequisite CGI::FormBuilder not found. +Warning: prerequisite CGI::Session 0 not found. +Warning: prerequisite Date::Parse 0 not found. +Warning: prerequisite HTML::Scrubber 0 not found. +Warning: prerequisite HTML::Template 0 not found. +Warning: prerequisite Mail::Sendmail 0 not found. +Warning: prerequisite Text::Markdown 0 not found. + +CORRECTION 1: I played around with CPAN and got the installation to the point of succeeding with >99% of tests in "make test". + +> What was the magic CPAN rune that worked for you? --[[Joey]] + +An attempt of "make install" failed while trying to put files in /etc/IkiWiki but per the output's instructions, I reran "make install" and that seemed to work, until this error, which doesn't seem to be satisfiable: + + Warning: You do not have permissions to install into /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi at /usr/lib/perl5/5.8.8/ExtUtils/Install.pm line 114. + Installing /usr/lib/perl5/site_perl/5.8.8/IkiWiki.pm + mkdir /usr/lib/perl5/site_perl/5.8.8/IkiWiki: Permission denied at /usr/lib/perl5/5.8.8/ExtUtils/Install.pm line 176 + +Any suggestions? Whew! + +> When you build ikiwiki, try doing it like this to make it +> install to your home directory. Then you can run `~/bin/ikiwiki` +> --[[Joey]] + + perl Makefile.PL INSTALL_BASE=$HOME PREFIX= + make + make install diff --git a/doc/news/version_3.11.mdwn b/doc/news/version_3.11.mdwn deleted file mode 100644 index 2d1dc7063..000000000 --- a/doc/news/version_3.11.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -ikiwiki 3.11 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * Avoid using python-support. Closes: #[525086](http://bugs.debian.org/525086) - * websetup: Display stderr in browser if ikiwiki setup fails. - * blogspam: Load RPC::XML library in checkconfig, so that an - error can be printed at that point if it's not available, - allowing the admin to see it during wiki setup. - Closes: #[520015](http://bugs.debian.org/520015) - * websetup: If setup fails, restore old setup file. - * relativedate: Deal with clock skew. - * Add IkiWiki::ErrorReason objects, and modify pagespecs to return - them in cases where they fail to match due to a configuration or syntax - error. - * pagespec\_match\_list: New API function, matches pages in a list - and throws an error if the pagespec is bad. - * inline, brokenlinks, calendar, linkmap, map, orphans, pagecount, - pagestate, postsparkline: Display a handy error message if the pagespec - is erronious. - * comments: Add link to comment post form to allow user to sign in - if they wish to, if the configuration makes signin optional - for commenting. - * Updated Danish translation from Jonas Smedegaard. Closes: #[525751](http://bugs.debian.org/525751) - * translation.mdwn: Typo fixes. Closes: #[525753](http://bugs.debian.org/525753)"""]] diff --git a/doc/news/version_3.12.mdwn b/doc/news/version_3.12.mdwn deleted file mode 100644 index 1e1862bb0..000000000 --- a/doc/news/version_3.12.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -You may want to run `ikiwiki-transition deduplinks my.setup` -after upgrading to this version of ikiwiki. This command will -optimise your wiki's saved state, removing duplicate information -that can slow ikiwiki down. - -ikiwiki 3.12 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * Re-enable python-support and add python:Depends to control file. - * ikiwiki-makerepo: Avoid using abs_path, as it apparently - fails on nonexistant directories with some broken perl - versions. - * inline: Minor optimisation. - * add_link: New function, which plugins should use rather than - modifying %links directly, to avoid it accumulating duplicates. - * ikiwiki-transition: Add a deduplinks action, that can be used - to remove duplicate links and optimise a wiki w/o rebuilding it. - * external: Fix pagespec_match and pagespec_match_list. - Closes: #527281 -"""]] diff --git a/doc/news/version_3.13.mdwn b/doc/news/version_3.13.mdwn deleted file mode 100644 index 0c8f7ab8b..000000000 --- a/doc/news/version_3.13.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -News for ikiwiki 3.13: - - The `ikiwiki-transition deduplinks` command introduced in the - last release was buggy. If you followed the NEWS file instructions - and ran it, you should run `ikiwiki -setup` to rebuild your wiki - to fix the problem. - -ikiwiki 3.13 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * ikiwiki-transition: If passed a nonexistant srcdir, or one not - containing .ikiwiki, abort with an error rather than creating it. - * Allow underlaydir to be overridden without messing up inclusion - of other underlays via add\_underlay. - * More friendly display of markdown, textile in edit form selector - (jmtd) - * Allow curly braces to be used in pagespecs, and avoid a whole class - of potential security problems, by avoiding performing any string - interpolation on user-supplied data when translating pagespecs. - * ikiwiki-transition: Allow setup files to be passed to all subcommands - that need a srcdir. - * ikiwiki-transition: deduplinks was broken and threw away all - metadata stored by plugins in the index. Fix this bug. - * listdirectives: Avoid listing \_comment directives and generally - assume any directive starting with \_ is likewise internal."""]]
\ No newline at end of file diff --git a/doc/news/version_3.141.mdwn b/doc/news/version_3.141.mdwn new file mode 100644 index 000000000..ac76ce023 --- /dev/null +++ b/doc/news/version_3.141.mdwn @@ -0,0 +1,28 @@ +ikiwiki 3.141 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * comment: Make comment directives no longer use the internal "\_comment" + form, and document the comment directive syntax. + * Avoid relying on translators preserving the case when translating + "discussion", which caused Discussion pages to get unwanted Discussion + links. + * Tighten up matching of bare words inside directives; do not + allow an unterminated triple string to be treated as a series + of bare words. Fixes runaway regexp recursion/backtracking + in strange situations. + * Setup automator: Check that each plugin added to the generated + setup file can be loaded and that its config is ok. If a plugin + fails for any reason, disable it in the generated file. + Closes: [532001](http://bugs.debian.org/532001) + * pagecount: Fix broken optimisation for * pagespec. + * goto: Support being passed a page title that is not a valid page + name, to support several cases including mercurial's long user + names on the RecentChanges page, and urls with spaces being handled + by the 404 plugin. + * Optimise use of gettext, and avoid ugly warnings if Locale::gettext + is not available. Closes: #[532285](http://bugs.debian.org/532285) + * meta: Add openid delegate parameter to allow delegating only + openid or openid2. + * Disable the Preferences link if no plugin with an auth hook is enabled. + * Updated French translation. Closes: #[532654](http://bugs.debian.org/532654) + * aggregate: Fix storing of changed md5. + * aggregate: Avoid resetting ctime when an item md5 changes."""]] diff --git a/doc/news/version_3.141/discussion.mdwn b/doc/news/version_3.141/discussion.mdwn new file mode 100644 index 000000000..1f5f39282 --- /dev/null +++ b/doc/news/version_3.141/discussion.mdwn @@ -0,0 +1,16 @@ +Version 3.141!? Is it not a mistake? Maybe you meant 3.14.1 or 3.15? +--[[Paweł|users/ptecza]] + +> I suspect the next version will be 3.1415 ;) -- [[Jon]] + +>> And next 3.14159, 3.141592, etc. :) I think that version schema +>> should be patented by Joey ;) --[[Paweł|users/ptecza]] + +>>> That's not exactly new; quoting from <http://www-cs-faculty.stanford.edu/~knuth/abcde.html>: +>>> +>>>> The latest and best TeX is currently version 3.1415926 (and plain.tex is version 3.141592653); METAFONT is currently version 2.718281 (and plain.mf is version 2.71). My last will and testament for TeX and METAFONT is that their version numbers ultimately become $\pi$ and $e$, respectively. At that point they will be completely error-free by definition. +>>> +>>> --[[tschwinge]] + +>>>> Thanks for the info, Thomas! I didn't know about it. Sorry Joey, +>>>> but Don Knuth was faster. What a pity... ;) --[[Paweł|users/ptecza]] diff --git a/doc/news/version_3.1415.mdwn b/doc/news/version_3.1415.mdwn new file mode 100644 index 000000000..93310bc64 --- /dev/null +++ b/doc/news/version_3.1415.mdwn @@ -0,0 +1,7 @@ +ikiwiki 3.1415 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * img: Fix extra double quote with alt text. (smcv) + * Updated French debconf templates translation. Closes: #[535103](http://bugs.debian.org/535103) + * openid: Support Net::OpenID 2.x when pretty-printing + openids. (smcv) + * highlight: Fix utf-8 encoding bug. Closes: #[535028](http://bugs.debian.org/535028)"""]]
\ No newline at end of file diff --git a/doc/news/version_3.14159.mdwn b/doc/news/version_3.14159.mdwn new file mode 100644 index 000000000..21f91fdb4 --- /dev/null +++ b/doc/news/version_3.14159.mdwn @@ -0,0 +1,5 @@ +ikiwiki 3.14159 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * svn: Fix rcs\_rename to properly scope call to dirname. + * img: Pass the align parameter through to the generated img tag. + * Move OpenID pretty-printing from openid plugin to core (smcv)"""]]
\ No newline at end of file diff --git a/doc/patch/core.mdwn b/doc/patch/core.mdwn new file mode 100644 index 000000000..fcf0bdb72 --- /dev/null +++ b/doc/patch/core.mdwn @@ -0,0 +1,7 @@ +Some [[patches|patch]] affect the ikiwiki core, rather than just a plugin. +This tag collects those patches. Please tag such patches with 'patch/core' +as well as 'patch'. + +[[!inline pages="(todo/* or bugs/*) and link(patch/core) + and !link(bugs/done) and !link(todo/done) and !*/Discussion" + rootpage="todo" archive="yes"]] diff --git a/doc/plugins/anonok.mdwn b/doc/plugins/anonok.mdwn index a3fec4d89..497ca07c8 100644 --- a/doc/plugins/anonok.mdwn +++ b/doc/plugins/anonok.mdwn @@ -6,7 +6,7 @@ anonymous web users, who have not signed in, to edit any page in the wiki by default. The plugin also has a configuration setting, `anonok_pagespec`. This -[[PageSpec]] can be used to allow anonymous editing of matching pages. +[[ikiwiki/PageSpec]] can be used to allow anonymous editing of matching pages. If you're using the [[comments]] plugin, you can allow anonymous comments to be posted by setting: diff --git a/doc/plugins/contrib/album.mdwn b/doc/plugins/contrib/album.mdwn new file mode 100644 index 000000000..94d5789d7 --- /dev/null +++ b/doc/plugins/contrib/album.mdwn @@ -0,0 +1,100 @@ +[[!template id=plugin name=album author="[[Simon_McVittie|smcv]]"]] +[[!tag type/chrome]] + +Available from [[smcv]]'s git repository, in the `album` branch +([[users/smcv/gallery|users/smcv/gallery]] contains some older +thoughts about this plugin). + +This plugin formats a collection of images into a photo album, +in the same way as many websites: good examples include the +PHP application [Gallery](http://gallery.menalto.com/), Flickr, +and Facebook's Photos "application". I've called it `album` +to distinguish it from [[contrib/gallery|plugins/contrib/gallery]], +although `gallery` might well be a better name for this functionality. + +The web UI I'm trying to achieve consists of one +[HTML page of thumbnails](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/) +as an entry point to the album, where each thumbnail links to +[a "viewer" HTML page](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/img_0068/) +with a full size image, next/previous thumbnail links, and +[[plugins/comments]]. + +(The Summer of Code [[plugins/contrib/gallery]] plugin does the +next/previous UI in Javascript using Lightbox, which means that +individual photos can't be bookmarked in a meaningful way, and +the best it can do as a fallback for non-Javascript browsers +is to provide a direct link to the image.) + +## Writing the viewers + + \[[!albumimage image=foo.jpg album=myalbum + title=... + caption=... + copyright=... + size=... + viewertemplate=... + ]] + +Each viewer contains one `\[[!albumimage]]` directive. This +sets the `image` filename, the `album` in which this image appears, +and an optional `caption`, and can override the `size` at which to +display the image and the `viewertemplate` to use to display the +image. + +It can also have `title`, `copyright` and `date` parameters, which +are short-cuts for [[ikiwiki/directive/meta]] directives. + +The viewer can also have any other content, but typically the +directive will be the only thing there. + +Eventually, there will be a specialized CGI user interface to +edit all the photos of an album at once, upload a new photo +(which will attach the photo but also write out a viewer page +for it), or mark an already-uploaded photo as a member of an +album (which is done by writing out a viewer page for it). + +The `\[[!albumimage]]` directive is replaced by an +[[ikiwiki/directive/img]], wrapped in some formatting using a +template (by default `albumviewer.tmpl`). The template can (and +should) also include "next photo", "previous photo" and +"up to gallery" links. + +The next/previous links are themselves implemented by +[[inlining|ikiwiki/directive/inline]] the next or previous +photo, using a special template (by default `albumnext.tmpl` +or `albumprev.tmpl`), in `archive`/`quick` mode. + +## Writing the album + +The album contains one `\[[!album]]` directive. It may also +contain any number of `\[[!albumsection]]` directives, for +example the demo album linked above could look like: + + \[[!album]] + <!-- replaced with one uncategorized photo --> + + ## Gamarra + + \[[!albumsection filter="link(gamarra)"]] + <!-- all the Gamarra photos --> + + ## Smokescreen + + \[[!albumsection filter="link(smokescreen)"]] + <!-- all the Smokescreen photos --> + + ... + +The `\[[!album]]` directive is replaced by an +[[ikiwiki/directive/inline]] which automatically includes every +page that has an `\[[!albumimage]]` directive linking it to this +album, except those that will appear in an `\[[!albumsection]]`. + +The `inline` is in `archive`/`quick` mode, but includes some +extra information about the images, including file size and a +thumbnail (again, made using [[ikiwiki/directive/img]]). The +default template is `albumitem.tmpl`, which takes advantage +of these things. + +Each `\[[!albumsection]]` is replaced by a similar inline, which +selects a subset of the photos in the album. 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 5e3db3d7c..b9ad3cc8e 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 @@ -39,3 +39,9 @@ I'm missing something terribly obvious? --Peter By the way: these need not be *HTML* files; `copyright.mdwn`, respectively `license.mdwn`, or every other format supported by ikiwiki are likewise fine. --[[tschwinge]] + +> Jon has done something similar in [[todo/allow_site-wide_meta_definitions]]; +> his version has the advantages that it doesn't invent magical page names, +> 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]] diff --git a/doc/plugins/contrib/mediawiki.mdwn b/doc/plugins/contrib/mediawiki.mdwn index c0a23254f..7bf1ba0df 100644 --- a/doc/plugins/contrib/mediawiki.mdwn +++ b/doc/plugins/contrib/mediawiki.mdwn @@ -3,3 +3,5 @@ [The Mediawiki plugin](http://u32.net/Mediawiki_Plugin/) allows ikiwiki to process pages written using MediaWiki markup. + +Available at <http://alcopop.org/~jon/mediawiki.pm> diff --git a/doc/plugins/contrib/mediawiki/discussion.mdwn b/doc/plugins/contrib/mediawiki/discussion.mdwn new file mode 100644 index 000000000..5066d9de5 --- /dev/null +++ b/doc/plugins/contrib/mediawiki/discussion.mdwn @@ -0,0 +1,5 @@ +Anyone know a safe place where this plugin can be found? -- mjr at phonecoop.coop + +> I ended up doing a backassward way of doing it, as described at the [convert discussion page](http://ikiwiki.info/tips/convert_mediawiki_to_ikiwiki/discussion/). -[[simonraven]] + +>> I've mirrored it at <http://alcopop.org/~jon/mediawiki.pm>. -- [[Jon]] diff --git a/doc/plugins/contrib/trail.mdwn b/doc/plugins/contrib/trail.mdwn new file mode 100644 index 000000000..d8dc02f47 --- /dev/null +++ b/doc/plugins/contrib/trail.mdwn @@ -0,0 +1,60 @@ +[[!tag type/chrome patch]] + +Available from [[smcv]]'s git repository, in the `trail` branch. This +plugin aims to solve [[todo/wikitrails]] in a simpler way. + +Joey: what do you think of this plugin? If you like the general approach +and are likely to include it in ikiwiki, I'll try to modify +[[plugins/contrib/album]] to be based on it, rather than partially +reinventing it. + +This plugin can benefit from +[[another_of_my_branches|todo/inline_plugin:_specifying_ordered_page_names]] +but does not require it. + +---- + +[[!template id=plugin name=trail author="[[Simon_McVittie|smcv]]"]] + +It's sometimes useful to have "trails" of pages in a wiki, as a guided +tour, sequence of chapters etc. In this plugin, a trail is represented +by a page, and the pages in the trail are indicated by specially marked +links within that page. + +If using the default `page.tmpl`, each page automatically displays the +trails that it's a member of (if any), with links to the trail and to +the next and previous members. + +The `traillink` [[ikiwiki/directive]] is used to record which pages +are in a trail, and simultaneously link to them. Alternatively, the +[[ikiwiki/directive/inline]] directive can be used with `trail=yes` +to record the inlined pages as part of the trail, in the order in +which they are inlined. + +## Directives + +(These will go to the appropriate pages in [[ikiwiki/directive]] if this +plugin is included in ikiwiki.) + +### traillink + +The `traillink` directive is supplied by the [[!iki plugins/contrib/trail desc=trail]] +plugin. This directive appears on the page representing a trail. It acts +as a visible [[ikiwiki/WikiLink]], but also records the linked page as +a member of the trail. + +Various syntaxes can be used: + + \[[!traillink Badgers]] + \[[!traillink How_to_find_mushrooms_using_badgers|badgers]] + \[[!traillink badgers text="How to find mushrooms using badgers"]] + +### trailoptions + +The `trailoptions` directive is supplied by the [[!iki plugins/contrib/trail desc=trail]] +plugin. This directive appears on the page representing a trail, and +produces no output. + +Currently, the only option supported is `[[!trailoptions circular=yes]]`, +which adds links between the first and last pages, turning the trail into +a circle. diff --git a/doc/plugins/highlight/discussion.mdwn b/doc/plugins/highlight/discussion.mdwn new file mode 100644 index 000000000..7d3cabea9 --- /dev/null +++ b/doc/plugins/highlight/discussion.mdwn @@ -0,0 +1,12 @@ +It would be nice to be able to set a few options for the highlighter +object. In particular, today I noticed my tabs were not being expanded +correctly, which could be fixed the command line with --replace-tabs but +programmatically needs a call to setPreformatting. I could probably play +with this, but what is your preferred way to support options? something +like 'highlight_options=>{replace_tabs=>8,line_numbers=>0}' ? Of course, +if you want to implement it I won't complain :-). [[DavidBremner]] + +> I don't know about tab replacement, which I can't really see the point +> of, but if there are multiple options, giving each its own nane would +> word better for websetup than would putting all the options in a +> sub-hash. --[[Joey]] diff --git a/doc/plugins/rst/discussion.mdwn b/doc/plugins/rst/discussion.mdwn index a792b670f..9909784d5 100644 --- a/doc/plugins/rst/discussion.mdwn +++ b/doc/plugins/rst/discussion.mdwn @@ -29,4 +29,15 @@ An exhaustive list of differences between prest and "standard" reST follows: * csv directive doesn't require csv.py * references directive doesn't allow options -There may be a few others; my eyes glazed over. --Ethan
\ No newline at end of file +There may be a few others; my eyes glazed over. --Ethan + +rst support for ikiwiki seems to be on hold. rst is much more elegant +than markdown in my opinion, so I tried it out in ikiwiki. I found out +in other places that some directives work just fine, like [[meta]] and +[[tag]], others work fine if you wrap them in `.. raw::`, like [[inline]]. + +But to make a wiki we need [[WikiLinks]]; they can't be escape-inserted or +such since they are inline elements in the text.. But images work fine in +rst's syntax.. what about using rst syntax for wikilinks as well? +Is it possible to inject something into the parser to turn unmached links +``WikiLink`_` into ikiwiki links? --ulrik diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn index 4b6b9f270..6730dd146 100644 --- a/doc/sandbox.mdwn +++ b/doc/sandbox.mdwn @@ -1,6 +1,22 @@ This is the [[SandBox]], a page anyone can edit to try out ikiwiki (version [[!version ]]). ---- +2009/7/13 Monday Blue...\\ +While working on [[http://eoffice.im.fju.edu.tw/phpbb/viewtopic.php?p=27199|[97] Phpbb 與 Dokuwiki 之間的往來]] (External Link to //http://eoffice.im.fju.edu.tw/phpbb/viewtopic.php?p=27199// not working?), surf Internet for Wikis supporting //Creole V1.0//, found this site. + +<<<<<<< HEAD:doc/sandbox.mdwn +* I thought that creole markup is used by ikiwiki... +* Thought about using //SVN/CVS// server, however with different idea +* Kinda curious why **Tcl** does not show her face in this Wiki arena +======= +* Thought about using //SVN/CVS// server, however with different idea +* Kinda curious why **Tcl** does not show her face in this Wiki arena +* It looks like that I was wrong, from Wikipedia Creole page it mention that ikiwiki is also adopting Creole markup. +>>>>>>> 55c1a37cce91d4fd01bf80fcaeeaf56535218a5c:doc/sandbox.mdwn + +---- + +Testing OpenID some more.. test more test [[中文显示]] @@ -90,7 +106,56 @@ But, of course, rsync is better. Let's see what happens... ~~ -測試的啦 +#中文标题一 +##中文标题二 +###中文标题三 +... +######中文标题六 + +###正文: + +君不见，黄河之水天上来，奔流到海不复回。 + +君不见，高堂明镜悲白发，朝如青丝暮成雪。 + +人生得意须尽欢，莫使金樽空对月。 + +天生我材必有用，千金散尽还复来。 + +###列表： + +* 天空 + + 1. 蓝色的 + 2. 好高啊 + +* 海洋 + + 1. 有鱼 + + * 鲸鱼 + * 鲨鱼 + + +* 大地 + +###链接： + +[谷歌](http://www.google.com) + +###引用： + +> 一级引用 +> +> 一级引用 +> +> > 二级引用 +> +>> 没有空格也可以 +>>> 三级引用 +> +> 回到一级引用 + ---- @@ -99,3 +164,5 @@ testing -- [[!toc levels=2]] + +[[Mamma Mia]] diff --git a/doc/sandbox/test.mdwn b/doc/sandbox/test.mdwn new file mode 100644 index 000000000..db20a2fbc --- /dev/null +++ b/doc/sandbox/test.mdwn @@ -0,0 +1 @@ +testing my openid provider @ www.steve.org.uk diff --git a/doc/tipjar.mdwn b/doc/tipjar.mdwn index e678053bb..787df9bf7 100644 --- a/doc/tipjar.mdwn +++ b/doc/tipjar.mdwn @@ -12,6 +12,7 @@ Thanks to the following people for their kind contributions: * Adam Shand * Martin Krafft * Paweł Tęcza +* Mick Pollard (Note that this page is locked to prevent anyone from tampering with the PayPal button. If you prefer your donation *not* be listed here, let [[Joey]] know.) diff --git a/doc/tips/dot_cgi.mdwn b/doc/tips/dot_cgi.mdwn index 64d7a0757..4532c84cd 100644 --- a/doc/tips/dot_cgi.mdwn +++ b/doc/tips/dot_cgi.mdwn @@ -55,3 +55,9 @@ rule that allow `ikiwiki.cgi` to be executed. **Warning:** I only use this lighttpd configuration on my development server (offline). I am not sure of how secure this approach is. If you have any thought about it, feel free to let me know. + +## boa + +Edit /etc/boa/boa.conf and make sure the following line is not commented: + + AddType application/x-httpd-cgi cgi diff --git a/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn b/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn index 8ecdf36d0..e5ac391c3 100644 --- a/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn +++ b/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn @@ -83,4 +83,4 @@ regenerate this one against that). -- 1.5.2.2 -[[!tag patch]] +[[!tag patch patch/core plugins/inline]] diff --git a/doc/todo/Add_space_before_slash_in_parent_links.mdwn b/doc/todo/Add_space_before_slash_in_parent_links.mdwn index 40a334032..9eb8e5364 100644 --- a/doc/todo/Add_space_before_slash_in_parent_links.mdwn +++ b/doc/todo/Add_space_before_slash_in_parent_links.mdwn @@ -8,6 +8,11 @@ This [[patch]] adds a space before the forward-slash in the the parent links. Th >>> Yes, please. This seems to be something a lot of people want to customize. (I certainly do -- a forward slash only looks natural to Unix users) --[[sabr]] +>> Joey, would I be right to summarize your position on this as "people who +>> want to change the text of the templates should maintain their own version +>> of the `.tmpl` files"? It's not clear to me how this todo item could be +>> closed in a way acceptable to you, except perhaps as WONTFIX. --[[smcv]] + Before: ikiwiki/ todo/ Add space before slash in parent links diff --git a/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn b/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn index 5b9cc8742..17f45dda6 100644 --- a/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn +++ b/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn @@ -67,3 +67,15 @@ Patch: >>> Adding a new `canlogin` hook looks like overkill to me. [[Joey]], how >>> about making registration of the `auth` hook mandatory for all plugins >>> making sense of the "Preferences" link? --[[Lunar]] + +>>>> Hmm, using the `auth` hook existance does seem like a nice solution. +>>>> While splitting the preferences code out into its own plugin is +>>>> easily enough done, it has the minor problem of being yet another +>>>> file nearly all ikiwikis will have to load, and also, prefs would +>>>> have to be disabled manually. So I like that using the hook would +>>>> cause it to auto-disable if nothing uses it. It's a bit ugly that +>>>> passwordauth doesn't need an auth hook (it could be reorged to +>>>> use it instead of formbuilder, maybe) and would probably just have an +>>>> empty one. Thanks for the idea. --[[Joey]] [[done]] + +>>>>> Thanks for implementing it! --[[Lunar]] diff --git a/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn b/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn index 95c38f794..bf8de16cd 100644 --- a/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn +++ b/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn @@ -1,5 +1,8 @@ This patch adds function bestdir() which returns best directory from the directory structure. This is in addition to the bestlink() function which is there in IkiWiki.pm +> Um, what is this for? :-) It would probably be a lot easier to review if it +> had documentation, and/or a plugin that used it. --[[smcv]] + ------- Index: IkiWiki.pm @@ -45,4 +48,4 @@ This patch adds function bestdir() which returns best directory from the directo ---- -[[users/arpitjain]] -[[!tag patch]] +[[!tag patch patch/core]] diff --git a/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn b/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn index 89167c084..4bc828e6e 100644 --- a/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn +++ b/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn @@ -1,4 +1,4 @@ -[[!tag patch]] +[[!tag patch plugins/calendar]] Here's my next version of the patch - still a work in progress. diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn new file mode 100644 index 000000000..492a8d747 --- /dev/null +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -0,0 +1,73 @@ +[[!tag plugins/meta patch]] + +I'd like to define [[plugins/meta]] values to apply across all pages +site-wide unless the pages define their own: default values for meta +definitions essentially. + +Here's a patch to achieve this (also in the "defaultmeta" branch of +my github ikiwiki fork): + + diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm + index b229592..3132257 100644 + --- a/IkiWiki/Plugin/meta.pm + +++ b/IkiWiki/Plugin/meta.pm + @@ -13,6 +13,7 @@ sub import { + hook(type => "needsbuild", id => "meta", call => \&needsbuild); + hook(type => "preprocess", id => "meta", call => \&preprocess, scan => 1); + hook(type => "pagetemplate", id => "meta", call => \&pagetemplate); + + hook(type => "scan", id => "meta", call => \&scan); + } + + sub getsetup () { + @@ -302,6 +303,15 @@ sub match { + } + } + + +sub scan() { + + my %params = @_; + + my $page = $params{page}; + + foreach my $type (map { s/^meta_//; $_ } grep /^meta_/, keys %config) { + + $pagestate{$page}{meta}{$type} = $config{"meta_$type"} + + unless defined $pagestate{$page}{meta}{$type}; + + } + +} + + + package IkiWiki::PageSpec; + + sub match_title ($$;@) { + diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn + index 000f461..200c4b2 100644 + --- a/doc/ikiwiki/directive/meta.mdwn + +++ b/doc/ikiwiki/directive/meta.mdwn + @@ -12,6 +12,12 @@ also specifies some additional sub-parameters. + The field values are treated as HTML entity-escaped text, so you can include + a quote in the text by writing `"` and so on. + + +You can also define site-wide defaults for meta values by including them + +in your setup file, e.g. + + + + meta_copyright => "Copyright 2007 by Joey Hess", + + meta_license => "GPL v2+", + + + Supported fields: + + * title + +-- [[Jon]] + +> This doesn't support multiple-argument meta directives like +> `link=x rel=y`, or meta directives with special side-effects like +> `updated`. +> +> The first could be solved (if you care) by a syntax like this: +> +> meta_defaults => [ +> { copyright => "© me" }, +> { link => "about:blank", rel => "silly", }, +> ] +> +> The second could perhaps be solved by invoking `meta::preprocess` from within +> `scan` (which might be a simplification anyway), although this is complicated +> by the fact that some (but not all!) meta headers are idempotent. +> +> --[[smcv]] 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 f60fc3d6e..f1d33114f 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 @@ -4,7 +4,7 @@ Tags are mainly specific to the object to which they’re stuck. However, I ofte Also see: <http://madduck.net/blog/2008.01.06:new-blog/> and <http://users.itk.ppke.hu/~cstamas/code/ikiwiki/autocreatetagpage/> -[[!tag wishlist]] +[[!tag wishlist plugins/tag patch]] I would love to see this as well. -- dato diff --git a/doc/todo/backlinks_result_is_lossy.mdwn b/doc/todo/backlinks_result_is_lossy.mdwn new file mode 100644 index 000000000..7b64a4f2c --- /dev/null +++ b/doc/todo/backlinks_result_is_lossy.mdwn @@ -0,0 +1,10 @@ +[[!tag patch patch/core]] + +IkiWiki::backlinks returns a form of $backlinks{$page} that has undergone a +lossy transformation (to get it in the form that page templates want), making +it more difficult to use in other contexts (like pagestats). + +A commit on my `among` branch splits it into IkiWiki::backlink_pages +(which returns the keys of $backlinks{$page}, and might be suitable for +exporting) and IkiWiki::backlinks (which calls backlink_pages, then performs +the same lossy transformation as before on the result). diff --git a/doc/todo/blogpost_plugin.mdwn b/doc/todo/blogpost_plugin.mdwn index bb91ffd02..69df27271 100644 --- a/doc/todo/blogpost_plugin.mdwn +++ b/doc/todo/blogpost_plugin.mdwn @@ -153,4 +153,4 @@ Index: IkiWiki.pm our $version='unknown'; # VERSION_AUTOREPLACE done by Makefile, DNE </pre> -[[!tag patch]] +[[!tag patch patch/core]] diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn index e3b295123..e302a49ed 100644 --- a/doc/todo/enable-htaccess-files.mdwn +++ b/doc/todo/enable-htaccess-files.mdwn @@ -12,7 +12,7 @@ qr/(^|\/).svn\//, qr/.arch-ids\//, qr/{arch}\//], wiki_link_regexp => qr/\[\[(?:([^\]\|]+)\|)?([^\s\]#]+)(?:#([^\s\]]+))?\]\]/, -[[!tag patch]] +[[!tag patch patch/core]] This lets the site administrator have a `.htaccess` file in their underlay directory, say, then get it copied over when the wiki is built. Without @@ -39,6 +39,13 @@ access and such .htaccess files should not be accessible through wiki cgi. Of co > See [[!debbug 447267]] for a patch for this. +>> It looks to me as though this functionality won't be included in ikiwiki +>> unless someone who wants it takes responsibility for updating the patch +>> from that Debian bug to be applicable to current versions, so that there's a +>> setup file parameter for extra filenames to allow, defaulting to none +>> (i.e. a less simplistic patch than the one at the top of this page). +>> Joey, is this an accurate summary? --[[smcv]] + --- bump! I would like to see some form of this functionality included in ikiwiki. I use a patched version, but @@ -47,4 +54,8 @@ but I use ikiwiki with a very small group of people collaborating so svn/web acc and htaccess is for limiting access to some areas of wiki. It should be off by default of course. --Max -[[!tag patch]] +--- ++1 I want `.htaccess` so I can rewrite some old Wordpress URLs to make feeds work again. --[[hendry]] + +--- ++1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]] diff --git a/doc/todo/format_escape.mdwn b/doc/todo/format_escape.mdwn index 574883d1b..762f16646 100644 --- a/doc/todo/format_escape.mdwn +++ b/doc/todo/format_escape.mdwn @@ -97,7 +97,7 @@ I've created an updated [patch](http://www.idletheme.org/code/patches/ikiwiki-fo --Ryan Koppenhaver ## Original patch -[[!tag patch]] +[[!tag patch patch/core plugins/rst]] <pre> Index: debian/changelog diff --git a/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn b/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn index a6a6ec1e1..7cf37fbb9 100644 --- a/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn +++ b/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn @@ -12,7 +12,7 @@ while the default stays as it is now. > INSTALLMAN1DIR (though MakeMaker lacks one for man8). I'd prefer not > adding new variables where MakeMaker already has them. --[[Joey]] -[[!tag patch]] +[[!tag patch patch/core]] <pre> diff --git a/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn new file mode 100644 index 000000000..336ae38d6 --- /dev/null +++ b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn @@ -0,0 +1,14 @@ +A [[!taglink patch]] in my git repository (the inline-pagenames branch) adds +the following parameter to the [[ikiwiki/directive/inline]] directive: + +> * `pagenames` - If given instead of `pages`, this is interpreted as a +> space-separated list of links to pages (with the same +> [[ikiwiki/SubPage/LinkingRules]] as in a [[ikiwiki/WikiLink]]), and they are inlined +> in exactly the order given: the `sort` and `pages` parameters cannot be used +> in conjunction with this one. + +This is on my [[wishlist]] for my [[plugins/contrib/album]] plugin, which currently +uses it internally (as it has already collected the pages in order). It could also +be useful for other things, like [[todo/wikitrails]]. --[[smcv]] + +[[!tag plugins/inline]] diff --git a/doc/todo/inline_postform_autotitles.mdwn b/doc/todo/inline_postform_autotitles.mdwn index 5005208be..b3366f60e 100644 --- a/doc/todo/inline_postform_autotitles.mdwn +++ b/doc/todo/inline_postform_autotitles.mdwn @@ -1,5 +1,4 @@ -[[!tag wishlist]] -[[!tag patch]] +[[!tag wishlist patch plugins/inline]] for postforms in inlines of pages which follow a certain scheme, it might not be required to set the title for each individual post, but to automatically set diff --git a/doc/todo/language_definition_for_the_meta_plugin.mdwn b/doc/todo/language_definition_for_the_meta_plugin.mdwn index 4ac4e2e25..8c4b45141 100644 --- a/doc/todo/language_definition_for_the_meta_plugin.mdwn +++ b/doc/todo/language_definition_for_the_meta_plugin.mdwn @@ -81,4 +81,16 @@ This may be useful for sites with a few pages in different languages, but no ful > Please resolve lang somewhere reusable rather than within meta plugin: It is certainly usable outside > the scope of the meta plugin as well. --[[JonasSmedegaard]] +>> I don't see any problem with having this in meta? meta is on by default, and +>> other plugins are free to use it or even depend on it (e.g. inline does). +>> +>> My only comments on this patch beyond what Joey said are that the page +>> language could usefully go into `$pagestate{$page}{meta}{lang}` for other +>> plugins to be able to see it (is that what you meant?), and that +>> restricting to 2 characters is too restrictive (HTML 4.01 mentions +>> `en`, `en-US` and `i-navajo` as possible language codes). +>> This slightly complicates parsing the locale to get the default language: +>> it'll need `tr/_/-/` after the optional `.encoding` is removed. +>> --[[smcv]] + [[!tag wishlist patch plugins/meta translation]] diff --git a/doc/todo/meta_rcsid.mdwn b/doc/todo/meta_rcsid.mdwn index 158edea6e..9e112317f 100644 --- a/doc/todo/meta_rcsid.mdwn +++ b/doc/todo/meta_rcsid.mdwn @@ -1,4 +1,4 @@ -The following patch adds an 'rcsid' parameter to the Meta plugin, to allow inclusion +The following patch adds an 'rcsid' parameter to the [[!taglink plugins/Meta]] plugin, to allow inclusion of CVS/SVN-style keywords (like '$Id$', etc.) from the source file in the page template. > So the idea is you'd write something like: diff --git a/doc/todo/missingparents.pm.mdwn b/doc/todo/missingparents.pm.mdwn index c5f2ab535..cecac7a94 100644 --- a/doc/todo/missingparents.pm.mdwn +++ b/doc/todo/missingparents.pm.mdwn @@ -258,4 +258,4 @@ Index: IkiWiki.pm my $page=shift; </pre> -[[!tag patch]] +[[!tag patch patch/core]] diff --git a/doc/todo/more_class__61____34____34___for_css.mdwn b/doc/todo/more_class__61____34____34___for_css.mdwn index 4712c12b3..cace27d63 100644 --- a/doc/todo/more_class__61____34____34___for_css.mdwn +++ b/doc/todo/more_class__61____34____34___for_css.mdwn @@ -15,6 +15,8 @@ Here's the one-liner: > applied --[[Joey]] +---- + The following adds a div element with class="trailer" around the meta-information added after an inlined page (namely: the post date, the tags, and the actions): @@ -42,7 +44,7 @@ added after an inlined page (namely: the post date, the tags, and the actions): > gets confused by these nested div's and puts p's around one of them, generating > broken html. If you can come up with a way to put in the div that passes > the test suite, or a fix to markdown, I will accept it, but the above patch -> fails the test suite. --[[Joey]] +> fails the test suite. --[[Joey]] >> Just a note... This discrepancy doesn't exist in [pandoc](http://code.google.com/p/pandoc/) as >> demonstrated in the relevant [page](http://code.google.com/p/pandoc/wiki/PandocVsMarkdownPl). @@ -64,6 +66,16 @@ added after an inlined page (namely: the post date, the tags, and the actions): >>>> to at least get into debian testing before I make ikiwiki depend on it >>>> though. --[[Joey]] +>> This Markdown issue seems to have been worked around by the optimization +>> in which \[[!inline]] is replaced with a placeholder, and the +>> placeholder is later replaced by the HTML. Meanwhile, this patch +>> has been obsoleted by applying a similar one (wrapping things in a div +>> with class inlinefooter). That was the last remaining unapplied patch +>> on this page, so I think this whole page can be considered [[done]]. +>> --[[smcv]] + +---- + I'd like a class attribute on the `<span>` tag surrounding wikilinks that refer to non-existent pages, in Ikiwiki.pm:htmllink, so that such broken links can be styled more dramatically with CSS. --Jamey diff --git a/doc/todo/pagestats_among_a_subset_of_pages.mdwn b/doc/todo/pagestats_among_a_subset_of_pages.mdwn new file mode 100644 index 000000000..1c1656b4e --- /dev/null +++ b/doc/todo/pagestats_among_a_subset_of_pages.mdwn @@ -0,0 +1,26 @@ +[[!tag patch plugins/pagestats]] + +My `among` branch fixes [[todo/backlinks_result_is_lossy]], then uses that +to provide pagestats for links from a subset of pages. From the docs included +in the patch: + +> The optional `among` parameter limits counting to pages that match a +> [[ikiwiki/PageSpec]]. For instance, to display a cloud of tags used on blog +> entries, you could use: +> +> \[[!pagestats pages="tags/*" among="blog/posts/*"]] +> +> or to display a cloud of tags related to Linux, you could use: +> +> \[[!pagestats pages="tags/* and not tags/linux" among="tagged(linux)"]] + +I use this on my tag pages on one site, with the following template: + + \[[!pagestats pages="tags/* and !tags/<TMPL_VAR raw_tag> + and !tags/photogallery" + among="tagged(<TMPL_VAR raw_tag>)"]] + + \[[!inline pages="tagged(<TMPL_VAR raw_tag>)" + archive="yes" quick="yes" reverse="yes" timeformat="%x"]] + +--[[smcv]] diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn index 9598af234..29f28ca32 100644 --- a/doc/todo/passwordauth:_sendmail_interface.mdwn +++ b/doc/todo/passwordauth:_sendmail_interface.mdwn @@ -1,4 +1,4 @@ -[[!tag wishlist]] +[[!tag wishlist plugins/passwordauth]] For sending out password reminder emails, the [[plugins/passwordauth]] plugin currently uses the *[Mail::Sendmail](http://search.cpan.org/perldoc?Mail::Sendmail)* module. @@ -52,3 +52,10 @@ Remaining TODOs: > lost it. --[[Joey]] Resent. --[[tschwinge]] + +> Debian now has Mail::Sender, Mail::SendEasy, and Email::Sender +> (which, according to its dpkg description, "replaces the old and sometimes +> problematic Email::Send library, which did a decent job at handling very +> simple email sending tasks, but was not suitable for serious use, for a +> variety of reasons"). Are any of those any better? It's unfortunate that +> there doesn't seem to be a clear "best practice"... --[[smcv]] diff --git a/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn new file mode 100644 index 000000000..3d4338a78 --- /dev/null +++ b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn @@ -0,0 +1,29 @@ +A feature I originally requested on +[[a_related_bug|bugs/openid_no_longer_pretty-prints_OpenIDs]]: + + Allow the openid plugin to be loaded but disabled, for its side-effect of defining IkiWiki::openiduser + + On various sites I have two IkiWiki instances running from the same + repository: one accessible via http and only accepting openid logins, + and one accessible via authenticated https and only accepting httpauth. + Ideally, the https version should still pretty-print OpenIDs seen in + git history. + +--[[smcv]] + +> I wonder if an option is the best approach. Maybe it would be better to +> simply move `openiduser` into `userlink`, and thus always support openid +> usernames whether the plugin is enabled or not. --[[Joey]] + +>> OK, implemented that as 'smcv/always-openid'; if you don't think that's +>> bloating the IkiWiki core too much, please consider merging. The poll on +>> [[news/openid]] indicates fairly strong support for *only* accepting OpenID +>> logins, so I think recognising OpenIDs can reasonably be considered core +>> functionality! --[[smcv]] + +>>> That seemed easier than expected, [[done]]. +>>> (I do wonder if the call to openiduser still needs to be evaled -- +>>> it was probably only evaled before in case it was not available, but +>>> I have not carefully checked it to make sure it doesn't ever die. --[[Joey]] + +[[!tag patch]] diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 0ef8a7847..61458d972 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -79,4 +79,21 @@ I can think about reducung the size of my wiki source and making it available on > > --[[Joey]] -[[!tag wishlist]] +>> I've been looking at optimizing ikiwiki for a site using +>> [[plugins/contrib/album]] (which produces a lot of pages) and it seems +>> that checking which pages depend on which pages does take a significant +>> amount of time. The optimize-depends branch in my git repository +>> avoids using `pagespec_merge()` for this (indeed it's no longer used +>> at all), and instead represents dependencies as a list of pagespecs +>> rather than a single pagespec. This does turn out to be faster, although +>> not as much as I'd like. --[[smcv]] + +>>> I just wanted to note that there is a whole long discussion of dependencies and pagespecs on the [[todo/tracking_bugs_with_dependencies]] page. -- [[Will]] + +>>>> Yeah, I had a look at that (as the only other mention of `pagespec_merge`). +>>>> I think I might have solved some of the problems mentioned there, +>>>> actually - `pagespec_merge` no longer needs to exist in my branch (although +>>>> I haven't actually deleted it), because the "or" operation is now done in +>>>> the Perl code, rather than by merging pagespecs and translating. --[[smcv]] + +[[!tag wishlist patch patch/core]] diff --git a/doc/todo/source_link.mdwn b/doc/todo/source_link.mdwn index b051361a8..9d9ec9697 100644 --- a/doc/todo/source_link.mdwn +++ b/doc/todo/source_link.mdwn @@ -4,6 +4,11 @@ How about a direct link from the page header to the source of the latest version I just implemented this. There is one [[patch]] to the default page template, and a new plugin. -- [[Will]] +> The use of sessioncgi here seems undesirable: on wikis where anonymity is +> not allowed, you'll be asked to log in. Couldn't you achieve the same thing +> by loading the index with IkiWiki::loadindex, like [[plugins/goto]] does? +> --[[smcv]] + ---- diff --git a/templates/page.tmpl b/templates/page.tmpl diff --git a/doc/todo/support_for_plugins_written_in_other_languages.mdwn b/doc/todo/support_for_plugins_written_in_other_languages.mdwn index 8476d1b44..006b6fd5e 100644 --- a/doc/todo/support_for_plugins_written_in_other_languages.mdwn +++ b/doc/todo/support_for_plugins_written_in_other_languages.mdwn @@ -1,4 +1,4 @@ -ikiwiki should support writing plugins in other languages +ikiwiki should support [[writing plugins in other languages|plugins/write/external]] > [[done]] !! diff --git a/doc/todo/tmplvars_plugin.mdwn b/doc/todo/tmplvars_plugin.mdwn index 644cf23aa..2fe819682 100644 --- a/doc/todo/tmplvars_plugin.mdwn +++ b/doc/todo/tmplvars_plugin.mdwn @@ -2,6 +2,29 @@ A simple plugin to allow per-page customization of a template by passing paramat [[!tag patch]] +> The implementation looks fine to me (assuming it works with current ikiwiki), +> apart from the "XXX" already noted in the patch. The design could reasonably +> be considered premature generalization, though - how often do you actually +> need to define new tmplvars? +> +> As for the page/destpage/preview thing, it would be good if the preprocess +> hook could distinguish between software-supplied and user-supplied +> parameters (the [[plugins/tag]] plugin could benefit from this too). Perhaps +> the IkiWiki core could be modified so that +> `hook(type => "preprocess", splitparams => 1, ...)` would invoke preprocess +> with { page => "foo", destpage => "bar", ... } as a special first argument, +> and the user-supplied parameters as subsequent arguments? Then plugins like +> tag could use: +> +> my $ikiparams = shift; +> my %params = @_; +> +> add_tags($ikiparams->{page}, keys %params); +> +> --[[smcv]] + +---- + #!/usr/bin/perl package IkiWiki::Plugin::tmplvars; diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index 3a761731b..80aaf3c39 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -1,3 +1,5 @@ +[[!tag patch patch/core]] + I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so on several wikis. However, as far as I can tell, ikiwiki has no functionality which can represent dependencies between bugs and allow pagespecs to select based on dependencies. For instance, I can't write a pagespec which selects all bugs with no dependencies on bugs not marked as done. --[[JoshTriplett]] > I started having a think about this. I'm going to start with the idea that expanding diff --git a/doc/todo/unaccent_url_instead_of_encoding.mdwn b/doc/todo/unaccent_url_instead_of_encoding.mdwn index 1be150a82..d74b632bd 100644 --- a/doc/todo/unaccent_url_instead_of_encoding.mdwn +++ b/doc/todo/unaccent_url_instead_of_encoding.mdwn @@ -6,4 +6,4 @@ This is a one liner change, but requires a bit of reordering in the code. [[cstamas]] -[[!tag wishlist patch]] +[[!tag wishlist patch patch/core]] diff --git a/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn b/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn index b28469993..d292a1184 100644 --- a/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn +++ b/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn @@ -33,6 +33,12 @@ ManojSrivastava > > directory, which is not very easy for a plain ol' user. Not everyone is the > > sysadmin of their own machines with access to system dirs. --ManojSrivastava +>>> It seems worth mentioning here that the `libdir` configuration parameter +>>> lets you install additional plugins in a user-controlled directory +>>> (*libdir*`/IkiWiki/Plugin`), avoiding needing root; indeed, a full local +>>> ikiwiki installation without any involvement from the sysadmin is +>>> [[possible|tips/DreamHost]]. --[[smcv]] + <pre> varioki => {'motto' => '"Manoj\'s musings"', 'arrayvar' => '[0, 1, 2, 3]', diff --git a/doc/todo/wikitrails/discussion.mdwn b/doc/todo/wikitrails/discussion.mdwn index 327e61491..9dbbb6bc8 100644 --- a/doc/todo/wikitrails/discussion.mdwn +++ b/doc/todo/wikitrails/discussion.mdwn @@ -1,9 +1,3 @@ -This sounds like a more general version of what I want for -one-photo-per-page galleries, where each page has previous|up|next links -(like this plugin) and the index page has a list or grid of thumbnails -(\[[!inline]] with a specially modified template perhaps). I'll watch this -with interest! --[[smcv]] - This is a nice idea, I do have my gripes about the imeplementation. Assuming that the index's list is in mdwn format is not ideal. I guess the @@ -22,3 +16,65 @@ breadcrums to be automatically inserted at the top of every page on the trail. (You'd have to use a directive to define the index for that to work.) --[[Joey]] + +---- + +Revisiting this, after effectively reimplementing a small version of it +in [[plugins/contrib/album]]: it occurs to me that might be a more +"ikiwiki-like" way we could get this functionality. + +In the index page, you either want an [[ikiwiki/directive/inline]], or +a list of links. In the former case, maybe we could extend inline like +this: + + \[[!inline ... blah blah ... trail=yes]] + +to make it remember the pages it inlined, in order, in the pagestate; +in the latter case, we could replace the wikilinks with a directive, +an operation something like this in diff notation: + + - \[[one]] - the unit + - \[[two]] - the base of binary + - \[[three|3]] - is a crowd + + \[[!trailitem one]] - the unit + + \[[!trailitem two]] - the base of binary + + \[[!trailitem three|3]] - is a crowd + +and have that directive remember the pages in order. + +In both cases, a scan() hook could clear the list before starting to +scan, then the inline or trailitem preprocessor directive could run in +the scan stage as well as the render stage (in the case of inline, +there'd be a very early return if trail=yes was not given, and +an early return after collecting and sorting the pages if not +actually rendering). + +This would mean that the contents of the trail, and a list of +trails in which each page can be found, would already be in +the pagestate by the time any page was rendered, so we'd be able +to use them for output, either in a pagetemplate() hook or +a \[[!trail]] preprocessor directive. + +This way, my album plugin could be turned inside out: instead +of precomputing the pages to be inlined, then using +[[pagenames|todo/inline plugin: specifying ordered page names]] +to get them into the inline, it could just do the inline, then +incorporate the output of \[[!trail]] into the template rendered +for \[[!albumimage]] on each viewer page. (Also, the viewers +wouldn't necessarily need to reference the album, only the other +way round.) + +Using a pagetemplate() hook to stuff the next/previous links +into page.tmpl would actually be a bit unfortunate for \[[!album]], +because that plugin definitely wants to style the next/previous +links as a thumbnail, which means there'd have to be a way to +affect the style - perhaps by arranging for album's pagetemplate +hook to run *after* trail's, or perhaps by having trail's +pagetemplate hook disable itself for pages that contain +a \[[!trail]] directive. + +I have now implemented this at [[plugins/contrib/trail]]. +What do you think? I'm still not sure how it would relate +to [[plugins/contrib/album]], but if trail is reviewed +and approved in principle, I'll try to adapt album as +outlined above. --[[smcv]] diff --git a/doc/users/dom.mdwn b/doc/users/dom.mdwn new file mode 100644 index 000000000..c75435679 --- /dev/null +++ b/doc/users/dom.mdwn @@ -0,0 +1,3 @@ +<http://www.larted.org.uk/~dom> + +Just another ikiwiki user. diff --git a/doc/users/smcv/gallery.mdwn b/doc/users/smcv/gallery.mdwn index b6b8de79f..d80fc3ba1 100644 --- a/doc/users/smcv/gallery.mdwn +++ b/doc/users/smcv/gallery.mdwn @@ -1,8 +1,5 @@ -[[!template id=plugin name=smcvgallery author="[[Simon_McVittie|smcv]]"]] -[[!tag type/chrome]] - -This plugin has not yet been written; this page is an experiment in -design-by-documentation :-) +This plugin has now been implemented as [[plugins/contrib/album]]; this +page has older thoughts about it. ## Requirements @@ -124,6 +121,8 @@ an option!) ### Synthesize source pages for viewers +(Edited to add: this is what [[plugins/contrib/album]] implements. --[[smcv]]) + Another is to synthesize source pages for the viewers. This means they can have tags and metadata, but trying to arrange for them to be scanned etc. correctly without needing another refresh run is somewhat terrifying. @@ -145,6 +144,10 @@ in that directory during the refresh hook. The source pages could be in the underlay until they are edited (e.g. tagged), at which point they would be copied into the source-code-controlled version in the usual way. +> Coming back to this: a specialized web UI to mark attachments as part of +> the gallery would make this easy too - you'd put the photos in the +> underlay, then go to the CGI and say "add all". --[[smcv]] + The synthetic source pages can be very simple, using the same trick as my [[plugins/comments]] plugin (a dedicated [[directive|ikiwiki/directives]] encapsulating everything the plugin needs). If the plugin automatically @@ -153,6 +156,9 @@ only the human-edited information and a filename reference need to be present in the source page; with some clever lookup rules based on the filename of the source page, not even the photo's filename is necessarily needed. +> Coming back to this later: the clever lookup rules make dependency tracking +> hard, though. --[[smcv]] + \[[!meta title="..."]] \[[!meta date="..."]] \[[!meta copyright="..."]] |