Feature Requests

This page is for requesting new features. Related pages include:

  • Roadmap - A list of planned features for future releases.
  • [[asdf 
    ==This is a new Heading==

    If you're proposing a feature that would obsolete, supercede, or very likely interfere with another feature, keep it in the same section with a subsection title that either makes very clear what alternative mechanism you're proposing, or that it's a "contrary position" that the mechanism is clearly not desirable. Feel free to edit contrary positions into constructive alternatives but do NOT omit the fundamental arguments against the original proposal when you refactor. If necessary put the whole section in issue/position/argument form or some other logic tree format that makes it easy to compare competing positions on one issue.

    [Edit]

    Flash embed capability

    I think it would be cool if we can put Flash files (or even other media files ) embedded.

    It probably wouldn't be hard to add support for the embed tag as a configurable option. I'll add it to the to-do list, thanks. -- Ryan 02-Apr-2008 13:37 PDT
    [Edit]

    Math. formula support

    [Edit]

    jsMath Support

    I implemented math formula rendering compatible with wikimedia syntax of "<math>sin(x)</math>" with the great js library jsMath in your parser. You might be interested in the result:

    put the jsMath stuff into the html head part

    patch: jamwiki-processor.jflex add:

math = (<[ ]*) "math" ([ ]+name[ ]*=[^>\/\n\r]+[ ]*)? ([ ]*>) ~(<[ ]*\/[ ]*math[ ]*>)

<NORMAL, LIST, TABLE, TD, TH, TC>{math} {
    logger.finer("math: " + yytext() + " (" + yystate() + ")");
    WikiMathTag parserTag = new WikiMathTag();
    return this.parseToken(yytext(), parserTag);
}

    create WikiMathTag class:

    public class WikiMathTag implements ParserTag {
	
    public String parse(ParserInput parserInput, ParserDocument parserDocument,
                        int mode, String raw) throws Exception {
        if (mode < JFlexParser.MODE_PROCESS) {
            return raw;
        }
        String content = ParserUtil.tagContent(raw);

        StringBuffer html = new StringBuffer();
        html.append("<div class=\"math\">");
        html.append(content);
        html.append("</div>");
        return html.toString();
    }
}

    check the topic content for wiki math. tag content

    
function checkForMathClass(id) {
	var div = document.getElementById(id);
	var elements = div.getElementsByTagName('div');
	for (var i=0; i < elements.length; i++){
	
		var div = elements[i];
		if (div.getAttribute("class") && div.getAttribute("class") == "math") {
			jsMath.Process();
				break;
		}
	}
}

    cheers!

    guido

    Cool! Ideally I'd like to implement this sort of functionality as a plugin to avoid having to include another 600KB in the default JAMWiki distribution (we're already at 4MB), which means that implementation of a plugin architecture needs to move further up on the to-do list. For now would you be OK with hosting this implementation on a page such as Tech:Math so that others can use it, and we can work on some way to implement the code as a plugin for a future release?
    Also, are you willing to license your code under the GFDL? Just let me know, and provided you're willing to license it for others please let me know what name you'd like to appear in the CREDITS file (most people use their real name followed by their jamwiki.org login, such as "Ryan Holliday (wrh2)"). -- Ryan 23-Jan-2007 21:51 PST
    I personally think that 4MB or 10MB does not matter nowadays anymore, but it's your choice. I'm fine with GFDL license. You can add my Name as: "Guido Schnider (olat) www.olat.org" --olat 31-Jan-2007 07:06 PST
    In the article jsMath - new version 3.4d installed in MathEclipse wiki, you can find a description how I integrated jsMath into jamwiki. Axel Kramer 19-Jan-2008 11:35 PST
    [Edit]

    JMathTex Support

    Did someone already think about integrating JMathTeX support into JAMWiki? Axel Kramer 19-Jun-2007 12:40 PDT

    Here is a simple example for rendering a formula from TeX to a PNG image:

    package be.ugent.caagt.jmathtex.test;

import java.awt.Graphics2D;
import java.awt.image.BufferedImage;
import java.io.File;
import java.io.IOException;

import javax.imageio.ImageIO;
import javax.swing.Icon;
import javax.swing.JLabel;

import be.ugent.caagt.jmathtex.TeXConstants;
import be.ugent.caagt.jmathtex.TeXFormula;

public class TestPNG {
	public static void main(String[] args) {
		TeXFormula formula = new TeXFormula("\\int_{t=0}^{2\\pi}\\frac{\\sqrt{t}}{1 + \\mathrm{cos}^2 t}\\nbsp dt");
		Icon icon = formula.createTeXIcon(TeXConstants.STYLE_DISPLAY, 25);
		BufferedImage image = new BufferedImage(icon.getIconWidth(), icon.getIconHeight(), BufferedImage.TYPE_INT_ARGB);
		Graphics2D g2 = image.createGraphics();
		icon.paintIcon(new JLabel(), g2, 0, 0); // component can't be null
		// fill a file path below
		File file = new File("c:\\temp\\jmathtex.png");
		try {
			ImageIO.write(image, "png", file.getAbsoluteFile());
		} catch (IOException ex) {
		}
	}
	
}

    The rendered image looks like this:

    The license is GPL, so I'm not sure that it can be included in the default JAMWiki distribution (I'm not a lawyer, so if anyone knows better please say something!). That said, it seems like this could still be handled as a plugin, which would avoid the GPL distribution issues. I don't personally use math functions, but if anyone wants to put something together I wouldn't have any objection. -- Ryan 19-Jun-2007 18:48 PDT
    [Edit]

    Virtual Wiki's

    Have started looking as virtual wiki's. Couple of questions:

    • When accessing my context, as mentioned, access defaults to "en" wiki and whatever topic is defined as initial startup topic in admin section, however when I try to access http://someurl/context/en'' it says 'no virtual wiki found'. Same applies to added virtual wiki. One has to enterhttp://someurl/context/new_virtual_wiki/some_topic''. I would have expected access to default to default topic. Is this possible? (Maybe it is not the intention).
    • Can each virtual wiki have their own default page - looks like they share a common name?
    • How can I redirect from menu page on left hand side of screen the user to a virtual wiki (besides providing full url)?

    Cheers CB 22-Jul-2006 07:03 PDT

    Hi Colin. I'll look into getting "http://someurl/context/virtualwiki" to redirect to the default topic, but I'll need to test a few things first. I'll try to get that fix into 0.1.0. I can also look into allowing each virtual wiki to have a different default topic, but I'll need to give some thought as to how that could be handled. As to how best to redirect to a virtual wiki without providing the full URL, it may be possible to do something similar to Mediawiki, where the link would look something like [[en:Topic Name]]. This is not currently implemented, but I don't think it would be too hard to do. Let me know if that would work for you.
    I'm probably not going to be writing much code today, but I'll hopefully be able to get something together by Monday. Thanks again for all of your feedback - it's extremely helpful! -- Ryan 22-Jul-2006 10:28 PDT
    I should hope you get to take some time off!
    Way I have gotten round (for now) the default topic is to redirect to "lefthand" as I don't want to force common name on virtual wiki's. Reason for using virtual wiki's is that allows me a crude way to group topics and control access via tomcat's authentication scheme using each virtual wiki's seperate path.
    Your suggestion on redirect to virtual wiki would definitely work for me.
    Only a pleasure on feedback, its one way I can offer help. CB
    Hi Colin - JAMWiki 0.1.0 (released tonight) contains support for Wiki links to a virtual wiki - simply enter text of the form [[:virtual:Topic]]. In addition, if you scroll down on the admin screen you are given the option to define a default topic for each virtual wiki, which should hopefully meet your needs. As to the redirection for "http://someurl/context/en", that's a bit trickier - "http://someurl/context/en/" will redirect (sorry, I guess that doesn't work either. I'll look into it), but without the closing slash it's tough to get the pattern matching correct. How important of an issue is that for you? -- Ryan 27-Jul-2006 00:33 PDT
    >That is awesome link to virtual wiki and seperate default topics work like a treat!
    >The "http://someurl/context/en" is not that critical just makes user access easier when adding user authentication to seperate virtual wiki's. If supported user will just need to point to the virtual wiki and not know actual page - does this make sense? CB
    I've got redirection working for "http://someurl/context/en/" (will be in 0.1.1), but ""http://someurl/context/en" is proving tricky. I've got some ideas, so hopefully that will make the next release as well. Thanks again for all of your feedback. -- Ryan 28-Jul-2006 19:24 PDT

    I would have one question. In the moment the only way to register new virtual wiki is to add a new context and restart servlet engine. Could it be done without restart? Regards Milan.

    Since the web.xml file needs to be modified when adding a new virtual wiki, the current code requires a restart. I suspect that there's probably a way to handle virtual wikis without the need to modify web.xml, but implementing such a change would probably require significant changes to the way JAMWiki handles requests. Anyone who has ideas and the motivation to make such a change is welcome to do so, however :) -- Ryan 14-Mar-2007 10:01 PST
    • It would be quite comfortable to disable virtual wikis at all. Most ppl need only one wiki. e.g. localhost/jamwiki/MainPage
    [Edit]

    Image Storage

    What would you think about storing images in the database as bytes (instead of on the file system as files) for database persistent installations? -- scroco 14-Aug-2006 11:23 PDT

    It could definitely be done as an option, but I'd definitely like to have the ability to store files on the filesystem as well. I've only worked on a couple of projects where files were stored in the database, and we had some issues due to the fact that the database size became huge and backups took a long time, as well as some problems with connections being held for long periods due to the amount of data that sometimes had to be transferred. However, I can see some cases where a business might want to put everything in a database for security or other reasons. I would assume that files would have to be cached on the filesystem for performance reasons - do you have a business case where security (or some other concern) would forbid file storage? -- Ryan 14-Aug-2006 11:48 PDT

    The case I'm thinking of is running JAMWiki across multiple servers. In such a case, there would be other items that would need to be addressed (lucene indexing perhaps, caching perhaps), but image storage is the most obvious one. -- scroco 14-Aug-2006 12:04 PDT

    Good call. Right now an NFS mount or something similar would be the only way to handle image uploads with multiple servers, but the software should have some mechanism for mirroring content. Thinking about it further, eventually adding some sort of automatic mirroring functionality could be hugely useful... -- Ryan 14-Aug-2006 12:13 PDT

    What about implementing support for MediaWiki-like structure of uploaded files? --Gutsul 26-Dec-2006 02:03 PST

    Is there an advantage to copying their file structure? I'm not too familiar with how they store files, but it appears that they simply create several parent directories and then store files within them under names like "/File.jpg/File.jpg", "/File.jpg/File-500px.jpg", etc. If there is a system that they're using and there are advantages to using it then copying it is worth considering, but I'd need to better understand the benefits. -- Ryan 26-Dec-2006 22:35 PST
    The advantage is that one can copy both topics and pictures from MediaWiki and use in JAMWiki. They are computing md5 sum of the file name and the uses first two hex-numbers for naming directories. For instance: if a.jpg has md5 = "abc123" then this file wil be store in _root_/a/ab/a.jpg --Gutsul 27-Dec-2006 05:58 PST
    [Edit]

    Allpages pagination

    When there are thousands of pages, the allpages page takes forever to load. Perhaps it should be paginated alphabetically. -- scroco 20-Sep-2006 10:59 PDT

    Special:Allpages, Special:History, user contributions, and other pages all need something like that - I just hadn't moved it higher on the priority list since no one was asking yet. I'll add it to Known Issues and try to get something done for 0.3.5 or 0.4.0. Let me know if you have any preferences for the way it looks, and thanks for the report. -- Ryan 20-Sep-2006 11:04 PDT
    There's a first attempt at pagination now running on jamwiki.org, please let me know if you have any feedback. I'll wait to push out a new beta until I've done a bit of testing on a database other than Postgres, just to verify that the SQL syntax changes are OK. -- Ryan 25-Sep-2006 15:09 PDT

    That looks pretty good. But how do you feel about alphabetical pagination? If a user wants to see if there's a category or an entry for South Dakota, it's difficult to guess how many hundreds (or thousands) of entries to skip to find the "S"'s. Much easier if there is an "S" link at the top. -- scroco 27-Sep-2006 17:06 PDT

    Just to be clear, would you want something like the index here? It's definitely doable, although probably not for JAMWiki 0.3.5. Barring objections I'm planning on scrapping the existing file persistency code for JAMWiki 0.4.0 and replacing it with the HSQL database, which will make requests like this one much, much easier to implement. Let me know how high of a priority the alphabetization would be for you, and unless it's a vital thing let's plan on getting something done post 0.4.0. If you have any further suggestions about implementation details please also let me know, as it's always easier when someone else does the design work ;) -- Ryan 27-Sep-2006 17:24 PDT

    Yup, like that page you linked. Or ... for Allpages they do it this way: http://en.wikipedia.org/wiki/Special:Allpages Maybe a combination of both would be good, or if you want to strictly follow wikipedia, that's cool too. Obviously, on something like "recent changes", it makes no sense to do it this way, unless maybe you grouped a page by week or month.

    This is not critical for me. The numbered pagination works fine, I just think the alpha would be more useful. -- scroco 27-Sep-2006 17:58 PDT

    [Edit]

    Non-Image file upload naming

    I wonder if JamWiki could support other uploaded files than image. I tried that and uploaded to your site a PDF, Image:bshmanual.pdf. This file is reported as an image:

    Image:bshmanual.pdf

    What do you think of allowing non image contents and present them like pdf:bshmanual.pdf, word:bshmanual.doc .....

    This feature will be very welcome when companies will see WIKI as a documentation and basic content management system. -- Henri

    I agree that naming a PDF or Word file with an "Image:" prefix doesn't make much sense. Perhaps eventually a configuration option could be added so that a site administrator could choose prefixes based on the file type, with a default prefix of "File:". That would allow a bit more flexibility than forcing prefixes on people who might not want them while still keeping JAMWiki mostly in-sync with how Mediawiki handles the situation. -- Ryan 11-Oct-2006 10:24 PDT
    Did you plan to add this feature ? -- Henri 14-Oct-2006 10:11 CET
    I think it would be a good feature to have, but it's not something that I'll be able to get to in the immediate future. In addition, there have been requests for language-specific namespaces, so it would probably make sense to implement both at the same time since the code will be similar. If you'd like you can add this request to the Roadmap under "Unscheduled", or else we can leave the request on this page for others to add their comments to. -- Ryan 14-Oct-2006 10:41 PDT
    IHMO, "File:" does make more sense. And what would go great with that would be a MIME Type field in the "File/Image" object and db table. It would allow for, eventually, plug-ins to do stuff like parsing .pdf files and indexing its content for search and stuff like that!... or maybe I got to stop smoking weird stuff... ;) -- João 30-Nov-2006 15:28 GMT
    For what it's worth there is already a mime_type field in the jam_wiki_file table. As to using a "File:" namespace for non-image files, I'd forgotten that idea but like it a lot - is anyone opposed to that idea, or can I put it on the to-do list for JAMWiki 0.5.1? -- Ryan 30-Nov-2006 16:07 PST
    Did this feature still planned in 0.5.1 ? Henri 23-Jan-2007 14:40 CET
    I still think that this feature is a good idea, but it won't make it for JAMWiki 0.5.1; I've been working a lot in the past two months, so JAMWiki development has slowed considerably. Since this is a feature that would differ from Mediawiki I'd ideally like to see a few more opinions about using "File:" vs. MIME-type specific prefixes. More than likely a final implementation would allow site administrators to choose prefixes based on MIME type, but that would be a bit of work to do. In any case this one will probably need to wait until either 1) there's enough discussion that someone else can implement it or 2) I get more free time. -- Ryan 23-Jan-2007 21:58 PST
    Mime approach is also a good idea, btw mime or file, JamWiki should be able to host various files, in flat file or in DB to make wiki very suitable for enterprises purposes. Henri 24-Jan-2007 11:01 CET
    [Edit]

    Templates

    Is there a page with a list of all the existing templates, or do i have to manage this list by my own? What if different users create there own templates, want to share their templates. Looking for how to create, find and manage templates I missed some help-texts. Are there plans to include them in jamwiki (I would support with ideas and texts ...)? : Michael Habbert 04-Nov-2006 16:28

    Hi Ryan, what do you think about a AllTemplage page?
    At the moment Special:Allpages is the only way to see a list of all templates. Something like Special:Alltemplates might be a good idea, or a drop-down could be added to Special:Allpages to allow the list to be filtered by namespace - that would allow a user to view (for example) all templates, all template comment pages, all help pages, etc.
    As to help text for templates, at the moment documentation is pretty sparse - I need to spend more time writing documentation, but there are a lot of things to do. If you're willing to start writing any documentation please feel free to add it to jamwiki.org and I'd be happy to help out with it. Otherwise I'd suggest using http://meta.wikimedia.org/wiki/Help:Templates as a starting point - JAMWiki supports the majority of the Mediawiki template syntax at this point. Let me know if that answers your questions, and thanks for the feedback! -- Ryan 04-Nov-2006 10:04 PST
    [Edit]

    PageUp-Link

    Hi Ryan, what do you think about a page-up-link, someone can add add the bottom of the page. Michael.Habbert 2006-11-17 16:06 MEZ

    Sorry, I'm not great with terminology - by "page-up-link", do you mean a link to the top of the page? Would it be sufficient to be able to link to the first heading, such as first heading on this page, or do you envision something different? -- Ryan 17-Nov-2006 07:29 PST
    Hi Ryan, yes I thought about exactly that topic. A tag you add at the end of the page or somehow in the middle. But the tag is not direktly related to the specific page (like your example: #Archives|... I had something more universal im mind, like: [[Page|top]] but on every page you place this unique tag you allway will get to the top of the actual page. And there is no effort to set the target of the link - because it is implicit in every page. I think this will be quit more convenient for the user to handle. -- Michael Habbert 20:15 CET
    I suspect that this kind of feature might be best implemented as a plugin, since it may not be something that all users want. At the moment JAMWiki doesn't support creating plugins for tags, but feel free to add this suggestion to Roadmap#Unscheduled, and once plugin support is available it should be an easy thing to add. In the mean time hopefully the workaround above (link to a heading) will be sufficient. -- Ryan 18-Nov-2006 15:41 PST
    [Edit]

    Favorites (or new watchlist functionality)

    This is a Mediawiki deviant feature. A functionality that I praise most in MoinMoin is the possibility of marking pages as favorites, for quick navigation. Although the "favorites" concept is slight different from "watchlist", the reasons a person has for putting something in the "watchlist" are mostly the same that the ones that drives someone to mark it as "favourite".

    The feature I'm proposing is altering the "Create a page to view and edit a user's current watchlist, as is done with Mediawiki." feature in 0.5's checklist and adopt a hybrid watchlist-favourites feature, which I predict to have a shorter development time than the original feature. In the LeftMenu, below the search div, would appear the list of the "watched" pages. That way it would work as a "favourite" list and at the same time, users could remove their watched pages by browsing to them and "Unwatching" the standard way. -- João 28-Nov-2006 14:19 GMT

    I was looking at the code and I can do this with no problem in about 15 minutes :) There is a problem with my idea, though... left menu is supposed to be "user independent" and this feature would break that rule. I'll wait for more feedback on this matter before doing anything but if you want to add me to the project @ sourceforge, my username is jmgoncalves. -- João 28-Nov-2006 15:34 GMT
    I like the idea of having links to favorites, but I'd worry about the implementation - on a few of the Mediawiki sites that I use I have as many as 500 watched pages, which would be unmanageable in the navigation bar. How does MoinMoin handle very large watchlists? Also, I'd want to make sure that if this feature was implemented that it was done as an option, so that individuals who want a Mediawiki clone still have it. I've added you to the Sourceforge project, so feel free to create a branch and add code to implement this feature (the "user independence" of the left menu isn't that big of a deal - just create another JSP and include it in the left menu area). Eventually there will need to be a way for sysadmins to add custom code to the left menu, so this will hopefully be a way to start that discussion. -- Ryan 28-Nov-2006 10:47 PST
    More urgent than sysadmins to add custom code, should be the possibility of adding hooks for plug-in development! Pieces of code for dynamically adding stuff to the left, top and user menus. The "Mediawiki deviant" features that people ask could then be available through plug-ins! But plug-in architecture is a big thing. Maybe you ought to open a whole page for it, when you are ready to work in such a thing :)
    Enough of off-topic, MoinMoin doesn't implement watchlists, and handles badly a big favorite list, so from there we're not going to get any ideas... I've been busy so I still haven't created a branch for me, and more-over I'd like to further discuss this feature. Maybe a Mediawiki-like watchlist management and favourites as a plug-in? -- João 30-Nov-2006 15:39 GMT
    Some sort of a plugin mechanism is very high on the to-do list, but it's a tough job. JAMWiki 0.5.0 offers additional plugin-type options, including making it easier to use a custom parser, authentication mechanism, or even data handler. I'd also like to make it easier to add custom syntax tags, customize menus and displays, etc. Over time all of that will probably get done, but in the interim the solution (unfortunately) will be that people need to write custom code for some customizations.
    Also, if you're ready to start working on a new feature please add it to the Current Development Status page and create a page describing the feature, such as Tech:Favorites List. Implementing a "favorites" list definitely sounds like a good candidate for a plugin, but as you've pointed out the discussions on how to implement such plugins has yet to begin. -- Ryan 30-Nov-2006 16:13 PST
    [Edit]

    Diagram editor

    Good to see JamWiki progressing so quickly. The new (0.5.0) integration with a third party authentication system is particularly interesting as it opens the possibility for a full user privileges system.

    On a separate note, I came across www.gliffy.com the other day. Would you ever think of integrating with them, in the same way they've integrated with the Confluence wiki (see their site)? Oliver 30-Jan-2007 14:49 PST

    The Acegi integration is courtesy of User:swift, and I agree it's a nice addition. I'd like to do a bit more work to allow more configuration of Acegi settings from Special:Admin and to better utilize the Acegi functionality for LDAP and other features, but even without that level of integration it's still a good improvement, and I'm grateful to Rainer for the work he put into it.
    Regarding Gliffy, provided an integration could be done in such a way that it had no effect on users who wanted to disable that feature I'd be happy to add support. Now that I'm working full time again I'm probably not going to have time to personally implement any sort of integration, but anyone who is interested is welcome to start up a discussion on the subject as a Tech: topic (see How to Help#Programmers). Due to time constraints I'm trying to shift my focus more towards making the JAMWiki infrastructure easier for others to extend. The work has barely begun, but the eventual goal is that there would be well-defined mechanisms for others to add plugin functionality, parser extensions, security modules, etc. Hopefully with such a framework in place an integration with something like Gliffy would become much simpler, or at least that's the goal. -- Ryan 30-Jan-2007 20:29 PST
    [Edit]

    CamelCase / WikiWord Support

    I don't think Mediawiki even has it (not sure), but is there any chance of getting optional CamelCase support for autolinking CamelCased WikiWords? Perhaps as an admin configurable option or something? -- DanR 30-Jan-2007 19:25 PST

    Agreed, it would definitely be something that could be nice to add as an option. I don't personally have time to work on adding CamelCase support right now, but technically there's no reason why such support couldn't be added. If you'd like you can copy this request to Roadmap#Unscheduled, or if you're brave you can take a look at the current parser code - if you choose that route beware, as the code is in need of an overhaul. -- Ryan 30-Jan-2007 20:32 PST
    It's a really really really really bad idea. About the worst possible. They are pollution that took years to get out of Wikipedia. If you add this horrific misfeature then you
    1. cause use of those words in existing mediawiki pages to break and make it difficult or impossible to use real English names such as company names that include them
    2. not only encourage but enforce bad capitalization habits in page names since they will be created with Absurd Victorian Capitalization and accordingly not be easy to link to unless you ALSO break the mediawiki convention of case sensitivity, which is the right one in English
    3. teach really bad English
    [Edit]

    More public methods

    I have found that, in building an external application that shares functionality with JAMWiki, it is necessary to change some protected methods and constructors to public. Specifically, thus far, /servlets/ServletUtil.java and /servlets/WikiPageInfo.java have been changed in this way. I don't find that making these changes appears to compromise the rest of the system in any way; I'd like to request that these changes find their way into SVN. Other such changes may be found to be necessary as well, but for now, I'm simply borrowing from the servlet infrastructure in order to federate TopicSpaces at runtime with JAMWiki. Jack 08-Mar-2007 16:49 PST

    My approach is generally to restrict methods as much as possible until they are needed elsewhere, but if relaxed permissions are needed somewhere then it's fine to relax them. If you'd like write access to the Subversion repository please let me know your Sourceforge ID and I'll set you up. I only ask that for now any changes are made to your own branch (not to the trunk) so that any changes can be reviewed prior to merging. -- Ryan 08-Mar-2007 21:34 PST
    [Edit]

    JAMWiki extensions

    Hello, I am playing with JAMWiki, and like it a lot. However, I may need to customize it in the following ways:

    • Content is stored on SVN not in DB
    • Different wiki language is used, so I have to introduce different parser.

    How difficult it could be respect to overall system architecture. For SVN access I would use SVNKit last version. Maybe you could be insterested for such contribution, if it is feasible after all. Regards Milan

    Please have a look at org.jamwiki.parser.AbstractParser, org.jamwiki.DataHandler and org.jamwiki.UserHandler, which are the interfaces / abstract classes for the parser and data handling code. JAMWiki was specifically designed so that new parsers or data handlers could be written and used instead of the defaults. I'm certain there will be some issues to resolve when using a radically different parser language or something like SVN for data storage, but the problems shouldn't be difficult to overcome. -- Ryan 15-Mar-2007 12:20 PST
    Thank you for the answer. I will try. I would have another question. Since I have tree structure (SVN working copy on local file system), I am thinking about matching Folders and JAMWiki Categories. I tried to find out, but without success, if JAMWiki supports nested categories. Or, maybe you have different idea how to support tree structure in JAMWiki. Thanks and regards, Milan
    I noticed, as mentioned here that when I used a different base DataHandler than AnsiDataHandler, there was an exception thrown when trying to initialize search on startup. That seems to expect AnsiDataHandler to be active. If it's not in the active DataHandler chain, the exception gets thrown. My knee-jerk response is that writing external DataHandler implementations will be problematic. -- Jack 23-Mar-2007 13:50 PDST
    It would be good to get more feedback about any problems when trying to introduce a new DataHandler - since there is currently only one I'm certain bugs exist, so patches to fix issues are very welcome. Alternatively, given a stack trace or similarly detailed bug report I should be able to make any needed fixes during my copious (ha!) free time. Making JAMWiki easier to extend and modify is high on the priority list, so if I can help to make the process easier I'd like to do so. -- Ryan 26-Mar-2007 21:29 PST
    [Edit]

    More flexible namespaces with more consistent names

    The "Comments" tab isn't consistent with the "edit" or "move" or "print" verbs, and it isn't consistent with the "talk:" prefix or "discuss" verb used in mediawiki (which admittedly aren't consistent with each other). Also mediawiki hardwires several namespaces ("help:", "user:", "template:" and the project name) which are actually all part of the project, as are the talk/discuss/comment pages. There's a complete analysis of all mediawiki's command and namespace ontology/naming problems you may wish to read. While "comment" might be fair both as a verb and as a description of what you're going to see (comment[on]article), the plural does nothing but interfere with reading "comment" as a verb and add an extra letter. Going back to "talk:" and "talk" makes sense for a bunch of reasons, not least of which is allowing for later chat integration and consistency with the vast array of information on "talk pages" in every mediawiki. A better solution would be to specify which namespaces are part of the project and shouldn't be exported with the data, ideally also giving each their own copyright status (the help files might be CC-by-sa while content is CC-by-nc-sa or something) and to let that be customized along with the control system.

    [Edit]

    Wiki Syntax: Page properties as variables

    I would like to add processing instructions within the markup of JAMWiki. For instance the following should be possible:

    {{page.MaxTocDepth = 2}}

    This property should then be understandable by the WikiModel to not generate a TableOfContents for h3, h4.

    I missed this comment originally, sorry! Feel free to add a comment to Roadmap#Unscheduled about this idea. It sounds like a good idea, but I won't personally have time to work on it for a while. Alternatively, if this is something you'd like to work on please start a "Tech:" article on the Current Development Status page. -- Ryan 15-Apr-2007 23:24 PDT
    [Edit]

    Display backlinks as navigation help

    Hi! I'm trying to build up a little JAMWiki as a knowledge base which has a few structured "base" pages from which the content is linked. I would like to be able to display the Special:LinkTo pages (i.e. pages that link to the current page) somewhere in a page (let's say at the top of the page). So you can see where you came from and can go back without having to click on the "Links" tab. Unfortunately I was not able to enable the sublink feature which would allow a real hierarchy and a "link history" : base page -> subpage -> subsubpage (which would even be better than only seeing the backlinks).

    User:DiegoB 07-Aug-2007 04:59 PDT

    If I understand your request then there are two ways I've seen this handled on other wikis, and I'm sure there are numerous others:
    • Some wikis, such as JSPWiki, display a trail that the user has followed to reach the current page.
    • Wikitravel has created a Mediawiki extension that allows articles to be placed into a hierarchy - see http://wikitravel.org/en/Yosemite_National_Park, which has a navigation bar at the top showing that Yosemite is in California, which is in the US, which is in North America.
    There may be others - if you had something different in mind please let me know. Currently JAMWiki does not offer any comparable feature - categories are close, but not exactly what it sounds like you want - but feel free to add something under Roadmap#Unscheduled and it could be considered for a future release. Alternatively, if you're comfortable with Java feel free to write up a proposal (see How to Help). -- Ryan 07-Aug-2007 09:01 PDT
    Displaying a trail that a user has followed to reach the current page was exactly what I had in mind. Currently I'm trying to implement it. Maybe it could be added sometime. User:DiegoB 08-Aug-2007 05:26 PDT
    [Edit]

    Set prename without changing password

    Hi Folks, Hi Ryan, I tried to change my Account:Settings (Special:Account). I tried to add my prename and lastname without changing my password, but I failed. ;-/ Don't you think a user should be able to change only a part of his account settings? Greetings -- Michael Habbert 29-Oct-2007 00:23 PST

    You should be able to change any field without changing the password, but you need to enter your old password to do so; it's only if you enter a new password that the password is changed. Some help text on that page would probably make this fact clearer, so I'll have to try to remember to add it. Alternatively, if there are other suggestions for improvement please add them below. -- Ryan 29-Oct-2007 22:14 PST
    [Edit]

    displaying local time in signature

    Hi Ryan, hi folks, Every time when I make a note on jamwiki.org, I do like the feature (don't know how to call it) ~~~~. But: I would prefer to set (as a personal preference for example) my timezone. So it would be more visible from where all over the world people are connected to jamwiki. And so for example: 05-Nov-2007 11:32 PST would be displayed as 05-Nov-2007 20:40 ECT ;-)) -- Michael Habbert 05-Nov-2007 11:34 PST

    [Edit]

    Inline Linking

    Moved from the Feedback page:

    Is the Inline Linking feature available in JAMWiki? If not, I would like to add HTML code into the wiki editor and render it by JAMWiki. How can I do it? Thanks.

    Inline linking is not allowed. Have a look at the "Links" section of metawikipedia:Help:Wikitext examples for the link (and other) syntax. -- Ryan 17-Apr-2007 20:44 PDT
    [Edit]

    OpenSearch

    From Wikipedia: "OpenSearch is a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation."

    In short you get a rss-feed as an result of a search request.

    [Edit]

    Memorizing of page

    It would be very commodious if one would be lead back to the last page browsed after logging in instead of being shown the start page. --Frank 14-Nov-2007 02:00 PST

    Without tracking every page a user visits it would be tough to know what their last visited page was, but it might make sense to make the user's "start" page configurable. There are actually a number of preferences that would be good (timezone, start page, signature pattern, etc). Thanks for the suggestion. -- Ryan 14-Nov-2007 21:21 PST
    [Edit]

    Reset user passwords as admin

    I'd like to be able as admin to view a list of all users and reset their passwords if necessary! --Michael-O 23-Nov-2007 01:54 PST

    This is a much-requested feature that is probably overdue for inclusion. If no one beats me to it and I don't forget I'll put this at the top of the to-do list for JAMWiki 0.6.3. -- Ryan 25-Nov-2007 13:01 PST
    Hey Ryan, is this password reset by admin feature implmented in 0.6.3 ? --Durga 24-Apr-2008 12:04 PDT
    This one got missed and is not yet available. If it's something you need please keep adding reminders and I'll be sure to get to it soon - there is a lot going on right now, so for something that's important a weekly reminder is helpful, and indicates that a particular feature is important. -- Ryan 24-Apr-2008 15:48 PDT
    Ryan, spite some cross-posting this is one of the features I wanted to provide to jamwiki when I get the system up and running. I will propose some very drafts asap.

    revision 2198 will add this feature for JAMWiki 0.6.6. -- Ryan 27-Apr-2008 11:04 PDT

    [Edit]

    Missing user password

    Moved from the Feedback page since this is on the same subject

    Hi folks, I've installed jamwiki-0.4.2 (hui such an old version;-) and added me as first user. I enterd a lot of data and now after a wile editing without registration I do not remember my account-password. What is the standard handling in such a case? I in fact do know my admin account data, but do not know what to do? Any advice? Is there a mechanism to reset the user-password or something similar? Thanks in advance. : Michael Habbert 17-Dec-2006 12:03 PST

    Hi Ryan, I just visited my user account - and recognized prename and last name for my account was empty and I was not able to add them to the profile - while the system told me this user-name is not avaliable. Thats right but so there is no way to change some account data. Your Michael Habbert 17-Dec-2006 12:35 PST
    Just a note to say I'm not ignoring the comments you've left, but I've been crazy busy and will have to get to them later this week. A quick answer, however, is that for security reasons passwords are stored using a one-way encryption, so there is no way to read a password from the database. The only workaround I can think of is to execute SQL to copy a known password value from another user account to the account that you've forgotten the password for. Longer term I guess we'll probably have to come up with some way to reset passwords... -- Ryan 17-Dec-2006 23:11 PST
    [Edit]

    XML-RPC API

    It would be nice, if someone can port the Confluence/XWiki based XML-RPC API to JAMWiki:

    This API is needed on the server to rewrite the XEclipseExtension into a JAMWiki Eclipse plugin

    which could be merged with features from the Wikipedia Eclipse editor:

    Bump. Haven't looked at this yet (busy lately) but don't want it to get lost. -- Ryan 04-Dec-2007 08:47 PST
    [Edit]

    Set the default language on the translations page

    A nice to have:

    • The language setting on the translations page should default to the language being selected based on the browser setting. If a translation that matches the browser setting is available, that should be used as the default. If not, "en" should be used as a default.

    Possibly, you just forgot this one:

    • The list of languages in the pull down list lacks "en" and "ja".
    Defaulting to the browser language should be easy to do - please remind me if I forget :) As to why "en" isn't appearing, the list currently displays the extensions from all current ApplicationResources_XX.properties files, and since "en" is the default (ie ApplicationResources.properties) it doesn't appear as an extension. If needed it would be easy to change the "blank" option to "en". As to "ja", it should be appearing - I see it when I look at Special:Translation, so if you aren't seeing it for some reason let me know and I'll investigate. Thanks for the suggestion & bug report. -- Ryan 05-Dec-2007 16:01 PST
    As of revision 1950 the page should now default to the user's default language. Additionally, "en" should now appear in the list of languages. I haven't yet copied the new code to jamwiki.org will will probably do so in the next 1-2 weeks. -- Ryan 09-Dec-2007 09:15 PST
    [Edit]

    Sort untranslated texts to the top of the page

    Also nice to have:

    • sort all untranslated texts to the top of the translation page or add something like a "filter button" which shows only untranslated entries. Axel Kramer 09-Dec-2007 13:41 PST
    Without investigating the code, it seems like it might be possible to do a diff of the translation file against the ApplicationResources.properties file to return those values that are the same. I really appreciate the work that all of the translators do, so any way to make that easier would be a good thing... -- Ryan 14-Dec-2007 18:47 PST

    Hi. You've done it Ryan, but almost. As a Japanese guy, I got "ja" shown as my default selection in the drop down box, but the translation text shown in all the text boxes are English. So I have to hit the "change" button once to actually get the Japanese translations shown. Maybe you are aware of this behavior and you're just half way through implementation. And thanks for your time working on my feature wish.

    That's a bug... I'll have to retest and see what I missed. Thanks for testing! -- Ryan 19-Dec-2007 08:26 PST
    revision 1963 should honestly and truly fix the problem - it works for me on both my laptop and on jamwiki.org, but let me know if you have any issues. Thanks again for double-checking me! -- Ryan 19-Dec-2007 22:31 PST

    revision 1997 adds a checkbox to to Special:Translation to "hide untranslated values". This option isn't perfect - it simply compares values against what's in ApplicationResources.properties and hides anything that differs - but it should hopefully be helpful to those doing translations. As always suggestions and reports of any problems are appreciated. -- Ryan 19-Jan-2008 10:32 PST

    [Edit]

    Delete unused pages by administrator

    It will be nice to have a way to delete all the unused pages by administrator.

    Just to clarify, by "unused" do you mean pages that have no links to them (ie orphaned pages)? At present there isn't any way to view orphaned pages in JAMWiki, but with some tweaking it would probably be doable to implement. -- Ryan 13-Dec-2007 21:46 PST
    [Edit]

    Find all orphaned pages (pages not in a category)

    In MediaWiki there is a special page, I think it is called "orphaned pages". It lists all the pages that are not in a category. I would love to see this in JAMWiki.

    [Edit]

    Make "Minor Edit" a User Preference

    As seen in MediaWiki: A user can set "Minor Edit" to be the default for editing. Would be nice to have.

    [Edit]

    Comments & Mailing List

    Moved from the Feedback page

    [Edit]

    Comments

    What is the difference between the Comments and the normal Article, beside that they occur on different pages? Is there the possibility to deactivate Comments? Tom 2007-01-26

    Please take a look at metawikipedia:Help:Talk page which explains talk/comment pages. At present there is no way to disable talk pages - if there is a valid use case for doing so please describe it here and it could potentially be added to the to-do list. -- Ryan 27-Jan-2007 01:44 PST
    You could add a capability to edit comments or not, so an user without that capability cannot edit talk page. So you can have, for example, unregistered user that cannot edit talk pages, and registered user that can. Also see below my other proposal -- Michele
    [Edit]

    Add Comments

    What you think about the possibility of add the Wikipedia "+" comment function? In such a way you can simply add a comment instead of edit the whole page.

    Also it could be interesting to add the "+" in addition to edit of each topic, so you can add an indented comment to an exisiting topic/discussion. Lastly, if this feature is implemented, you can add the capability to distinguish EDIT_COMMENT to ADD_COMMENT, allowing some users only to add comments but not to edit them. -- Michele

    Feel free to copy this to the Feature Requests page - it sounds like it would be a worthwhile addition, and most likely wouldn't be too hard to implement, although I'm writing that without having actually given any thought to what would be involved :) -- Ryan 28-Oct-2007 17:55 PST
    I would like to try to implement it but I am not sure how to proceed. I would simply get the code and sent you a patch but I am not sure how to announce other I am doing it. I think a mailing list would be very useful to keep current, so I cannot understand why there is not one... -- Michele
    Have a look at How to Help#Programmers. And the reason that there isn't a mailing list is because wikis are better for collaboration :-P However, I agree that it would be useful to have some way of sending email to alert people when a topic is updated. And note that there is a mailing list that tracks Subversion commits - the address is provided in the How to Help page. -- Ryan 29-Oct-2007 22:26 PST
    I have read it. However I feel a bit uneasy in using a wiki to discuss implementations, this way only people looking in the same place know about, while with a mailing list everyone knows. Also I do not feel that one should be listed as a developer until he sent some patch to the main maintainer. Also I do not understand exactly who should setup a page telling that some one is trying to develop something, and who will merge the result in the trunk. A simple mailing list sequential solve all these problems: one announce the intention, the main maintainer agree, the new collaborator sent the patch, the maintainer accept or refuse it; after some time if the developer does a good job obtain access to the repository, has some autonomy and discuss with the mailing list what is doing. Without it I lose my personal vision of how the development usually proceed... I see good the wiki to write documentation, but I feel the development is a bit different. Just my 2 cents. -- Michele
    If there is enough demand then a mailing list could definitely be started; however, my (obviously biased) opinion is that the need for a mailing list indicates a failure in the wiki process. There is a saying that a company eat's its own dogfood when it uses its own products; as much as possible I'd like to see that done with JAMWiki, too. -- Ryan 31-Oct-2007 19:12 PST
    +1 for a mailing list, I noticed that even the group that develop mediawiki has a mailing list. While I am entusiast about the wiki concept, and agree about eating our own dogfood, there is another concept: use the right tool for the job. I feel that looking at the recent changes and diffing the is NOT the best tool to stay current and share ideas about development, not to mention voting about decisions and get jobs assigned. -- Michele
    [Edit]

    forward back on working page

    Hi Ryan, while im working a little bite more on jamwiki I request a feature: When I look around on the jamwiki site I see something, somewhere I whant to add a note to it, so I do register by clicking the link on the top left. So far so fine. But then I have to search for the topic again to do my changes ;-/ So what do you think about a redirect to the page from where the user started befor he registers? Did I make myself clear? -- Michael Habbert 02-Feb-2008 07:47 PST

    One of my co-workers requested the same thing yesterday, so this feature would definitely be worth investigating. -- Ryan 02-Feb-2008 09:35 PST
    [Edit]

    SSO support

    Single sign-on support for portals, containers and whatever would be cool to implement in this wiki.

    Wikimedia wanted to do this using the jabber ID. OpenID could also be used.
    [Edit]

    general purpose import of all pages from mediawiki or another jamwiki

    The descripton of XML import is arcane and doesn't explain how to use it to generally import a whole mediawiki or use existing online wiki services as a base to import articles/frame pages.

    [Edit]

    static

    Static import means identifying a mediawiki or its SQL database and sucking it in to jamwiki, choosing manually on a form which namespaces to include. May require dealing with one-time conflicts when names are being overwritten, with policies such as dumping the losing page to the talk/comment/discussion page associated with the winning page.

    This is primarily useful for those moving to jamwiki from existing mediawikis.

    [Edit]

    dynamic

    Dynamic import means identifying which of several mediawikis, jamwikis, or even other wikis supporting XML import, contains an authoritative article on a subject, and instructing jamwiki to import it when there's an open link to it. Wikinfo does this with Wikipedia, importing every page not native to Wikinfo. Tikiwiki has a general facility of this nature.

    It's extremely useful for intranets since you don't want to define every damn term in the language, you just want to refer people to relatively standard ones in Wikipedia or some fork of it like Wikinfo, without having them leave your corporate wiki.

    [Edit]

    Dumping Wiki

    Moved from the Feedback page:

    Yo, guys. Is there a possibility of dumping my whole wiki in an HTML doc (many HTML pages)? --Zajoman 05-Sep-2007 13:09 PDT

    Not yet, but it probably wouldn't be hard to build. I don't have time to work on it at the moment, but if you're a programmer feel free to throw some code together, or you can add a request to the Feature Requests page. -- Ryan 05-Sep-2007 14:41 PDT
    [Edit]

    Prefer lowercase

    Moved from the Feedback page:

    It's horrible English to capitalize everything, please go to all-lowercase as fast as you possibly can. Capital letters in page names are the most destructive habit in wiki, as they prevent just linking things casually in sentences, and you encourage that with unnecessary capitals in "special pages" and "recent changes" and "starting points". WikiWords also need to be eliminated for the same reason. No mediawiki user uses them after a few weeks, when they realize the nasty problems that they cause.

    This is not a style choice. Look at wikis that succeed and you'll see that they are rigorous about using capital letters only where English (or the natural language) does. This is what makes casual internal linking easy. Also mediawiki uses the wise convention of being case-insensitive on the first letter, just as English is, because the link may come at the start of the sentence. I've been using wiki as long as it's existed, and it makes me physically and viscerally angry to see "Edit Comment" capitalized like that - aside from the fact that mediawiki calls it an "edit summary" and a serious project using mediawiki will have lots of documentation talking about the "edit summary" and none talking about the "Edit Comment". You will turn off literally all the most experienced editors with these defaults, as they've all spent months and months of mindless grunt time correcting bad capitalization in page names and correcting bad links to slightly different names for the same things that they learned from other wikis. For a long time new wikis went to seedwiki just because it was in all-lowercase, and the gurus didn't want to be wasting their time correcting bad page names abusing uppercase.

    [Edit]

    Howto: Direct database access

    Moved from the Feedback page:

    After fiddling around for hours, could anyone (hi Ryan ;) help me accessing JWs internal database with hsqldb's sqltool (e.g. table name)? BTW: is adding content to JWs database straightforward? Any traps? We want to add program-generated information to JW articles. --fmr 25-Jun-2007 03:24 PDT

    I've honestly never tried to directly access HSQL when it is installed as the JAMWiki internal database. The original intention behind including the HSQL option was so sites with simple wiki needs could get up and running easily - for sites with more complex needs I'd recommend installing a standalone database. That said, the connection settings for HSQL would be:
    JDBC driver: org.hsqldb.jdbcDriver
    URL: jdbc:hsqldb:file: + path to SQL files + jamwiki
    User: sa
    Password: blank
    Hope that helps! -- Ryan 25-Jun-2007 09:06 PDT
    Alas it doesn't for that's how far I got, but thanks for your reply. I am able to connect to that database, but I don't know anything about it's structure, and hsqldb documentation didn't make it plain to me. Regarding the standalone database issue, I'm forced to run JW on a server running an elderly MySQL not supporting UTF-8...hmmm, while writing it occurs to me that I might be able to use a more recent MySQL on a remote machine, guess there's nothing here covering that issue, the same with moving contents from hsqldb to MySQL... -- fmr 26-Jun-2007 01:21 PDT
    Could you share with us how you connected? It seems that there are plenty of people interested. Me for instance, I am trying to establish a quick mechanism for importing/exporting JAMWiki information easily.
    Sounds promisingly. Currently I am able to access via 
    java -jar /usr/share/java/hsqldb.jar --sql "select * from jam_wiki_user_info" jamwiki
    with ~/sqltool.rc containing 
    urlid jamwiki
url jdbc:hsqldb:file:{PATH_TO_JAMWIKI}/jamwiki
username sa
password
driver org.hsqldb.jdbcDriver
    This way selecting works, but deleting or updating data does not. -- fmr 30-Aug-2007 03:17 PDT
    [Edit]

    Missing tabs

    Moved from the Feedback page:

    Feedback of a user after upgrading to 0.6.0: he misses the page edit tab when not logged in. So far he was forced to log in when clicking that tab. After entering his login data JW directs him to the article he just wanted to edit. Now one has to log in via the top right link which directs always to the start page. A little loss of convenience, but I understand the user's impatience. -- Frank 12-Sep-2007 04:51 PDT

    I suspect that's the new security code. If you go to Special:Roles, are the box for "ROLE_EDIT_NEW" and "ROLE_EDIT_EXISTING" checked for GROUP_ANONYMOUS?
    No, they are not!
    By default they should be, but I think you indicated there were some problems during an upgrade so it's possible that setting wasn't updated properly. And for the record, updating the documentation for the new roles code is on my to-do list, so hopefully there will be useful documentation for that feature soon. -- Ryan 12-Sep-2007 07:56 PDT
    Checking the aforementioned boxes does not yield the desired behaviour because I don't want anonymous to edit pages. -- Frank 13-Sep-2007 01:50 PDT
    So if I understand correctly, the requested functionality would be to display the edit tab, and if the user is not logged-in when he clicks on it then he will be redirected to the login page prior to being allowed to edit? It could probably be made a preference to display the edit tab even if the user does not have editing permissions - please let me know if that would be helpful. -- Ryan 13-Sep-2007 09:24 PDT
    And how! The one missing it very most is sitting three meters in front of me ... -- Frank 13-Sep-2007 09:37 PDT
    [Edit]

    Is there any other stylesheet available for Jam wiki?

    Moved from the Feedback page:

    Hi Ryan,

    we want to change the stylesheet to match out websites. If you have any other stylesheet other than blue theme, please share it with us. --Durga 15-Nov-2007 09:16 PST
    There is currently only one default stylesheet, but you can customize it by editing the StyleSheet topic on your wiki. Note that when upgrading your changes will be overwritten by the upgrade process, but they are saved in the StyleSheet topic history so they are easy to retrieve. -- Ryan 15-Nov-2007 10:57 PST

    my question is is there any plan for another themes out of the box from Jam wiki. than just blue theme. --Durga 19-Nov-2007 14:04 PST

    I'm not very good with look & feel so alternate stylesheets aren't something that I'm working, but I'd love to see submissions of alternative StyleSheet CSS and would be thrilled to include those alternatives in future versions if someone contributed one. In addition, I'm more than willing to make any modifications to the JAMWiki code to make support of alternative stylesheets easier. -- Ryan 19-Nov-2007 14:15 PST
    [Edit]

    Opening External Pages in Another window

    Moved from the Feedback page:

    When we give the links for external websites, the link is opening in the same page, i have them opened in separate window than in the same window. How to enable that in jam wiki? --Durga 06-Dec-2007 11:41 PST

    You should be able to open external links in a new window by enabling the "Open external links in new window" option on Special:Admin#General settings - see Configuration#General settings. Let me know if you have any trouble. -- Ryan 06-Dec-2007 12:18 PST
    [Edit]

    Upload into DB

    Moved from the Feedback page:

    Hi Ryan, first I want to thank you all for that great wiki! Now we are still running a test server with Jamwiki. but in productive case it will be a weblogic 8.1.5 server with NO write access. the only way out is to write into an Oracle-DB. It functions except the upload of files. Is it possible to change the wiki to upload files in a DB (i.e. Oracle)?

    Currently there is no way to upload files directly into the database, but since a few different people have requested that feature it may make sense to add it. It would need to be done as an optional feature - I'm envisioning and "UploadHandler" interface with retrieveFile() and storeFile() methods - but it probably won't get done for a while (I would guess several months). What is your timeline for going to production? Is it 1-2 months, 3-6 months, or a matter of weeks? -- Ryan 10-Dec-2007 07:43 PST

    We are going to production at the end of january 2008. We well release even if this feature is available or not. but it would be (very) nice if users could upload their images ;-).

    [Edit]

    HTML to Wiki converter

    Moved from the Feedback page:

    Is there any plugins or tools avilable to convert the HTML content or a word doc content to WIKI format for jamwiki? i saw one for mediawiki, the tool name is WikiEd, can we use them for Jamwiki too? --Durga 12-Dec-2007 07:51 PST

    Since both Mediawiki and JAMWiki use the same wiki syntax then a converter for Mediawiki should also work for JAMWiki. Note that JAMWiki does not yet implement the full Mediawiki syntax set, but it covers the majority. If you find any issues please report them here as it will help to identify any functionality that JAMWiki is missing. -- Ryan 12-Dec-2007 08:18 PST
    There's a simple HTML to Wikipedia syntax converter included in the Java Wikipedia API you can test the converter online at JTidy.de Axel Kramer 21-Jan-2008 12:28 PST

    i tried with WikiEd, but it is not working in Jam wiki, working fine in media Wiki. could you please check. --Durga 09-Jan-2008 01:01 PST

    You'll need to provide the specific syntax that isn't rendering properly in JAMWiki. Most of the people who contribute to this project don't have a lot of free time available, so without a detailed bug report there won't be much anyone can do. -- Ryan 09-Jan-2008 13:28 PST
    [Edit]

    Block IP, ban user using multiple IPs or accounts

    An unfortunate but necessary feature required of any popular Wiki is the ability to block certain users. While my personal belief is that most annoyances can be handled better by simply reverting vandalism, more sophisticated attacks (such as automated or scripted attacks) require a block as the only reasonable way to stop a vandal. It should be possible to block users at both an IP and a username level.

    Just make sure you are correctly identifying WHAT is being blocked. It is an IP number, or an account, or a person/user who may have multiple accounts, i.e. the intent is to block all accounts or IP numbers proven beyond some threshold to belong to that person/user, which is not at all the same thing as blocking an account. Keep the terminology straight, you can "ban" (administratively choose to prohibit) a user but you can only "block" an account or IP number. These are different operations at different levels of abstraction and intent.
    This feature is called "host blocking" at wikimatrix and MediaWiki already has it.
    [Edit]

    User/Group permissions

    "The 0.6.0 release WILL offer fine-grained permissions, allowing a site administrator more control over limiting what users are allowed to do -- see Tech:User Permissions. I'm hopeful that the release will happen before the end of the month." Ryan 10-Aug-2007 19:14 PDT

    Did this actually happen? If so what exactly was implemented?
    I would just love to use the user/permission system from leading forum software like vBulletin, PHPBB, IPB, etc.

    Holger Engels proposed "a permission for every item (function/ data) worth protecting. Permissions can then be bundled as Roles (i.e. nobody, user, admin, ...) and Roles can be assigned to Users. This is more flexible, because then one can freely define new roles."

    Use cases should be raised in Tech:User Permissions where several already exist. Detailed discussion of use of roles, integration with multiple virtual wikis, categories and namespaces also belong on that page.

    [Edit]

    ACL

    Longer term goal is to implement an ACL-based permission scheme allowing various Wiki actions to be assigned to users or groups. This is an extremely complex feature that can very easily be abused, and many exploits are possible to defeat such systems.

    It's likely to be a classic ACL system - an admin defines a group consisting of users and (possibly) sub-groups. There will then be a series of actions that can be assigned to one or more group. For example, there might be a translator action (access to Special:Translation), a web design action (access to StyleSheet, BottomArea, TopArea),

    PLEASE PLEASE PLEASE don't use disastrous "WikiWords" to name the permissions. Put these in a namespace properly, like project:style_sheet, project:bottom_display_area and project:top_display_area. And for God's sake do NOT use WikiWords in the names of permissions, use sane readable English language phrases separated by underscores, which is the reason Wikipedia is big and other wikis never are.

    a site admin (ability to delete pages, make pages read-only, etc), a sysadmin (access to Special:Admin), etc. The tricky part will be implementing this in a way that is/could be compatible with existing LDAP solutions, and also doing it in a way that doesn't kill performance.

    I'd just like to second this as a feature I'd like. Particularly to have a privilege that allowed editing of pages Oliver 13-Oct-2006 08:09 PDT
    This will probably end up being the first feature worked on for 0.5.0 - it's long overdue. -- Ryan 13-Oct-2006 11:58 PDT
    It's very difficult to do right. Interaction with multiple virtual wikis, with categories and namespaces, need to be thought through and designed, not arise by accident.
    [Edit]

    integration with Apache?

    Users who "want to restrict the write-access to authenticated and approved users" such as Tom should use apache passwords on "edit" URLs. Within jamwiki Ryan says they "can currently prevent non-logged in users from editing by selecting the "Force setting of username" option from Special:Admin - that label isn't very clear for the checkbox's purpose and will probably be changed for the next release."

    [Edit]

    LDAP

    I love what you've done so far. I am eagerly awaiting an LDAP implementation also. This is the only thing keeping me from implementing JAMWiki for my workgroup right away. Any idea when this feature might be available? I'm dying to get this app up and running in my shop. Even if it was just to simply authenticate to track a users changes (for accountability). Fancier role-based permissions could be added later. hexC0DE 10-Aug-2007 10:21 PDT
    There is currently experimental LDAP support available that allows the use of an LDAP system for authenticating users - I've done minimal testing with open LDAP, but I don't really use LDAP much so it will be marked experimental until other users can provide some feedback on whether it works for them or not. I would eventually like to use whatever LDAP support Acegi offers, but without a good way to test I've been putting that off and hoping someone else would pick it up.
    [Edit]

    NO fine-grained permissions - contrary position

    There is a contrary position that deserves representation as it may influence some aspects of implementing this, and at least prevent the worst errors and misfeatures.

    Fine-grained permissions in the wiki itself have several serious problems:

    • they interfere with collaboration by removing the assumption that everyone can edit every page, people can no longer ask each other to do things for themselves if there are many pages that those asked may not be allowed to edit
    • they could interfere with a publishing mechanism (which would probably be blog-like) that would have its own permissions scheme requirements
    • they would be redundant with existing web-server-based permissions and probably interfere with those too

    Until how the interaction with the web server, a publishing/blog mechanism and the social patterns of the wiki is clearer, implementing gACL should be put off. Apache integration needs to be very carefully thought through, as does multiple virtual wiki integration. Then namespaces. Then categories. Only when the implications of permissions associated with all of these is a lot clearer, should a separate permissions system per page start to evolve.

    Intellipedia, the US intelligence community's massive mediawiki, don't use or need fine-grained permissions. They rely on perimeter protections and the web server. If that works for them, why not for everyone else?

    [Edit]

    at least make them really easy to turn off post-facto when they get screwed up

    At the very least all fine-grained permissions must be able to be turned off post-facto with one click in the configuration. They are almost always so badly designed that they destroy any chance of collaboration and even very experienced administrators often have to redo them every few years or so.

    [Edit]

    captcha and solve-this are permission levels

    A captcha or solve-this-number-puzzle utility is also required because spam filters are hard to configure and often problematic. It needs to be integrated with the permissions system since "allow edit with captcha" is a permission level. It's also a mediawiki extension.

    Even if there's no other permission system, this needs to be supported.

    [Edit]

    Status Update

    JAMWiki 0.6.0 introduced a basic user permission system. It is undergoing additional enhancements, and may be significantly modified once the next major version of Acegi is released. -- Ryan 23-Mar-2008 10:37 PDT

    [Edit]

    Credits

    For licensing purposes there should be a credits block on the bottom of each page with links to the user pages of all users who have contributed to an article. Because this isn't universally desirable, including should be a checkbox option with the fact that this is required by GFDL and CC-by licenses noted beside the checkbox.

    [Edit]

    integrate into BottomArea, make easy to remove

    There are problems when dealing with IP numbers and multiple pseudonyms. Like everything else dealing with licensing and copyright and credit it should go in the BottomArea by default and be easy to remove. The default checkbox would then only determine whether it was included by default in a given install.

    [Edit]

    CC+ support ?

    The CCplus protocol is a simple standard way to request more rights than a CC license requires. CC0 is for certifying that there are no rights or that a work is public domain. They are easy to support if a CC license is in use, putting the appropriate logos in the appropriate places, possibly the BottomArea. Technically this is a permissions issue since it's legal but since it may involve contacting the people listed in the "Credit" it should be considered as part of that feature. For instance if someone has used the CC0 or CC+ protocols to grant specific rights to a page then its copyright status is easy to determine with a program, and this might be used to determine, for instance, whether the source text of a page is displayable or not.

    [Edit]

    XML Export

    XML import and export is useful for complying with open source licenses such as the GFDL and the CC-SA license, as it allows the full history of an article to be downloaded and credited. However, while this feature may be implemented in some form to allow for testing using data from other wikis, it will probably not be implemented as a fully supported feature for a while.

    I really would appreciate it, if this Export/Import feature could be used to backup and restore the whole content. JIRA has a very smart feature: a backup-task can be configured to create backups in a regular intervals and store them zipped on the server's file system. Beside that, it also allows to import and export the content as XML which is very useful upgrading to a newer version. Tom 2007-01-26
    Obviously being able to import an entire MediaWiki XML dump would make it a lot easier for enterprise users who've already started an MW instance to migrate. --Evan Prodromou 05-Apr-2007 06:42 PDT
    See also Tech:XML import. -- Ryan 05-Apr-2007 23:25 PDT
    There's now also Feature Requests about this, asking for both static and dynamic (Wikinfo-like) import.
    [Edit]

    Getwiki/Wikinfo-like whole-wiki import

    The extremely strategic and useful feature of Getwiki (a mediawiki fork) is that it draws in an entire wiki and populates all pages that are populated in that other wiki, and then lets users merely specialize and customize the pages. This is how Wikinfo works and it's how most organizations SHOULD use wiki content. That is, NOT write most of it themslves but rather import and specialize. Getwiki/Wikinfo uses some color coding to tell users which articles have been imported and which not.

    Being able to nest wikis in a multiple-wiki cascade would make jamwiki extremely useful for projects that, like most in a private corporation, have multiple layers of security.

    [Edit]

    Anonymous user talk pages

    Add talk pages for anonymous users. Mediawiki has them: The user name is the IP address.

    [Edit]

    Mediawiki compatibility

    This wikimatrix comparison helps to pinpoint some problems with mediawiki compatibility. The syntax section of the JAMWiki entry needs update so that it is clearer that the intent is to exactly mirror MediaWiki syntax. That needs to be stated clearly in several entries, else it will be very misleading. WikiMatrix itself should make it easier to find compatible syntaxes and should allow MediaWiki compatibility intent as a field, just as it does with the now-dead WikiCreole non-standard.

    Wikimatrix lists the following features as available in mediawiki but not in JAMWiki:

    [Edit]

    syntax

    JAMWiki supports the same strikethrough (s) and center (center) notation as mediawiki but Wikimatrix says not, that strike and div are used instead. This prevents JAMWiki and Mediawiki from showing up as supporting identical syntax, critical for spreading JAMWiki. Checks need to be made to ensure they really are being treated identically.

    [Edit]

    backlinks

    Next to identical syntax, this is probably the most important feature. It's really difficult to find out what links to a page unless this is supported universally. Mediawiki has a "what links here" feature (that really should be called "What links to this page" to avoid unnecessary spatial metaphor, "here" is a priveleged real world concept when you're working on oh say any mobile application). TikiWiki lists backlinks on a pulldown menu, and it would be nice to do this ALSO in JAMWiki (but still support a dedicated page for them that can be picked up by a bot. TikiWiki also makes it easy to include a macro to list backlinks in page text, or even to list an RSS feed within a page.

    This is supported in JAMWiki - every page has a "Links" tab. For example, http://jamwiki.org/wiki/en/Special:LinkTo?topic=Roadmap shows all pages that link to this page. It could probably be updated to use a page name that matches Mediawiki. -- Ryan 07-Feb-2008 21:11 PST
    [Edit]

    wanted/orphaned/most/least popular

    These names for Special pages are very unfortunate as they overlay some unnecessary and misleading language on top of the functions. The best way to support these features is to support the mediawiki names for them but also simultaneously (without an option turning them off) support more operational names that say exactly what is being displayed:

    For instance, calling the list of open links that, and supporting "Special:open_links" or "Special:all_open_links" (letting open_links be used with an argument to track those specific to a page or tree of pages) as a synonym for the POV "Special:Wantedpages". If this gets rid of the run-together words that create temptations to make up bad new WikiWords, great. Time for special page name to be readable in ordinary English and not require anchor text any more. There are persistent reasons other than "Wanting that page to exist" to open a link to it.

    As for "popular", it's beneath contempt. They are the "most_viewed_pages" or "least_viewed_pages" and that's all they are. It's not clear that humans viewed them nor why and this concept of popularity doesn't exist in the user interface nor in SEO talk either. Page views are what they are called in that lingo and the more familiar the Special page names are to SEO people the more will be using JAMWiki to get reports from it they understand.

    [Edit]

    feed aggregation

    RSS feeds are extremely important and having to subscribe to one per page or hav