diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/bugs/Toc_map_and_template_plugins_do_not_play_well_together.mdwn | 57 | ||||
| -rw-r--r-- | doc/download.mdwn | 9 | ||||
| -rw-r--r-- | doc/install.mdwn | 22 | ||||
| -rw-r--r-- | doc/news/code_swarm.mdwn | 4 | ||||
| -rw-r--r-- | doc/sandbox.mdwn | 2 | ||||
| -rw-r--r-- | doc/tipjar.mdwn | 7 | ||||
| -rw-r--r-- | doc/todo/Allow_TITLE_to_include_part_of_the_path_in_addition_to_the_basename.mdwn | 64 | ||||
| -rw-r--r-- | doc/todo/ability_to_force_particular_UUIDs_on_blog_posts.mdwn | 10 | ||||
| -rw-r--r-- | doc/todo/multiple_repository_support.mdwn | 15 |
9 files changed, 129 insertions, 61 deletions
diff --git a/doc/bugs/Toc_map_and_template_plugins_do_not_play_well_together.mdwn b/doc/bugs/Toc_map_and_template_plugins_do_not_play_well_together.mdwn index f49d14f9b..608948466 100644 --- a/doc/bugs/Toc_map_and_template_plugins_do_not_play_well_together.mdwn +++ b/doc/bugs/Toc_map_and_template_plugins_do_not_play_well_together.mdwn @@ -1,53 +1,30 @@ -I've got a wiki page that contains : +The following renders incorrectly: \[[!toc ]] - - # header1 - - content1 - - # header2 - - \[[!template id=bla]] - -And `templates/bla.mdwn` contains : - - # header3 - - content3 - - # header4 - - content4 - -If no `\[[!map]]` directive is anywhere in the template, the page is rendered as expected. -If `\[[!map]]` is used e.g. in content4, the wiki page is rendered with -the following elements : - -> Surely you mean a toc directive, not map? --[[Joey]] - ->> No, I really mean map, but I forgot to escape the toc above (in the example wiki page content), which prevented you from understanding my point. -- intrigeri + # header1 -- an empty toc div -- every markdown code before the first `\[[!map]]` directive is not - interpreted and rendered as-is : `# header1 content1 # header2 - content2 #header3 #header4 content4_before_the_map` -- the correctly rendered map directive result + content1 -If `\[[!map]]` is used in content3, the wiki page is rendered with -the following elements : + # header2 -- a TOC containing only the last header (header4) -- every markdown code before the first `\[[!map]]` directive is not - interpreted and rendered as-is : `# header1 content1 # header2 - content2 #header3 content3_before_the_map` -- content3 (starting at the map), header4 and content4 are all rendered as expected + \[[map pages="sandbox"]] -Moving the `\[[!toc]]` directive from the page to the template gives the same results. Removing the `\[[!toc]]` directive or moving it at the end of the page makes the whole wiki page be rendered as expected. Hint : in all cases, the non-interpreted markdown code is copied as-is in the HTML output, without any leading `<p>` or any HTML formatting. + +> You're using the old version of `markdown`, that is known to have a broken block +> html parser, that will get confused if markdown is present between two +> separate html blocks, and not format the markdown. +> +> This is fixed in [[cpan Text::MarkDown]] 1.0.19. markdown 1.0.2 also +> fixes the problem. Install either one. I'm going to make ikiwiki's +> dependencies list Text::Markdown before markdown, since people keep +> stumbling over this. (The downside is that the old broken markdown is +> faster). --[[Joey]] + +[[done]] diff --git a/doc/download.mdwn b/doc/download.mdwn index f3f0a004b..95c48b456 100644 --- a/doc/download.mdwn +++ b/doc/download.mdwn @@ -10,7 +10,7 @@ Installation steps and requirements are listed on the [[install]] page. ## packages -If using Debian (since 4.0), or Ubuntu (since 6.10): +To install with apt, if using Debian (since 4.0), or Ubuntu (since 6.10): [[template id=note text=""" Note that Debian 4.0 and especially Ubuntu 6.10 contain older versions of ikiwiki, there have been lots of enhancements and bug fixes since those @@ -28,10 +28,13 @@ There is also an unofficial backport of ikiwiki for Ubuntu Gutsy and Ubuntu Hardy, provided by Paweł Tęcza, at [http://gpa.net.icm.edu.pl/ubuntu/](http://gpa.net.icm.edu.pl/ubuntu/index-en.html). -Also, FreeBSD has ikiwiki in its +FreeBSD has ikiwiki in its [ports collection](http://www.freshports.org/www/ikiwiki/). -And Gentoo has an [ebuild](http://bugs.gentoo.org/show_bug.cgi?id=144453) in its bug database. +Gentoo has an [ebuild](http://bugs.gentoo.org/show_bug.cgi?id=144453) in its bug database. + +IkiWiki can be installed [from macports](http://www.macports.org/ports.php?by=name&substr=ikiwiki) +by running `sudo port install ikiwiki`. ## revision control diff --git a/doc/install.mdwn b/doc/install.mdwn index 40b7b4c5b..bd8c4b881 100644 --- a/doc/install.mdwn +++ b/doc/install.mdwn @@ -1,6 +1,7 @@ -The easiest way to install ikiwiki is using the Debian package, but you can -also [[download]] the source and install it by hand. Ikiwiki should work on -most unix-like systems. +This page documents how to install ikiwiki if a prepackaged version is not +available for your distribution, and you are faced with [[downloading|download]] +the source and installing by hand. Ikiwiki should work on most unix-like +systems. ## Dependencies @@ -18,21 +19,16 @@ they are available. Various [[plugins]] use other perl modules and utilities; see their individual documentation for details. -## Debian +### Installing dependencies with yum -The Debian packages depend on and recommend an appropriate set of packages, -so just install ikiwiki using apt. - -## Fedora 7 - -While Fedora 7 doesn't have an ikiwiki package, you can install needed -perl modules using this command: +Here's an example of how to install ikiwiki's dependencies using yum +on Fedora 7: yum install perl-Text-Markdown perl-Mail-Sendmail perl-HTML-Scrubber \ perl-XML-Simple perl-TimeDate perl-HTML-Template perl-CGI-FormBuilder \ perl-CGI-Session perl-File-MimeInfo perl-gettext perl-Authen-Passphrase -## Installing by hand +### Installing dependencies by hand If you want to install by hand from the tarball, you should make sure that all the perl modules are installed. This is one way to install them, using @@ -41,6 +37,8 @@ CPAN: PERL5LIB=`pwd` PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'CPAN::Shell->install("Bundle::IkiWiki")' PERL5LIB=`pwd` PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'CPAN::Shell->install("Bundle::IkiWiki::Extras")' +## Installing ikiwiki by hand + Then to build and install ikiwiki: perl Makefile.PL # PREFIX=/dir to install elsewhere diff --git a/doc/news/code_swarm.mdwn b/doc/news/code_swarm.mdwn index 3d43be8c8..5302d626b 100644 --- a/doc/news/code_swarm.mdwn +++ b/doc/news/code_swarm.mdwn @@ -3,8 +3,8 @@ visualization of the first 2+ years of ikiwiki's commit history. [[img screenshot.png size="480x360"]] -* [50 MB ogg vorbis](http://kitenet.net/~joey/screencasts/ikiwiki_swarm.ogg) -* high quality version not yet uploaded +* [15 mb avi](http://kitenet.net/~joey/screencasts/ikiwiki_swarm.avi) +* [stream on vimeo](http://vimeo.com/1324348) PS, while I'm posting links to videos, here's a [video of a lightning talk about ikiwiki](http://log.hugoschotman.com/hugo/2008/07/webtuesday-2008-07-08-lightning-talk-by-axel-beckert-about-ikiwiki.html). diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn index 5a4f17221..5c7368fc3 100644 --- a/doc/sandbox.mdwn +++ b/doc/sandbox.mdwn @@ -2,6 +2,8 @@ This is the SandBox, a page anyone can edit to try out ikiwiki. blather!! +Testing an edit in the sandbox. + ---- Here's a paragraph. diff --git a/doc/tipjar.mdwn b/doc/tipjar.mdwn index 74d03d7bf..e678053bb 100644 --- a/doc/tipjar.mdwn +++ b/doc/tipjar.mdwn @@ -5,12 +5,13 @@ choose. If you'd like to fund development of a specific feature, see the <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=joey%40kitenet%2enet&item_name=ikiwiki&no_shipping=1&cn=Comments%3f&tax=0¤cy_code=USD&lc=US&bn=PP%2dDonationsBF&charset=UTF%2d8"><img src="https://www.paypal.com/en_US/i/btn/x-click-but04.gif" alt="donate with PayPal" /></a> -If you would like your donation listed here, let [[Joey]] know. Thanks to -the following people for their kind contributions: +Thanks to the following people for their kind contributions: * James Westby * Kyle S MacLea * Adam Shand * Martin Krafft +* Paweł Tęcza -(Note that this page is locked to prevent anyone from tampering with the PayPal button.) +(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/todo/Allow_TITLE_to_include_part_of_the_path_in_addition_to_the_basename.mdwn b/doc/todo/Allow_TITLE_to_include_part_of_the_path_in_addition_to_the_basename.mdwn new file mode 100644 index 000000000..cdabdb774 --- /dev/null +++ b/doc/todo/Allow_TITLE_to_include_part_of_the_path_in_addition_to_the_basename.mdwn @@ -0,0 +1,64 @@ +I need to display part of my pages' path in the `<title>` meta HTML +header instead of their basename ; e.g. for /abs/path/to/basename, I'd +like to set it to path/to/basename. + +Of course, one might consider it's my own problem, as I could +workaround this in my templates, and replace, in the `<title>` meta +HTML header, `<TMPL_VAR TITLE>` with a `TMPL_LOOP` on `PARENTLINKS`, +but... + +- it's ugly (call it a semantic hijacking if you want) ; a side-effect + of this ugliness is : +- it defeats any further plugin's (e.g. [[plugins/meta]]) + attempt to override the default title with a nicer one ; +- all parents appear : there is no way to specify how deep to go up in + the parents tree. + +So I really want to avoid this ugly workaround. + +Looking at `Render.pm`, the second solution I thought of was : + +- add a `parents_in_page_title` configuration option (default=0, i.e. + the current behaviour) ; +- modify `Render.pm` to insert as much parents as possible (up to + `N=parents_in_page_title`), separated by '/', in the `title` + template parameter, before the actual page basename ; I personally + would use N=2. + +The only problems I can see with this approach are : + +- it requires modification of the core, which may not be desirable +- the resulting title would be unconditionally overridden by the meta + plugin, and I can think of no clean solution to make this + configurable without hacking [[plugins/meta]], which I'd rather not + to ; I don't care, but once you add a ad-hoc feature to the core, + you can be sure someone will want a more generic version in less than + three months ;) + +I'm not too convinced writing a plugin for such a small feature isn't +overdoing it, so I'm tempted to implement this solution in the +simplest way : the generated title would be the default and could be +overridden later by plugins. + +Joey, what do you think ? + +(Before starting to write any single line of code, I need to know how +much you are on the "if you can do it as a plugin, don't ever modify +the core" side... :) + +In case you're on the hardcore side, I would probably write +a dedicated plugin, called `genealogictitle` or whatever, and : + +- use the pagetemplate hook to modify the `title` template parameter, + and maybe set `title_overridden`, as does the meta plugin +- add a `genealogictitle_depth` configuration option to tell how many + parents to display +- maybe add a `genealogictitle_overrides_meta` or whatever to decide + whether a title overridden by [[plugins/meta]] should be overridden + by genealogictitle ; but anyway, I've not found, in the plugins + documentation, any hint about the order in which the plugins are + called for a given hook, so the "choose the strongest between meta + and genealogictitle" thing might just be more complicated... (no, + I did not Read The Nice Source, yet). + +-- intrigeri diff --git a/doc/todo/ability_to_force_particular_UUIDs_on_blog_posts.mdwn b/doc/todo/ability_to_force_particular_UUIDs_on_blog_posts.mdwn index 4bc3ffc8e..0f8f9bb73 100644 --- a/doc/todo/ability_to_force_particular_UUIDs_on_blog_posts.mdwn +++ b/doc/todo/ability_to_force_particular_UUIDs_on_blog_posts.mdwn @@ -1,7 +1,15 @@ When converting an existing blog to ikiwiki it would be useful to be able to preserve any existing UUIDs on posts, in order to [avoid flooding aggregators](/tips/howto_avoid_flooding_aggregators/). -Also, it should be possible to change the canonical URL of a post, i.e. the atom `<link>` (e.g. leaving a redirector behind) while keeping the same UUID (so that aggregators don't get confused). +Also, it should be possible to change the permalink (the Atom `<link>`) of a post (e.g. moving the content and leaving a redirector behind), while keeping the same Atom `<id>` (so that aggregators don't get confused). Ideally UUIDs for [blog posts](/ikiwiki/blog/) should be chosen when the post is created, and frozen permanently by checking them in along with the content. Perhaps ikiwiki's blogging functionality could be hooked up to the [meta plugin](/meta/plugin/), with a new meta keyword (uuid? feed-uuid? atom-uuid?) to achieve this. + +> I've now knocked together a [[patch]], which is in the "force-uuids" branch of git://git.debian.org/git/users/smcv/ikiwiki.git (see also [gitweb](http://git.debian.org/?p=users/smcv/ikiwiki.git;a=shortlog;h=refs/heads/force-uuids)). +> +> I'm not convinced that "uuid" is the best name for this functionality - the `<id>` in an Atom feed can be any URI, and one of the use-cases I have for this functionality in my own blog needs to have its `<id>` set to a URI that is not, in fact, its own address (it was a typo). "id" is a bit arrogant (forcing Atom terminology into a flat namespace!), "atom-id" is slightly misleading because it's also used for RSS... any ideas? +> +> While I was there, I noticed that the quality of the generated Atom/RSS feeds could be improved by making more use of the meta plugin if it's also enabled - would anyone object to me hacking on this some more? +> +> -[smcv](http://smcv.pseudorandom.co.uk/) diff --git a/doc/todo/multiple_repository_support.mdwn b/doc/todo/multiple_repository_support.mdwn new file mode 100644 index 000000000..33d794790 --- /dev/null +++ b/doc/todo/multiple_repository_support.mdwn @@ -0,0 +1,15 @@ +I'd like to be able to use one git repository for my basic website, and +another one for the big files (pictures, videos), and another one for temp +files. This way I'd not bloat the basic repo, and I could toss temp files +up, and throw the temp repo away periodically. + +For this to work really well, ikiwiki would need multiple repository +support. Possibly it could be tied into 'mr'? + +Another thought is that it would be good if ikiwiki could determine the +type of repo a subdirectory is in by itself, eliminating the need to +manually configure it in the setup file. + +--[[Joey]] + +[[tag wishlist]] |