This is ikiwiki's bug list. Link bugs to [[bugs/done]] when done.
-Also see the [Debian bugs](http://bugs.debian.org/ikiwiki).
+Also see the [Debian bugs](http://bugs.debian.org/ikiwiki), and the
+[[TODO]] page.
[[inline pages="bugs/* and !bugs/done and !bugs/discussion and
!link(bugs/done) and !bugs/*/*"
1. Make command-line arguments override settings in the setup file
> This is difficult to do, since reading a setup file replaces values for
-> config items with the values in the setup file.
+> config items with the values in the setup file. Also, when you say
+> --setup foo, you're asking ikiwiki to set up the wiki using the
+> comnfiguration in file foo. Which is what it does.
2. Comment out all settings in the example setup file that are simply
setting options to their default values. That way, the file will
work for these settings while they remain commented out.
> I've done that, I also fixed some issues with --verbose handling earlier.
+> I'm pretty sure that those fixes fix the real issue, so calling this
+> [[done]].
> --[[Joey]]
+I am serving notice that I am starting work on a calendar plugin inspired by Blosxom's calendar plugin. The current plan is to create a plugin that looks through all the source files matching a certain pagespec, and optionally spit out a month view for the specified month (default to current), or spit out a year view for a given year (defaulting to the current year), of a list of year with posts in them. The output would be a table, with the same CSS directives that the Blosxom plugin used to use (so that I can just reuse my css file). The links would be created to a $config{archivedir}/$year or $config{archivedir}/$year-$month file, which can just have
+
+ \[[inline pages="blog/* and !*/Discussion and creation_year($year) and creation_month($month)" rss="no" atom="no" show="0"]]
+
+or some thing to generate a archive of postings.
+
+Roland Mas suggested a separate cron job to generate these archive indices automatically, but that is another thread.
+
+ManojSrivastava
+
This plugin is inspired by the calendar plugin for Blosxom, but derivesno code from it. This plugin is essentially a fancy front end to archives of previous pages, usually used for blogs. It can produce a calendar for a given month, or a list of months for a given year. To invoke the calendar, just use the preprocessor directive:
\[[calendar ]]
--[[JoshTriplett]]
[[tag soc]]
+
+[[wishlist]]
> is that it provides a GUI for editing with widets for italics, etc,
> compared to showdown which still leaves input in markdown and seems more
> geared to a fast preview of the html. --[[Joey]]
+
+> Since we have semi-working wikiwgy and it's better, I'm considering this
+> todo item as [[done]] or rather, will-not-be-done..
[scmbug](http://www.mkgnu.net/?q=scmbug) might help here. --[[JoshTriplett]]
[[tag soc]]
+
+[[tag wishlist]]
>> By Google BTS, do you mean the issue tracker in the Google code
>> project hosting?
>>
->> --Teemu
\ No newline at end of file
+>> --Teemu
+
+[[wishlist]]
--[[JoshTriplett]]
-[[tag soc]]
+[[tag soc]] [[tag wishlist]]
+++ /dev/null
-I am serving notice that I am starting work on a calendar plugin inspired by Blosxom's calendar plugin. The current plan is to create a plugin that looks through all the source files matching a certain pagespec, and optionally spit out a month view for the specified month (default to current), or spit out a year view for a given year (defaulting to the current year), of a list of year with posts in them. The output would be a table, with the same CSS directives that the Blosxom plugin used to use (so that I can just reuse my css file). The links would be created to a $config{archivedir}/$year or $config{archivedir}/$year-$month file, which can just have
-
- \[[inline pages="blog/* and !*/Discussion and creation_year($year) and creation_month($month)" rss="no" atom="no" show="0"]]
-
-or some thing to generate a archive of postings.
-
-Roland Mas suggested a separate cron job to generate these archive indices automatically, but that is another thread.
-
-ManojSrivastava
\ No newline at end of file
ikiwiki could support rendering and editing po files via the web. Run against
a software repository, ikiwiki would make for an interesting
-translation-management tool. --[[JoshTriplett]]
\ No newline at end of file
+translation-management tool. --[[JoshTriplett]]
+
+[[wishlist]]
A simple script should be able to poll for the irc topic and update a page,
then run ikiwiki -refresh to update the wiki. No need to put that in
ikiwiki or a plugin, though. --[[Joey]]
+
+[[wishlist]]
That looks pretty good.. putting the passwordauth part in a box of its own with
the submit buttons I don't know how to do.
+I'm happy enough with what we have now though, with the above improvements.
+Hope you are too, as I'm calling this [[done]]..
+
--[[Joey]]
contain the wiki title from `ikiwiki.setup`.
--[[JoshTriplett]]
+
+[[wishlist]]
ikiwiki could provide one or more plugins that provide "add to" links for popular feed readers, such as Google Reader, Bloglines, My Yahoo!, or Netvibes.
Potentially less useful given an implementation of [[todo/integration_with_Firefox_and_Iceweasel_feed_subscription_mechanism]].
---[[JoshTriplett]]
\ No newline at end of file
+--[[JoshTriplett]]
+
+[[wishlist]]
>> 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 wishlist]]
We might want some kind of abbreviation and acronym plugin. --[[JoshTriplett]]
- * Not sure if this is what you mean, but I'd love a way to make works which match existing page names automatically like (eg. if there is a page called "MySQL" then any time the word MySQL is mentioned it should become a link to that page). -- [[AdamShand]]
\ No newline at end of file
+ * Not sure if this is what you mean, but I'd love a way to make works which match existing page names automatically like (eg. if there is a page called "MySQL" then any time the word MySQL is mentioned it should become a link to that page). -- [[AdamShand]]
+
+[[wishlist]]
> I agree that having this as an option is reasonable. Although it would
> take a fair amount of work. --[[Joey]]
+
+[[tag wishlist]]
-Wishlist: optionally use the [[plugins/contrib/syntax]] plugin automatically on source code files in the repository with recognized extensions or shebangs, and render them as though they consisted of an [[.mdwn|markdown]] page containing nothing but a single call to the syntax plugin with the file contents as the text argument and the recognized type as the type argument.
+[[Wishlist]]: optionally use the [[plugins/contrib/syntax]] plugin automatically on source code files in the repository with recognized extensions or shebangs, and render them as though they consisted of an [[.mdwn|markdown]] page containing nothing but a single call to the syntax plugin with the file contents as the text argument and the recognized type as the type argument.
-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]].
\ No newline at end of file
+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]].
described at [[todo/fileupload]].
--[[JoshTriplett]]
+
+[[wishlist]]
>> That wouldn't use the same style for the RSS and Atom links, and it
>> wouldn't embed the feed link into `<head>` so that browsers can automatically
>> find it.
+
+[[tag wishlist]]
Should be doable w/o touching a single line of code, just
editing the [[wikitemplates]] and/or editing [[style.css]].
+
+[[done]] ([[css_market]] ..)
<ikihacker> \[[setup]]
<ikibot> http://ikiwiki.info/setup.html: "This tutorial will walk you through setting up a wiki with ikiwiki. ..."
---[[JoshTriplett]]
\ No newline at end of file
+--[[JoshTriplett]]
+
+[[wishlist]]
on their site. We could then provide the manual configuration settings as a
[[tip|tips]], and perhaps provide an extension or other mechanism to set them
automatically. --[[JoshTriplett]]
+
+[[wishlist]]
-----
[[tag soc]]
+
+[[tag wishlist]]
However, that also seems like potential overkill, and less important than the
basic functionality of `linktitle`.
--[[JoshTriplett]]
+
+[[wishlist]]
ikiwiki could support manpages (or general groff input files) and convert them
to HTML. --[[JoshTriplett]]
+
+[[wishlist]]
Hmm, I think the pagetemplate hook should allow one to get close enough to
this in a plugin now.
+
+See also: [[Allow_per-page_template_selection]] -- same thing, really.
* Password protection?
-- [[JoshTriplett]]
+
+[[wishlist]]
-Ikiwiki could optionally use rel=nofollow on all external links, or on all those from a configurable subset of pages (such as */discussion if using [[plugins/opendiscussion]]). --[[JoshTriplett]]
\ No newline at end of file
+Ikiwiki could optionally use rel=nofollow on all external links, or on all those from a configurable subset of pages (such as */discussion if using [[plugins/opendiscussion]]). --[[JoshTriplett]]
+
+> This is tricky, and would need a html parser, since external links can be
+> added in lots of ways including raw in markdown. --[[Joey]]
-How about a direct link from the page header to the source of the latest version, to avoid the need to either use edit or navigate to the current version via the history link?
\ No newline at end of file
+How about a direct link from the page header to the source of the latest version, to avoid the need to either use edit or navigate to the current version via the history link?
----
-Firefox 2 (or whatever it will be in Debian) does this for you, and then there's the mozex extension
\ No newline at end of file
+Firefox 2 (or whatever it will be in Debian) does this for you, and then there's the mozex extension
+
+> Yeah, IMHO gecko's spellchecker nailed this. Spellcheckers server-side
+> are now passe. Calling this [[done]] --[[Joey]]
* We could support editing SVGs via the web interface. SVG can contain unsafe content such as scripting, so we would need to whitelist safe markup.
---[[JoshTriplett]]
\ No newline at end of file
+--[[JoshTriplett]]
+
+[[wishlist]]
This is one good argument for changing ikiwiki so that pages are all
dir/index.html, then a link to just "dir" works.
+
+ So this could be implemented now for userdirs wikis..
-We could support web-based image editing, using something like [Snipshot](http://snipshot.com/). Several comparisons of web-based image editors exist; we would need to choose which one(s) to support. --[[JoshTriplett]]
\ No newline at end of file
+We could support web-based image editing, using something like [Snipshot](http://snipshot.com/). Several comparisons of web-based image editors exist; we would need to choose which one(s) to support. --[[JoshTriplett]]
+
+[[wishlist]]
MoinMoin has a simple implementation of this, [click here to see an example](http://www.spack.org/wiki/SandBox?action=edit&editor=text).
---[[AdamShand]]
\ No newline at end of file
+--[[AdamShand]]
+
+[[tag wishlist]]
-Wishlist item: I'd love to see the ability to optionally switch back to wiki syntax within the comments of code pretty-printed with the [[plugins/contrib/syntax]] plugin. This would allow the use of links and formatting in comments.
\ No newline at end of file
+[[Wishlist]] item: I'd love to see the ability to optionally switch back to wiki syntax within the comments of code pretty-printed with the [[plugins/contrib/syntax]] plugin. This would allow the use of links and formatting in comments.
off in WikiText mode.
[[tag soc]]
+
+[[tag wishlist]]
projects / ikiwiki.git / commitdiff