[ Joey Hess ]
* template: Add support for a BASENAME variable.
* Fixes creation of pages when clicking on WikiLinks starting with "/".
+ * Change deb dependencies to list Text::Markdown before markdown, since
+ the former, while slower, has a much better html parser that avoids
+ numerous bugs.
-- Josh Triplett <josh@freedesktop.org> Wed, 09 Jul 2008 21:30:33 -0700
Section: web
Priority: optional
Build-Depends: perl, debhelper (>= 5)
-Build-Depends-Indep: dpkg-dev (>= 1.9.0), libxml-simple-perl, markdown | libtext-markdown-perl, libtimedate-perl, libhtml-template-perl, libhtml-scrubber-perl, wdg-html-validator, libhtml-parser-perl, liburi-perl
+Build-Depends-Indep: dpkg-dev (>= 1.9.0), libxml-simple-perl, libtext-markdown-perl | markdown, libtimedate-perl, libhtml-template-perl, libhtml-scrubber-perl, wdg-html-validator, libhtml-parser-perl, liburi-perl
Maintainer: Joey Hess <joeyh@debian.org>
Uploaders: Joey Hess <joeyh@debian.org>, Josh Triplett <josh@freedesktop.org>
Standards-Version: 3.8.0
-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]]
## 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
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
-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
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
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
[[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).
blather!!
+Testing an edit in the sandbox.
+
----
Here's a paragraph.
<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.)
--- /dev/null
+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
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/)
--- /dev/null
+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]]
projects / ikiwiki.git / commitdiff