Merge branch 'master' of ssh://git.kitenet.net/srv/git/ikiwiki.info
Joey Hess
commit
08cb5f7bad
|
|
@ -0,0 +1,24 @@
|
|||
I am trying to add a post address to a document:
|
||||
|
||||
<address>
|
||||
First line<br/>
|
||||
Second line
|
||||
</address>
|
||||
|
||||
As you can see, the `<br/>` is being removed. I disabled [[htmlscrubber]], but that was not it. The [markdown Dingus](http://daringfireball.net/projects/markdown/dingus) on its homepage processes the inline HTML just fine.
|
||||
|
||||
I tried searching the web and wiki but could not find any information on why <br/> would be removed.
|
||||
|
||||
> It does work if you use `<br />`:
|
||||
>
|
||||
> First line<br />
|
||||
> Second line
|
||||
>
|
||||
> Or, as we've just been told in #ikiwiki: put two spaces at the end of the first line.
|
||||
>
|
||||
> First line
|
||||
> Second line
|
||||
>
|
||||
> --[[tschwinge]]
|
||||
|
||||
> > `<br/>` is also valid, so this is a bug still. --[[madduck]]
|
||||
|
|
@ -19,4 +19,13 @@ which is exactly the same regular expression drawn out as a constant. It appear
|
|||
> checking in the debian package. You can do the same by building ikiwiki
|
||||
> with NOTAINT=1. :-( --[[Joey]]
|
||||
|
||||
[[tag done]]
|
||||
----------------
|
||||
Continuing to dig into the problem I reported, it may not be taint after all. Running strings on the ikiwiki.cgi wrapper, I see stuff like:
|
||||
|
||||
'wiki_file_regexp' => bless( do{\(my $o = undef)}, 'Regexp' )
|
||||
|
||||
without any payload of the actual regexp, and that would also certainly also have the observed effect of the regexps being completely broken while running in CGI mode. This seems to implicate Data::Dumper (2.101). After upgrading Data::Dumper to 2.121 I get:
|
||||
|
||||
'wiki_file_regexp' => qr/(?-xism:(^[-[:alnum:]_.:\/+]+$))/
|
||||
|
||||
This would call for at most an installation prerequisite of Data::Dumper >= 1.121. A look at the module's changelog shows that no intervening versions were actually released, so 1.121 would be the minimal good one.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[template id=plugin name=pagestate author="Enrico Zini"]]
|
||||
[[template id=plugin name=pagestats author="Enrico Zini"]]
|
||||
[[tag type/meta type/tags]]
|
||||
|
||||
This plugin can generate stats about how pages link to each other. It can
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ Bulleted list
|
|||
* three
|
||||
* four
|
||||
* five
|
||||
|
||||
* six
|
||||
----
|
||||
|
||||
[[template id=note text="this is generated by the [[plugins/haiku]] plugin"]]
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
hehe
|
||||
hehe hohoho
|
||||
|
|
|
|||
|
|
@ -0,0 +1,3 @@
|
|||
[[tag wishlist]]
|
||||
|
||||
It would be cool if the CGI could be used to render dynamic pages. For instance, I might want to create a page with a `\[[map]]` according to a [[pagespec]] to be passed in the query string, instead of creating/hardcoding all possible pagespecs I might want to call.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
It would be great if I could tell ikiwiki to automatically instantiate pages for each tag, according to a template, especially when `$tagbase` is set.
|
||||
|
||||
Tags are mainly specific to the object to which they’re stuck. However, I often use them the other way around, too: as concepts. And sometimes I’d like to see all pages related to a given concept (“tagged with a given tag”). The only way to do this with ikiwiki is to instantiate a page for each tag and slap a map on it. This is quite tedious and I’d really love to see Ikiwiki do so by default for all tags.
|
||||
|
||||
Also see: <http://madduck.net/blog/2008.01.06:new-blog/> and <http://users.itk.ppke.hu/~cstamas/code/ikiwiki/autocreatetagpage/>
|
||||
|
||||
[[tag wishlist]]
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
[[tag wishlist]]
|
||||
|
||||
HTML::Template is an okay templating kit, but it lacks a lot of powerful
|
||||
features and thus makes it rather hard to give an ikiwiki site a consistent
|
||||
look. If you browse the templates provided in the tarball, you'll notice that
|
||||
more than one of them contain the `<html>` tag, which is unnecessary.
|
||||
|
||||
Maybe it's just me, I also find HTML::Template cumbersome to use, due in part
|
||||
to its use of capital letters.
|
||||
|
||||
Finally, the software seems unmaintained: the mailing list and searchable
|
||||
archives linked from
|
||||
<http://html-template.sourceforge.net/html_template.html#frequently%20asked%20questions>
|
||||
are broken and the author has not replied to my query in months.
|
||||
|
||||
I would love to see ikiwiki use the [Template
|
||||
Toolkit](http://template-toolkit.org/) as templating engine.
|
||||
|
||||
One major reason for TT is its use of slots, a concept I first encountered
|
||||
with Zope Page Templates and never wanted to miss it again. Let me quickly
|
||||
illustrate, using the HTML::Template syntax for simplicity. Traditionally,
|
||||
templating is done with includes:
|
||||
|
||||
Page A Page B
|
||||
<TMPL_INCLUDE header> <TMPL_INCLUDE header>
|
||||
this is page A this is page B
|
||||
<TMPL_INCLUDE footer> <TMPL_INCLUDE footer>
|
||||
|
||||
This involves four pages, and if you mistype "footer" on page B,
|
||||
it'll be broken in potentially subtle ways.
|
||||
|
||||
Now look at the approach with slots:
|
||||
|
||||
MainTemplate
|
||||
This is the header
|
||||
<TMPL_SLOT content>
|
||||
This is the footer
|
||||
|
||||
Page A Page B
|
||||
<TMPL_USE MainTemplate> <TMPL_USE MainTemplate>
|
||||
<TMPL_FILL content> <TMPL_FILL content>
|
||||
This is page A This is page B
|
||||
</TMPL_FILL> </TMPL_FILL>
|
||||
</TMPL_USE> </TMPL_USE>
|
||||
|
||||
As soon as you think about more structure pages with various slots
|
||||
to fill, I am sure you can see the appeal of that approach. If not,
|
||||
here is some more documentation: <http://wiki.zope.org/ZPT/METALSpecification11>
|
||||
|
||||
I would be glad to volunteer time to make this switch happen, such as rewrite
|
||||
the templates. I'd prefer not having to touch Perl though...
|
||||
Loading…
Reference in New Issue