>>>> Which would rule out openid, or other fun forms of auth. And routing all access
>>>> through the CGI sort of defeats the purpose of ikiwiki. --[[Ethan]]
-Also see [[debbug 443346]].
+Also see [[!debbug 443346]].
I am considering giving this a try, implementing it as a module.
Here is how I see it:
> N+1th page that its PageSpec matches is a no-op.
> --[[Joey]]
-[[tag done]]
+[[!tag done]]
Here's a short script for replicating the bug. Just cut and paste this
to a shell, (it will only muck in a new /tmp/ikiwiki-test directory
--[[JoshTriplett]]
-[[tag soc]]
+[[!tag soc]]
[[wishlist]]
--
1.5.2.2
-[[tag patch]]
+[[!tag patch]]
> be a good idea to check out current git master before spending time on
> patches in the future. Thanks for the work anyway.. --[[Joey]]
-[[tag done]]
+[[!tag done]]
--- IkiWiki/Plugin/mdwn.pm.orig 2008-03-08 11:33:50.000000000 +0100
+++ IkiWiki/Plugin/mdwn.pm 2008-03-08 13:37:21.000000000 +0100
-- [[HenrikBrixAndersen]]
-[[tag patch]]
+[[!tag patch]]
-[[tag wishlist]]
-[[tag patch]]
+[[!tag wishlist]]
+[[!tag patch]]
-In our team internal wiki, we wish to impose a policy that all edits must have a comment. Patch in [[debbug 450620]].
+In our team internal wiki, we wish to impose a policy that all edits must have a comment. Patch in [[!debbug 450620]].
> Good idea! I also hate empty commit comments, but I know that it's also a matter
> of human mentality. Of course, you can forbid users to commit empty comments,
[scmbug](http://www.mkgnu.net/?q=scmbug) might help here. --[[JoshTriplett]]
-[[tag soc]]
+[[!tag soc]]
-[[tag wishlist]]
+[[!tag wishlist]]
----
-[[users/arpitjain]]
-[[tag patch]]
+[[!tag patch]]
--[[JasonBlevins]], March 23, 2008 21:41 EDT
-[[tag soc]] [[tag wishlist]]
+[[!tag soc]] [[!tag wishlist]]
In some situations, it makes sense to have the repository in use by ikiwiki reside on a different machine. In that case, one could juggle SSH keys for the `post-update` hook. A better way may be to provide a different `do` parameter handler for the CGI, which would pull new commits to the working clone and refresh the wiki. Then, the remote `post-update` hook could just `wget` that URL. To prevent simple DoS attacks, one might assign a simple password.
-[[tag wishlist]]
+[[!tag wishlist]]
> [[done]] via the pinger and pingee plugins --[[Joey]]
It would be nice to specify a minimum length for the change log for web edits, and if it's only required vs. non-required. I realise this is not going to solve the problem of crap log messages, but it helps guard against accidental submissions which one would have logged. Mediawiki/wikipedia has that option, and I find it a useful reminder. --[[madduck]]
-[[tag wishlist]]
+[[!tag wishlist]]
-[[tag wishlist]]
+[[!tag wishlist]]
A useful item, I think, would be for an option to disable certain pages from being indexed.
--[[Joey]]
-[[tag soc]]
+[[!tag soc]]
-[[tag wishlist]]
+[[!tag wishlist]]
----
Additional details are available [here](http://myweb.unomaha.edu/~ajain/ikiwikigallery.html).
-[[tag patch]]
+[[!tag patch]]
> I'd love to merge this into ikiwiki.
>
-[[tag wishlist patch]]
+[[!tag wishlist patch]]
# Context
See also: [[bugs/tags_base_dir_not_used_when_creating_new_tags]]
-[[tag wishlist]]
+[[!tag wishlist]]
>
> This could also be implemented using a combination of raw inline and meta
> to change the title (add a "redirected from etc." page. This could be done
-> with a plugin. A redirect page would be [[redirect page="newpage"]].
+> with a plugin. A redirect page would be [[!redirect page="newpage"]].
> But then if you click "edit" on this redirect page, you won't be able
> to edit the new page, only the call to redirect.
> --Ethan
-----
-[[tag patch]]
+[[!tag patch]]
This is my second cut at a feature like that requested here.
It can also be found [here](http://ikidev.betacantrips.com/patches/move.patch).
[[plugins/search]] could provide [OpenSearch](http://www.opensearch.org/)
metadata. Various software supports OpenSearch (see the Wikipedia article on
-[[wikipedia OpenSearch]]); in particular, browsers like Firefox and Iceweasel
+[[!wikipedia OpenSearch]]); in particular, browsers like Firefox and Iceweasel
will automatically discover an OpenSearch search and offer it in the search
box.
[[madduck]]: Update: I did try setting `templates` in `ikiwiki.setup` but could not get it to work. Then I found in the code that ikiwiki already checks that dir before the `/usr/share/ikiwiki` one, and tried it again, and now it works... sorry.
-Thus [[taglink done]].
\ No newline at end of file
+Thus [[!taglink done]].
\ No newline at end of file
> I would really like for some additional TMP variables to be present in the rss template as well. For the inline page template, the CTIME TMPL_VAR results in nice phrases like: <q>Posted late Tuesday morning, November 13th, 2007</q>, and it would be neat to let the planet Debian people see that as well :-) Manoj
-[[tag wishlist]]
+[[!tag wishlist]]
> Not that I'm opposed to the idea of a plugin that adds a Raw link
> --[[Joey]]
-[[tag wishlist]]
+[[!tag wishlist]]
-[[tag patch]]
+[[!tag patch]]
Here's my next version of the patch - still a work in progress.
* If you specify an event preprocessor in a post, such as:
- [[event time="2008-06-24"]]
+ [[!event time="2008-06-24"]]
That date will be used instead of the post creation time when displaying the calendar.
>
> IMHO, what you really want is [[Moving_pages]]. :-) --[[Joey]]
-[[tag wishlist]]
+[[!tag wishlist]]
Perhaps ikiwiki should support XML-RPC-based blogging, using the [standard
MetaWeblog protocol](http://www.xmlrpc.com/metaWeblogApi). This would allow
-the use of applets like [[debpkg gnome-blog]] to post to an ikiwiki blog. The
+the use of applets like [[!debpkg gnome-blog]] to post to an ikiwiki blog. The
protocol supports multiple blog names, so one standard URL with page names as
blog names would work. --[[JoshTriplett]]
>> I'd love to see support for this and would be happy to contribute towards a bounty (say US$100) :-). [PmWiki](http://www.pmwiki.org/) has a plugin which [implements this](http://www.pmwiki.org/wiki/Cookbook/XMLRPC) in a way which seems fairly sensible as an end user. --[[AdamShand]]
-[[tag soc]]
+[[!tag soc]]
-[[tag wishlist]]
+[[!tag wishlist]]
-[[tag wishlist]]
+[[!tag wishlist]]
It'd be nice to be allowed to insert tabs into the textarea, as opposed to
having to insert 4-spaces for lists/etc. This would require JavaScript to
-Here is a patch [[tag patch]] to add a *forward*ing functionality
+Here is a patch [[!tag patch]] to add a *forward*ing functionality
to the [[`meta`_plugin|plugins/meta]].
> [[done]], with some changes --[[Joey]]
-[[tag wishlist]]
+[[!tag wishlist]]
An option to have absolute urls in wikilinks instead of relative ones would be useful,
for pages included into other pages out of the wiki rendering process (shtml for example)
The aggregate plugin's handling of http 301 (moved permanently) could be
-improved. Per [[rfc 1945]]:
+improved. Per [[!rfc 1945]]:
> The requested resource has been assigned a new permanent URL
> and any future references to this resource should be done
> "ikiwiki-transition aggregateinternal $setupfile" moves the pages around,
> although it doesn't update the pagespecs (I wouldn't know how...) --[[smcv]]
-[[tag patch done]]
+[[!tag patch done]]
-[[tag wishlist]]
+[[!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.
> I agree that having this as an option is reasonable. Although it would
> take a fair amount of work. --[[Joey]]
-[[tag wishlist]]
+[[!tag wishlist]]
srcdir. This would allow the admin to review them, and manually
add/delete them before they bloat history.
-[[tag wishlist]]
+[[!tag wishlist]]
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]]
I would love to see this as well. -- dato
Together with the ability to have
[[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]],
-this would allow the use of ikiwiki for [[wikipedia literate programming]].
+this would allow the use of ikiwiki for [[!wikipedia literate programming]].
* I have started something along these lines see [[plugins/contrib/sourcehighlight]]. For some reason I started with source-highlight [[DavidBremner]]
our $version='unknown'; # VERSION_AUTOREPLACE done by Makefile, DNE
</pre>
-[[tag patch]]
+[[!tag patch]]
> > I'm sending in an updated package, and have removed the older version you had here.--ManojSrivastava
-[[tag patch]]
+[[!tag patch]]
----
>> wouldn't embed the feed link into `<head>` so that browsers can automatically
>> find it.
-[[tag wishlist]]
+[[!tag wishlist]]
> recognise such commit messages when parsing the logs. Do that and extend
> to the other modules and I'll accept it. --[[Joey]]
-[[tag patch]]
+[[!tag patch]]
<pre>
--- IkiWiki/Rcs/svn.pm (revision 2650)
[[done]] --[[Joey]]
-[[tag patch]]
+[[!tag patch]]
-- [Thomas Schwinge](mailto:tschwinge@gnu.org)
-[[toggle text="show"]]
-[[toggleable text="""
+[[!toggle text="show"]]
+[[!toggleable text="""
# Support for the darcs rcs, <URL:http://darcs.net/>.
# Copyright (C) 2006 Thomas Schwinge <tschwinge@gnu.org>
#
`rcs_commit()` uses backticks instead of `system()`, to prevent darcs' output being sent to the browser and mucking with the HTTP headers (`darcs record` has no --quiet option). And `rcs_recentchanges()` uses regexes rather than parsing darcs' XML output.
-[[toggle text="show" id="bma"]]
-[[toggleable id="bma" text="""
+[[!toggle text="show" id="bma"]]
+[[!toggleable id="bma" text="""
#!/usr/bin/perl
Well, here's my version too. It only does getctime -- using a real XML parser, instead of regexp ugliness -- and maybe recentchanges, but that may be bitrotted, or maybe I never finished it, as I only need the getctime. As for actual commits, I have previously voiced my opinion, that this should be done by the plugin generating a patch bundle, and forwarding it to darcs in some way (`darcs apply` or even email to another host, possibly moderated), instead of the hacky direct modification of a working copy. It could also be faster to getctime in a batch. Just reading in all the changes the first time they're needed, might not be a big improvement in many cases, but if we got a batch request from ikiwiki, we could keep reaing the changes until all the files in this batch request have been met. --[[tuomov]]
-[[toggle text="show" id="tuomov"]]
-[[toggleable id="tuomov" text="""
+[[!toggle text="show" id="tuomov"]]
+[[!toggleable id="tuomov" text="""
<pre>
#!/usr/bin/perl
# Stubs for no revision control.
It's got couple of FIXMEs, and a very site-specific filter for recentchanges. Not sure how to do that better though. I will eventually add web commits, probably of my own (and mention it here).
-[[tag patch]]
+[[!tag patch]]
>>> might move it to the contributed plugins directory as it's a bit
>>> specialised to be included in ikiwiki though. --[[Joey]]
-[[tag patch]]
+[[!tag patch]]
Would each page be its own individual blog? Or its own blog post? To me it seems like an entire wiki can be viewed as a blog, with threaded or unthreaded comments underneath.
-[[tag soc]]
+[[!tag soc]]
-[[inline pages="sandbox/castle/discussion/* and !sandbox/castle/discussion/*/*" rootpage="sandbox/castle/discussion"]]
\ No newline at end of file
+[[!inline pages="sandbox/castle/discussion/* and !sandbox/castle/discussion/*/*" rootpage="sandbox/castle/discussion"]]
\ No newline at end of file
I don't like foo. Have you tried living without foo?
-[[inline pages="sandbox/castle/discussion/Don__39__t_like_foo/*" rootpage="sandbox/castle/discussion/Don__39__t_like_foo"]]
\ No newline at end of file
+[[!inline pages="sandbox/castle/discussion/Don__39__t_like_foo/*" rootpage="sandbox/castle/discussion/Don__39__t_like_foo"]]
\ No newline at end of file
recently fixed [[TODO]] items
-[[inline pages="link(todo/done) and !todo and !*/Discussion" sort=mtime show=10]]
+[[!inline pages="link(todo/done) and !todo and !*/Discussion" sort=mtime show=10]]
-[[tag wishlist]]
+[[!tag wishlist]]
Given that ikiwiki has a suggested use as a tool for developers, I was thinking it might be cool if ikiwiki had [Doxygen](http://www.doxygen.org/) support. I'm not exactly sure how the integration would work. Something along the lines of a plugin to support .dox files would be my first thought. I'd leave generating the documentation from any source files for a separate run of Doxygen - it'd be easier and you probably don't want the source being edited over the web.
qr/(^|\/).svn\//, qr/.arch-ids\//, qr/{arch}\//],
wiki_link_regexp => qr/\[\[(?:([^\]\|]+)\|)?([^\s\]#]+)(?:#([^\s\]]+))?\]\]/,
-[[tag patch]]
+[[!tag patch]]
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
That way I have revision control on that file too. That may be a security concern, but I trust everybody that has svn commit
access and such .htaccess files should not be accessible through wiki cgi. Of course, it could default to 'off'.
-> See [[debbug 447267]] for a patch for this.
+> See [[!debbug 447267]] for a patch for this.
---
and htaccess is for limiting access to some areas of wiki.
It should be off by default of course. --Max
-[[tag patch]]
+[[!tag patch]]
ikiwiki could display a reasonable message to the user, indicating what
they've done wrong.)
-[[tag soc done]]
+[[!tag soc done]]
--Ryan Koppenhaver
## Original patch
-[[tag patch]]
+[[!tag patch]]
<pre>
Index: debian/changelog
and search/sort pages by distance to a given location, as well as
showing page locations on a map (Google Map, OpenStreetMap, etc). -- [[users/vibrog]]
-[[tag wishlist]]
+[[!tag wishlist]]
--[[Joey]]
-[[tag patch done]]
+[[!tag patch done]]
the user or by the script?), it could also set `GIT_COMMITTER_NAME` and
`GIT_COMMITTER_EMAIL` to the same values. --[[JoshTriplett]]
-> See [[debbug 451023]] for a [[patch]] --[[Joey]]
+> See [[!debbug 451023]] for a [[patch]] --[[Joey]]
[[done]]
How about a plugin providing a
[[preprocessor_directive|ikiwiki/preprocessordirective]] to render a
-[[debpkg graphviz]] file as an image via one of the graphviz programs
+[[!debpkg graphviz]] file as an image via one of the graphviz programs
("dot" by default) and include the resulting image on the page, using the
"cmapx" image map format? graphviz files themselves could also render the
same way into an HTML file with the same basename as the graphviz file;
> INSTALLMAN1DIR (though MakeMaker lacks one for man8). I'd prefer not
> adding new variables where MakeMaker already has them. --[[Joey]]
-[[tag patch]]
+[[!tag patch]]
<pre>
below, concerns wanting to use foo/index.mdwn source files and get an
output page name of foo, rather than foo/index. --[[Joey]]
-[[tag patch]]
+[[!tag patch]]
---
> Please resolve lang somewhere reusable rather than within meta plugin: It is certainly usable outside
> the scope of the meta plugin as well. --[[JonasSmedegaard]]
-[[tag wishlist patch plugins/meta translation]]
+[[!tag wishlist patch plugins/meta translation]]
How about a plugin adding a
[[preprocessor_directive|ikiwiki/preprocessordirective]] to render some given LaTeX
and include it in the page? This could either render the LaTeX as a PNG via
-[[debpkg dvipng]] and include the resulting image in the page, or perhaps
+[[!debpkg dvipng]] and include the resulting image in the page, or perhaps
render via [HeVeA](http://pauillac.inria.fr/~maranget/hevea/index.html),
[TeX2page](http://www.ccs.neu.edu/~dorai/tex2page/tex2page-doc.html), or
similar. Useful for mathematics, as well as for stuff like the LaTeX version
>
> --[[Joey]]
-[[tag soc]]
-[[tag wishlist]]
+[[!tag soc]]
+[[!tag wishlist]]
--[[madduck]]
-[[tag wishlist]]
+[[!tag wishlist]]
--[[madduck]]
-[[tag wishlist]]
+[[!tag wishlist]]
except it doesn't have to show up in the page text.
* Recording page licenses.
-[[meta link=done]]
-[[meta title="supporting metadata..."]]
-[[meta author="Joey Hess"]]
-[[meta link="foo.css" rel="stylesheet" type="text/css"]]
+[[!meta link=done]]
+[[!meta title="supporting metadata..."]]
+[[!meta author="Joey Hess"]]
+[[!meta link="foo.css" rel="stylesheet" type="text/css"]]
[[todo/done]]
# Allow generating feeds even if not generated by default?
#allowrss => 1,
-[[tag patch]]
+[[!tag patch]]
> Hmm, recentchanges is just a blog. Of course the word "blog" is perhaps
> being used in too broad a sense here, since it tends to imply personal
something like this:
<pre>
-[[missingparents pages="posts/* and !posts/*/*" generate="""[[template id=year text="$page"]]"""]]
-[[missingparents pages="posts/*/* and !posts/*/*/*" generate="""[[template id=month text="$page"]]"""]]
-[[missingparents pages="posts/*/*/* and !posts/*/*/*/*" generate="""[[template id=day text="$page"]]"""]]
+[[!missingparents pages="posts/* and !posts/*/*" generate="""[[template id=year text="$page"]]"""]]
+[[!missingparents pages="posts/*/* and !posts/*/*/*" generate="""[[template id=month text="$page"]]"""]]
+[[!missingparents pages="posts/*/*/* and !posts/*/*/*/*" generate="""[[template id=day text="$page"]]"""]]
</pre>
And it scans the whole wiki for pages that match the pagespecs but are missing
+ my %params=@_;
+
+ if (! defined $params{pages} || ! defined $params{generate}) {
-+ return "[[missingparents ".gettext("missing pages or generate parameter")."]]";
++ return "[[!missingparents ".gettext("missing pages or generate parameter")."]]";
+ }
+
+ push @pagespecs, \%params;
my $page=shift;
</pre>
-[[tag patch]]
+[[!tag patch]]
+
+</div>
-[[tag patch]]
+[[!tag patch]]
> Unfortunately, the inlinepage content passes through markdown, and markdown
> gets confused by these nested div's and puts p's around one of them, generating
>> alternatives is always a good thing and perhaps, the fact that pandoc can make markdown->LaTeX
>> conversion may lead to new possibilities. --[[Roktas]]
->>> I confirm that this ([[debbug 405058]]) has just been fixed in markdown
+>>> I confirm that this ([[!debbug 405058]]) has just been fixed in markdown
>>> [`1.0.2b7`](http://packages.debian.org/experimental/web/markdown) (BTW, thanks to your bug
>>> report Joey). FYI, I've observed some performance drop with `1.0.2b7` compared to `1.0.1`,
>>> especially noticable with big files. This was also confirmed by someone else, for example,
--[[bma]]
-[[tag wishlist]]
+[[!tag wishlist]]
--[[Joey]]
-[[tag wishlist]]
+[[!tag wishlist]]
+1
</pre>
-[[tag patch]]
+[[!tag patch]]
> This looks really interesting. It reminds me of XPath and its conditionals.
> Those might actually work well adapted to pagespecs. For instance, to write
>>> Sure, a plugin is just a perl library so can easily be packaged
>>> separately.
-[[tag wishlist]]
+[[!tag wishlist]]
-[[tag wishlist]]
+[[!tag wishlist]]
For sending out password reminder emails, the [[plugins/passwordauth]] plugin currently uses
the *[Mail::Sendmail](http://search.cpan.org/perldoc?Mail::Sendmail)* module.
--[[tschwinge]]
-> One that is in Debian is [[cpan Email::Send]], which can do SMTP and
+> One that is in Debian is [[!cpan Email::Send]], which can do SMTP and
> sendmail and some other methods and falls back through methods until one
> succeeds. I haven't tried to use it but it looks like a feasable
> candidate.
OK, so I'll have a look at replacing all email handling with *Email::Send*.
-[[tag patch]]
+[[!tag patch]]
*<http://www.thomas.schwinge.homeip.net/tmp/ikiwiki-sendmail.patch>*
Remaining TODOs:
* Resolve TODOs as denoted inside the patch.
- * Is it worthwhile to use and depend on [[cpan Return::Value]]
+ * Is it worthwhile to use and depend on [[!cpan Return::Value]]
just for this bit of functionality?
* Debian news file.
* ikiwiki news file.
> (master language + translations) support. Expect news from me on
> this front in the next weeks. --[[intrigeri]]
-[[tag patch done]]
+[[!tag patch done]]
>> can use that as an alternative. I'm happy to chat about this, ping me..
>> --[sm](http://joyful.com)
-[[tag wishlist]]
+[[!tag wishlist]]
It would rock if I could view diffs from the web without going via feeds. I envision toggle-style buttons on the recentchanges page, or just links to the CGI, which then displays the diff... --[[madduck]]
-[[tag wishlist]]
+[[!tag wishlist]]
>
-[[tag patch]]
+[[!tag patch]]
> [[done]], although I left off the escapeHTML thing which seems to be in
> your patch by accident.
<http://www.reedmedia.net/~reed/tmp-sfhkcjkfrfh/rcs.pm>
-[[tag patch]]
+[[!tag patch]]
> Clearly needs some cleanup and perhaps some of the missing stubs
> implemented, before it can be included into ikiwiki.
— NicolasLimare
-[[tag wishlist]]
+[[!tag wishlist]]
-[[tag wishlist]]
+[[!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
>
> -- [[JoshTriplett]]
-[[tag wishlist]]
+[[!tag wishlist]]
Here [is][1] a link.
- [1]: [[l a_page_in_the_wiki]]
+ [1]: [[!l a_page_in_the_wiki]]
- Obviously [this]([[l another_page]]) also works, although the syntax is quite cumbersome.
+ Obviously [this]([[!l another_page]]) also works, although the syntax is quite cumbersome.
So that the 'l' plugin inserts the location the page there, and markdown does the rest. My plugin currently fails if it can't find the page, as that is sufficient for my needs. Differing colouring for non-existing pages is not doable in a straightforward manner with this approach.
>
> --[[Joey]]
-[[tag wishlist]]
+[[!tag wishlist]]
of very simple text parsing or regex application, to make it possible to write
shortcuts like these:
- [[mmlist listname@lists.example.org]] -> <listname@example.org> ([mailman page] (http://lists.example.org/mailman/listinfo/listname)
- [[debcl packagename]] -> [packagename changelog](http://packages.debian.org/changelogs/pool/main/p/packagename/current/changelog)
+ [[!mmlist listname@lists.example.org]] -> <listname@example.org> ([mailman page] (http://lists.example.org/mailman/listinfo/listname)
+ [[!debcl packagename]] -> [packagename changelog](http://packages.debian.org/changelogs/pool/main/p/packagename/current/changelog)
For shortcut definitions, a `match` parameter could supply a regex, and then the `url` and `desc` parameters could make use of the named or numbered groups from the match.
see in action in the preformatted patch below. So I don't see why the
default style sheet should do this. --[[Joey]]
-[[tag patch]]
+[[!tag patch]]
<pre>
diff --git a/basewiki/style.css b/basewiki/style.css
-I think it would be useful for ikiwiki to support [[debpkg sdf]] input,
+I think it would be useful for ikiwiki to support [[!debpkg sdf]] input,
which can be converted and rendered to many formats.
I should add, however, that SDF allows executing arbitrary perl code
from its documents; which means some sanitization would need to occur
before the document is fed to sdf.
--[[JeremieKoenig]]
-[[tag wishlist]]
+[[!tag wishlist]]
What I ended up doing is write something like this to the page:
- [[blogcomment from="""Username""" timestamp="""12345""" subject="""Some text""" text="""the text of the comment"""]]
+ [[!blogcomment from="""Username""" timestamp="""12345""" subject="""Some text""" text="""the text of the comment"""]]
Each comment is processed to something like this:
$cgi->param('comments') : '';
my $comment=$cgi->param('blogcomment');
- $content.=qq{[[blogcomment from="""$name""" timestamp="""$timestamp""" subject="""$subject""" text="""$comment"""]]\n\n};
+ $content.=qq{[[!blogcomment from="""$name""" timestamp="""$timestamp""" subject="""$subject""" text="""$comment"""]]\n\n};
$content=~s/\n/\r\n/g;
$form->field(name => "editcontent", value => $content, force => 1);
} # }}}
return $ctime;
} #}}}
-[[tag patch done]]
+[[!tag patch done]]
* Need to get post commit hook code working.
* Need some example urls for web based diffs.
-[[tag rcs/tla]]
+[[!tag rcs/tla]]
A simple plugin to allow per-page customization of a template by passing paramaters to HTML::Template. For those times when a whole pagetemplate is too much work. --Ethan
-[[tags patch]]
+[[!tags patch]]
#!/usr/bin/perl
package IkiWiki::Plugin::tmplvars;
It would be nice if one could set the initial state of the toggleable area.
--[[[rdennis]]
-[[tag plugins/toggle]]
+[[!tag plugins/toggle]]
[[done]]
--[[madduck]]
-[[tags wishlist patch]]
+[[!tags wishlist patch]]
The [[typography_plugin|plugins/typography]] could support configuration of
-which translations to make. [[cpan Text::Typography]] supports fine-grained
+which translations to make. [[!cpan Text::Typography]] supports fine-grained
control of which translations to make, so [[plugins/typography]] just needs to
expose this somehow. --[[JoshTriplett]]
[[cstamas]]
-[[tag wishlist patch]]
+[[!tag wishlist patch]]
+
</pre>
-[[tag patch]]
+[[!tag patch]]
--[[AdamShand]]
-[[tag wishlist]]
+[[!tag wishlist]]
problem. According to the developers, it is possible to do that, and start
off in WikiText mode.
-[[tag soc]]
+[[!tag soc]]
-[[tag wishlist]]
+[[!tag wishlist]]
-[[tag patch]]
+[[!tag patch]]
Project IkiWiki::WIKIWYG v1.6 - <http://ikiwiki.xbaud.com/>
===========================================================
projects / ikiwiki.git / commitdiff