Please add features you'd like to see here. I'll classify them into priorities (but you may "vote" for features you'd really like to see by adding comments here). - Richard W.M. Jones
Add your unclassified features here ...
I would like to suggest that the existing syntax is extended logically, such that [[http://url/|text to show]] is extended with [[http://url/|image://url_to_image]] and [[http://url/|thumb://url_to_image]]. This was what i intuitively tried before discovering that it was not possible with clickeable images.
This wiki has a lot of very nice features. I'll certainly be considering it when I get my site back together. How about adding a working (only works in MSIE - done in 5 minutes jobbie) version of this ? Contact me if you need help on the javascript side of things. (The realtime display of what you're typing is a little painful though - freezes the textarea that I'm typing into whenever its refreshing, is that a bug or a feature? :))
This extends the discussion below about whether an image is a clickable link, or displayed inline. Something like [[image:picture.jpg|Fubar]] perhaps, which displays the image inline and allows a click to take the user to Fubar?
It would be nice to have an option to use externally provided account (username/password/e-mail) information:
Yes, I'd like this too :-)
In some situations it is not possible to configure a virtual host. Being able to use a path prefix like http://web.server/prefix/ instead as the base URI for the wiki would be nice. Or is this already possible?
You can probably do this, but you'd need to change all the mod_rewrite rules appropriately. Notice that we deliberately create URLs which are bookmark, email and search-engine friendly, unlike most other wikis.
My intention is to add cocanwiki to an already existing webserver so that all wiki related pages/URIs are served from http://server.name/prefix/ and all other URIs continue to work. The scripts seem to construct URIs by using
"http://" ^ hostname ^ "pagename..."
Allowing something like
"http://" ^ hostname ^ prefix ^ "pagename..."
would make it possible to even have multiple instances on the same server hostname in different paths. You currently seem to use only hostname as the key to select the wiki instance. My proposal is to extend that with a path prefix. This could be stored in the database to be used together with hostname to form the selector.
OK, mysterious correspondent. It's probably better to continue this conversation in email. Mail me at mailto:rich@annexia.org.
Make COCANWIKI available through the GODI package system.
I'd like to see this too. I even contacted Gerd and he sent me in the direction of some very useful links. However I don't really have the time to do a GODI package - it also involves packaging mod_caml. I can help out others who want to try.
Warn people not to use valuable passwords (Daniel Bunzli)
Don't email every change -- either email once per day, or don't email until someone checks the site (as is done in PHPBB).
Links to images, like [[http://www.annexia.org/graphics/squidship.jpg]], should be turned into images.
Should this really be automatic? There exist cases (such as with particularly large images) where it might be desirable to link to an image without inlining it. How do other wikis handle this?
In UseModWiki a bare URL is turned into a link, and a bare URL which happens to end in .jpg or .gif gets turned into an inline image. I don't think that bare URLs should ever be turned into links, but if we assume that we're talking about [[links]]. There is an argument that sometimes you'd want to link to an image, and sometimes you'd want to have the image automatically inline itself. How often would you want each? I suspect the inlining would be more useful, but only if you know about that feature. -- Richard W.M. Jones
Actually, I now think the best way to do this is to have [[image:http://www.annexia.org/graphics/squidship.jpg]] be an inline image, and [[http://www.annexia.org/graphics/squidship.jpg]] be a simple link to the image.
Mediawiki uses Texvc to render math formulas in HTML, MathML or PNG (via LaTeX). Texvc is written in OCaml so it might be easily integrable in COCANWIKI.
This isn't a feature which I want, but please send me patches if you make it work. -- Richard W.M. Jones
Allow pages to be deleted. (Controversial: perhaps just allowing for redirects is sufficient; if a page really needs to be deleted, say for legal reasons, it could be removed by hand from the database).
Actually I've decided that I won't implement this unless someone gives me a compelling case for it. I think redirects are enough, and I suspect that allowing pages to be deleted has tricky implications on some of the rest of the code. -- Richard W.M. Jones
Wikipedia has it, why not us?!
This isn't a very well-formed idea, but it would be nice to see some sort of standard page components which can be added; the particular cases are contact forms, blogs and galleries. As well as "insert new section here" you would be able to insert a "standard component" which would be a blog, gallery, etc.
Another feature, a possible alternative implementation of this: Have an [[include page#section]] directive which includes the contents of one page within another.
Allow '**' to start a second level of bulleted list, and similarly for '##'.
Some way of supporting the definition list HTML feature.
<dl> <dt>term1</dt> <dd>definiton1</dd> <dt>term2</dt> <dd>definition2</dt> <dd>definition3</dd> </dl>
It would be particularly appropriate for the advantages of OCaml at http://wiki.cocan.org/
I agree this would be useful. At the very least, the <html> "inline HTML" feature should allow it. Then we could think of a suitable markup syntax and allow its general use. - Richard W.M. Jones
How about adding a table support like Wikipedia do?
Already in version 1.1, coming soon-ish.
For a small wiki a database isn't really necessary.
Ain't gonna happen. The database schema is very complex and we use lots and lots of big SQL queries all over the place. Just set up a PostgreSQL database, it only takes a few minutes. -- Richard W.M. Jones
Then, how about a feature that can export a static website (html only and without those edit or version wiki function keys) according to the newest (or marked stable) version. This would be useful for those who wish to locally maintain their pages in cocanwiki but have to publish them to a server without ocaml support.
This would be a nice feature. Another, related feature which is often mooted is PDF export. If you can do a PDF export of the site or a subset of the site, then exporting to HTML could be done by the same code. You can do something similar by "wget"-ing the site and doing a bit of HTML surgery to remove the unwanted links. However that is not so nice. -- Richard W.M. Jones
Would be nice to have the possibility to for instance have a journal which is integrated in the wiki.
Implemented in version 1.1. Try pointing your favorite RSS aggregator at http://sandbox.merjis.com/wishlist_features/index.rss
It'd be useful to have a site template, much like the Site Menu, to set up corporate branding and standard page information.
This can be done in CSS. -- Richard W.M. Jones
Allow
Not going to happen. If anything I'm going to move away from wiki markup entirely. Richard W.M. Jones
Could you please clarify what you mean with moving away from wiki markup? -- AnonymousCowardUsingBugMeNot
An internal search option - probably based on the database full text indexing packages available for PostgreSQL.
Done, based on tsearch2.