Welcome to ikiwiki's todo list. Link items to done when done.
Wikiwyg is a WYSIWYG editor written in javascript for wikis. It allows editing in a gui or in wikitext and converts edits back to wiki format to be saved to the wiki.
It would be awesome to use this in ikiwiki, but to take full advantage of it with ikiwiki, it would need to know about MarkDown. Wikiwyg does allow defining the text that is stuck on each side of a given html element to make it wikified, for example, it can add "# " for a h1, "[[" and "]]" for a link, etc. This seems easily doable.
The other thing that would need doing is a saveChanges
function would
need to be implemented that saves the text back to ikiwiki.
http://svn.wikiwyg.net/code/trunk/wikiwyg/share/Kwiki/lib/Wikiwyg/Kwiki.js
seems like a good starting point for building a submit form on the fly.
One other problem: Wikiwyg works by parsing html from a div, turning it back into the wiki markup, and editing/saving that. That seems to assume that there's a way of parsing a page's html and getting back to the underlying wiki markup, which is not always the case in ikiwiki. Unless there's some other way to feed it the actual source for a page, this seems like a problem. According to the developers, it is possible to do that, and start off in WikiText mode.
Posted Mon Nov 27 23:24:11 2006- Need to get post commit hook working (or an example of how to use it.)
- rcs_notify is not implemented
- Is the code sufficiently robust? It just warns when mercurial fails.
Suggestions of ideas for plugins:
- list of registered users - tricky because it sorta calls for a way to rebuild the page when a new user is registered. Might be better as a cgi?
sigs ?
Support RecentChanges as a regular page containing a plugin that updates each time there is a change, and statically builds the recent changes list. (Would this be too expensive/inflexible? There might be other ways to do it as a plugin, like making all links to RecentChanges link to the cgi and have the cgi render it on demand.)
Or using an iframe to inline the cgi, although firefox seems to render that nastily with nested scroll bars.
For PlaceWiki I want to be able to do some custom plugins, including one that links together subpages about the same place created by different users. This seems to call for a plugin that applies to every page w/o any specific marker being used, and pre-or-post-processes the full page content. It also needs to update pages when related pages are added, so it needs to register dependencies pre-emptively between pages, or something. It's possible that this is a special case of backlinks and is best implemented by making backlinks a plugin somehow. --Joey
interwiki links
random page (cgi plugin; how to link to it easily?)
All the kinds of plugins that blogging software has is also a possibility:
Blog post calendar
How about an event calendar. Events could be sub-pages with an embedded code to detail recurrance and/or event date/time
Ikiwiki has already been optimised a lot, however..
Look at splitting up CGI.pm. But note that too much splitting can slow perl down.
The backlinks calculation code is still O(N^2) on the number of pages. If backlinks info were stored in the index file, it would go down to constant time for iterative builds, though still N^2 for rebuilds.
Perhaps ikiwiki should support XML-RPC-baed blogging, using the standard MetaWeblog protocol. This would allow the use of applets like 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.
Posted Tue Nov 21 15:22:36 2006This would be a great thing to add a plugin for. (Probably using the cgi hook to let ikiwiki act as an RPC server. --Joey
Currently, the page title (either the name of the page or the title specified with [[meta title="..."]]
) shows up in a <div class="header">
. I tend to follow the w3c guideline recommending the use of h1 for the title; for this purpose, how about an option to make the page title an <h1 class="header">
, and shift the markdown headings down by one (making # an h2, ## an h3, etc; or alternatively making # equivalent to [[meta title="..."]]
)?
Posted Tue Nov 21 15:21:49 2006The reason I don't use a h1 for the navbar is that while it incorporates the page title, it's not just a page title, it has the links to parent pages. I also don't want to get in the business of munging up markdown's semantics. This way, # is reserved for h1 if you choose to use headers in your page. --Joey
Wishlist: optionally use the 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 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, this would allow the use of ikiwiki for literate programming.
Posted Mon Nov 20 00:22:59 2006Wishlist item: I'd love to see the ability to optionally switch back to wiki syntax within the comments of code pretty-printed with the syntax plugin. This would allow the use of links and formatting in comments.
Posted Mon Nov 20 00:22:59 2006I thought I'd draw attention to a desire of mine for ikiwiki. I'm no power-user, and mostly I do fairly simple stuff with my wiki.
However, I would like the ability (now) to rename/move/delete pages. As part of having a genealogy wiki, I've put name and dates of birth/death as part of the title of each article (so to avoid cases where people have the same name, but are children/cousins/etc of others with that name). However, some of this information changes. For instance, I didn't know a date of death and now I do, or I had it wrong originally, or it turns out someone is still alive I didn't know about. All of these cases leave me with bad article titles.
So, I can go ahead and move the file to a new page with the correct info, orphan that page, provide a link for the new page if desired, and otherwise ignore that page. But then, it clutters up the wiki and serves no useful purpose.
Anyway to consider implementing rename/move/delete ? I certainly lack the skills to appreciate what this would entail, but feel free to comment if it appears impossible, and then I'll go back to the aforementioned workaround. I would prefer simple rename, however.
Thanks again to Joey for putting ikiwiki together. I love the program.
Kyle=
The MediaWiki moving/renaming mechanism is pretty nice. It's easy to get a list of pages that point to the current page. When renaming a page it sticks a forwarding page in the original place. The larger the size of the wiki the more important organization tools become.
I see the need for:
- a new type of file to represent a forwarding page
- a rename tool that can
- move the existing page to the new name
- optionally drop a forwarding page
- optionally rewrite incoming links to the new location
Brad
Posted Sat Nov 11 02:34:29 2006Feature idea: I'd like to be able to tag pages in an ikiwiki blog with a publication date, and have the option of building a blog that excludes publication dates in the future. (meta pubdate= ?)
I'm using ikiwiki on git for a "tip of the day" RSS feed, and I'd like to be able to queue up a bunch of items instead of literally putting in one tip per day. In the future I think this will come in handy for other Mainstream Media-oriented requirements such as "embargo dates" and "editor on vacation".
Posted Wed Nov 8 20:44:18 2006The problem with implementing a feature like this is that, since ikwiiki is a wiki compiler, if something causes content to change based on the date, then the wiki needs to be rebuilt periodically. So you'd need a cron job or something.
Implemeting this feature probably needs plugin dependency calulation to be implemented. --Joey
ikiwiki currently stores some key data in .ikiwiki/index. Some plugins need a way to store additional data, and ideally it would be something managed by ikiwiki instead of ad-hoc because:
- consistency is good
- ikiwiki knows when a page is removed and can stop storing data for that page; plugins have to go to some lengths to track that and remove their data
- it's generally too much code and work to maintain a separate data store
The aggregate plugin is a use-case: of 324 lines, 70 are data storage and another 10 handle deletion. Also, it's able to use a format very like ikiwiki's, but it does need to store some lists in there, which complicates it some and means that a very naive translation between a big per-page hash and the .index won't be good enough.
The current ikiwiki index format is not very flexible, although it is at least fairly easy and inexpensive to parse as well as hand-edit.
Would this do: ?
- Plugins can register savestate and loadstate hooks. The hook id is the key used in the index file that the hook handles.
- loadstate hooks are called and passed a list of all values for a page that for the registered key, and the page name, and should store the data somewhere
- savestate hooks are called and passed a page, and should return a list of all values for that key for that page
- If they need anything more complex than a list of values, they will need to encode it somehow in the list.
Hmm, that's potentially a lot of function calls per page eave load/save
though.. For less function calls, only call each hook once per load/save,
and it is passed/returns a big hash of pages and the values for each page.
(Which probably means %state=@_
for load and return %state
for save.)
It may also be better to just punt on lists, and require plugins that need
even lists to encode them. Especially since in many cases, join(" ", @list)
will do. Er hmm, if I do that though, I'm actually back to a big global
%page_data that plugins can just toss data into, arn't I? So maybe that's
%the right approach after all, hmm.. Except that needing to decode/encode list
data all the time when using it would quite suck, so no, let's not do that.
Note that for the aggregate plugin to use this, it will need some changes:
- guid data will need to be stored as part of the data for the page that was aggregated from that guid. Except, expired pages don't exit, but still have guid data to store. Hmm.
- All feeds will need to be marked as removable in loadstate, and only unmarked if seen in preprocess. Then savestate will need to not only remove any feeds still marked as such, but do the unlinking of pages aggregated from them too.
If I do this, I might as well also:
- Change the link= link= stuff to just links=link+link etc.
- Change the delimiter from space to comma; commas are rare in index files, so less ugly escaped delimiters to deal with.
Admins need the ability to block IP ranges. They can already ban users.
Posted Sat Oct 28 00:00:32 2006Why isn't it statically-genereated, but generated dynamically by CGI? It seems like it could be beneficial to have it rendered in the post-commit hook, just like everything else in the wiki.
I hope to statically generate it eventually, currently the problem is that it takes at least several seconds to generate the recentchanges page, and adding several seconds to every page edit is not desiriable. If the time can be reduced it could be done, I'm also not adverse to adding an optional way to statically render it even at the current speed.
Also, is it planned/desired that recent changes generate the same information in RSS feed format? This seems like it could be a useful way to keep track of the wiki as a whole.
This is used by various interwiki type things, I think, so should be done..
Lastly, would it be possible to use the recent changes code with a pagespec? I understand this sort of infringes on territory covered by the inline plugin, but the inline plugin only puts a page in the RSS feed once, when it's created, and I imagine some people -- some deranged, obsessive-compulsive people like myself -- would like to know about the changes made to existing pages as well as newly-created pages.
Some inconsistences around the toplevel index page:
- ?ikiwiki is a separate page; links to ?ikiwiki should better go to the index though.
The toplevel ?Discussion page has some weird parentlinks behavior. This could be special cased around with the following patch. However, I'm unsure if I like the idea of more special cases around this. It would be better to find a way to make the toplevel index page not be a special case at all.
--- IkiWiki/Render.pm (revision 1187) +++ IkiWiki/Render.pm (working copy) @@ -71,6 +71,7 @@ my $path=""; my $skip=1; return if $page eq 'index'; # toplevel
- $path=".." if $page=~s/^index\///; foreach my $dir (reverse split("/", $page)) { if (! $skip) { $path.="../";
Posted Sat Sep 30 21:31:42 2006I would like to suggest another tack, namely a bigger, better special case. The basic idea is that all indices of the form foo/bar/index get the wiki path foo/bar. This makes some things more elegant:
- All files having to do with foo/bar are in the foo/bar directory, rather than the (admittedly minor) wart of having the index be in foo/.
- This sort of addresses broken parentlinks in that example/ is guaranteed to be a valid path. (There might be no index there, though.)
- This is more in line with standard HTML practice, as far as I understand it, namely that linking to a/b means a/b/index.html rather than a/b.html.
This would change the inline plugin in strange ways -- I think if foo/index.html contains [[inline "* and !*/Discussion"]], it should skip inlining foo/index.html explicitly, but would inline index pages in child directories foo/bar/baz/index.html as bar/baz.
It always bothers me that foo/bar/ files need a foo/bar.html in front of them, rather than a foo/bar/index.html, as is (to my mind) traditional.
Ethan
Hmm, now I've had time to think about this, and this does conflict pretty hard with foo.html/Discussion pages. Well, back to the drawing board.
Well, it seems unlikely that you'll have both foo/bar.html and foo/bar/index.html, so why not accept either as foo/bar? This would both preserve backwards compatibility, as well as allow foo/bar/Discussion.
Ethan
No, in order for this to work, the wiki path foo/bar/baz could be any of:
- foo/bar/baz.html
- foo/index/bar/index/baz.html
- foo/bar/index/baz.html
- foo/bar/index/baz/index.html
Or many others. Which is probably even hackier than having both foo.html and foo/.
Ethan
Need a way to sign name in page that's easier to type than "--Joey" and that includes the date.
What syntax do other wikis use for this? I'm considering "?--" (with spaces removed) as it has a nice nmemonic.
OTOH, adding additional syntax for this would be counter to one of the design goals for ikiwiki: keeping as much markup as possible out of the wiki and not adding nonstandard markup. And it's not significantly hard to type "--Joey", and as to the date, we do have page history.
I'm also unsure how to possibly implement this. Seems ikiwiki would need to expand the rune to the user's name when a page is saved, but that leaves out svn commits.
Alternate idea: Make a sig plugin, which would expand --Name to
--?Name (the "user/" bit would be configurable). This would be very
easy to do, although it would need to try to avoid false positives, such
as --foo
in C code..
- Need to get post commit hook code working.
- Need some example urls for web based diffs.
- Eventually, might want page deletion.
- Eventually, might want file upload.
- Page move? Link corrections?
Posted Fri Sep 1 22:34:29 2006(I left this comment in discussion, but it might be better here on the main page) This is a function I would really like. I am dealing with a situation, in creating a link for my family history, for instance to "Peter Richard MacLea (1888-c.1946)" and fleshing out an article with pictures and so on. Then, I later find out that Peter died in 1948. So, I want to move that page to "Peter Richard MacLea (1888-1948)". There doesn't seem to be an easy way to do this. The main problem being that I can easily create a second page with that data, but what happens to the old one? Does it remain? I would like to see at least a rename or page move function.... Kyle=
Perhaps I'm just too stupid to find the proper way to do this, but how would I add a new page to the wiki without selecting to edit an already installed one and frobbing the URL to direct to the to-be-created page? --?ThomasSchwinge
Good point. Of course one way is to start with creating a link to the page, which also helps prevent orphans. But other wikis based on CGI do have this a bit easier, since they can detect an attempt to access a nonexistant page and show an edit page. Ikiwiki can't do that (unless its web server is configured to do smart things on a 404, like maybe call ikiwiki.cgi which could be modified to work as a smart 404 -> edit handler).
Some wikis also provide a UI means for creating a new page. If we can find something good, that can be added to ikiwiki's UI. --Joey
Hmm, maybe just a preprocessor directive that creates a form inside a page, like is used for blog posting already would suffice? Then the main page of a wiki could have a form for adding new pages, if that directive were included there. Won't work for subpages though, unless the directive were added to the parent page. However, unconnected subpages are surely an even rarer thing to want than unconnected top level pages. --Joey
Here is a simple plugin that does that. Perhaps options could be added to it, but I couldn't really think of any. http://jameswestby.net/scratch/create.diff -- JamesWestby
Maybe a very simple PHP frontend for serving the statically generated pages, that would display a page editing form or something like that for non-existent pages, wouldn't be too bad a thing and resource hog? Just a thought... --?Tuomov
Posted Mon Aug 28 19:18:54 2006A few plugins need more complex dependency calculations than ikiwiki can do on its own:
- Use of a version plugin should only make the page rebuild when it's built with a new version of ikiwiki.
- The sidebar plugin should make any page get rebuilt if a sidebar is created "closer" to it than the current sidebar.
- Some plugin might want to always rebuild the page that uses it.
- If backlinks were turned into a plugin, it would need to make a page rebuild when its backlinks changed.
These suggest there should be a way for plugins to have hooks that tweak the list of pages to rebuild.
Which in turn suggests that there should be a list of pages to rebuild; currently there's not, and the best such an interface could do would be to rebuild the pages even if they were already going to be rebuilt for some other reason. (See optimisations.)
It also suggests that plugins will want to examine pages and/or store data about them to use in the dependency calculations. For example, the version plugin would need to store info about what pages use it.
Posted Sun Aug 27 05:32:49 2006A speel chek plug-in woold be fantaztik. Anyone working on this?
Knot adz fair ass eye no --Joey
Posted Mon Aug 21 21:42:44 2006Another useful feature might be to be able to choose a different template file for some pages; blog pages would use a template different from the home page, even if both are managed in the same repository, etc.
Well, that would probably be fairly easy to add if it used pagespecs to specify which pages use the non-default template.
Hmm, I think the pagetemplate hook should allow one to get close enough to this in a plugin now.
Posted Tue Aug 1 21:32:09 2006Stuff still needing to be done with tags:
It's unfortunate that the rss category (tag) support doesn't include a domain="" attribute in the category elements. That would let readers know how to follow back to the tag page in the wiki. However, the domain attribute is specified to be the base url, to which the category is just appended. So there's no way to add ".html", so the url won't be right.
This is one good argument for changing ikiwiki so that pages are all dir/index.html, then a link to just "dir" works.