Feature Requests

This page is for requesting new features. When requesting a feature please describe the feature in enough detail to make it clear what is being requested. If there is similar functionality in another wiki, particuarly Mediawiki be sure to note that and, if possible, provide a link to a description of the implementation. Features should be listed under one of the following sections:

  • Mediawiki Compatibility - For features that exist in Mediawiki but JAMWiki does not (yet) support. Please provide a link to the Mediawiki documentation that describes the feature.
  • Enhancements to Existing Features - For minor enhancements to existing JAMWiki functionality. Anything that breaks Mediawiki-compatibility or significantly alters existing JAMWiki functionality should NOT be listed here.
  • Other Requests. For all other requests.

Note: Feature requests are generally given more attention when there are enthusiastic users requesting the feature, so please add your name to requests that interest you and follow-up regularly to inquire on status.

Related pages include:

[Edit]Mediawiki Compatibility

[Edit]Included Template Links

While editing or previewing a page there ought to be links to the included templates at the bottom, like in MW. Otherwise there's no way to find a link to a template to edit it. -- Floating World 27-Oct-2009 07:54 PDT

[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]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]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]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]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]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]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

How about a link to other sites that use JAMWiki so at the very least we can copy and paste their StleSheets? e.g. http://www.linux.org.ru/wiki/en/StyleSheet

Have a look at Powered by JAMWiki, and feel free to add your own site to that list. -- Ryan • (comments) • 06-May-2009 08:16 PDT

[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]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]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 having to create watchlists just for this purpose is problematic. 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.

[Edit]recent visitors and other analysis

There are extensions that provide a lot of information about who's looking at what page.

[Edit]most transited links

The most useful features, which mediawiki does NOT support for commercial reasons related to the Wikia and Bomis corporations, would make visible the most-transited links between pages. This is critical to finding the paths people are taking through the data and improving it.

[Edit]"talk" vs. "comments"

This really is problematic. It's barely justifiable to call the namespace "discuss:" since that's the verb on the tab in mediawiki (it doesn't match the name of the namespace). But "comments" is not even a verb so it isn't like "edit" or "print" which imply something will be happening. Probably best to simply revert to mediawiki's usage for now and support namespaces better.

[Edit]simple flexible namespaces

As this extension documentation shows, mediawiki as of 1.7 was supposed to have simple namespace management so it wouldn't hurt to anticipate that and flex up the namespaces.

This is pretty important since Mediawiki-based services emphasize social software features while content management seems to lack.

Sigh - when is that dynamic inclusion of pages from Wikipedia going to work?

[Edit]export to other data types e.g. ODT, HTML

Mediawiki also exports to many other data types. See below under user interface.

[Edit]Cancel Button in Edit Mode

For usability we would like to have a cancel button in the editor. Shure, it's no problem to click the back button of the browser but for usability reasons i think a cancel button would be a nice feature.

Currently Mediawiki has a cancel link (instead of a button). I'd prefer to follow their lead in order to make JAMWiki as easy to use as possible for people familiar with that software, so if a link works for you then it would be easy to add. -- Ryan • (comments) • 24-Mar-2009 06:04 PDT

[Edit]Clean up inconsistent EN language translation

"StartingPoints" is a WikiWord beside "Recent Changes" which isn't consistent with the mediawiki "Special:Recentchanges", and while "Special:Specialpages" is, "Special Pages" isn't. This is a mess and it's very easy to fix:

  • Remove all capital letters after the first character as mediawiki does - remove all WikiWords from the interface everywhere, i.e. StartingPoints should become "project:entry_pages" or something which is more consistent usage of "pages", and clearly designated within the project name space only, so multiple projects could be accomodated on the same base of pages in one wiki.
  • Support the mediawiki capitalization precedents on Special:Recentchanges and Special:Specialpages and so on - note that special:recentchanges and special:specialpages are treated identically by mediawiki but not jamwiki as of 0.6.3
  • eliminate extraneous capitals, i.e. "SourceForge page" is fine, "Page" is not
  • absolutely eliminate all capital letters from the user interface by default, i.e. "Edit Comment" becomes "edit comment" or better, "edit summary" exactly as mediawiki calls it
    • Toggling between a proper-english no-capitals-except-on-proper-names and the existing crap is also an option, but the latter seems to have no advantage. It's inconsistent with mediawiki and with itself, and should go.
Someone care to fix the EN translation?

[Edit]Interwiki Link support like in Wikipedia

Could JAMWiki support interwiki links like in Wikipedia. I think therefore we need a similar method like

  ParserOutput#addCategory(String categoryName, String sortKey)

Which selects the categories for category-include.jsp? -- Axel Kramer 30-Apr-2008 09:19 PDT

Interwiki links should be shown below the LeftMenu in the default layout IMO. For example the German interwiki link for JAMWiki on http://en.wikipedia.org/wiki/JAMWiki looks something like this:

<div id="p-lang" class="portlet">
		<h5>Languages</h5>
		<div class="pBody">
			<ul>
				<li class="interwiki-de"><a href="http://de.wikipedia.org/wiki/JAMWiki">Deutsch</a></li>
			</ul>

		</div>
	</div>

So the method should probably look something like this:

  ParserOutput#addInterwikiLink(String cssClassName, String hrefName, String descriptionName)

[Edit]Multi-server Support

Currently some aspects of JAMWiki may limit installations to a single server - image upload adds a file to a single local filesystem, and file-persistency mode will only support one server. Some of these limitations can be overcome by using NFS mounts or a storage area network, but others should be addressed from the software itself.

[Edit]Mediawiki API Support

Mediawiki is now offering a somewhat standardized API for interacting with bots and scripts - see http://meta.wikimedia.org/wiki/API for details. While it is probably not feasible for JAMWiki to offer compatible support (JAMWiki is not written using PHP), it should be feasible to ensure that JAMWiki offers similar functionality.

I've taken a look into the API's wiki. The std API is no more than a Web Service offering various queries and formats. This can be done here too with Apache Axis 2 in a servlet container. Is there a need for at all? It would take some time to code but if no more than 10 % of the users will use it, it seems to me like a waste of time! --Michael-O
My thinking is that this issue is on the very long-term to-do list. It would be nice to have as a way of offering additional compatibility with Mediawiki, but there are features still missing from JAMWiki that may prevent a full implementation. That said, if someone wants to work on this they are more than welcome to do so, but for those who are just looking for some way to help there are other issues that are probably higher priority. -- Ryan 20-Jul-2007 16:57 PDT
Saying "if no more than 10 % of the users will use it, it seems to me like a waste of time! --Michael-O" is absurd. That ten per cent are by definition the most technically astute and advanced users who are integrating jamwiki into other applications, say on intranets or other products. Those are the most important users of any component or application. They drive everyone else's use and inhabit niches that competing wikis cannot. So there's really nothing more strategic than supporting mashups and so on.

[Edit]Support for API

This is somewhat of a continuation of the topic above, just simply an API for querying, adding, or editing pages would probably get the most use. It would be nice if there was a Java/Tomcat Wiki option with an API. More info/give feedback hereTech:Editing APIs

[Edit]SCRAPI - a contrary position?

Another, contrary, position, is that an API is a bad idea. A SCRAPI (screen-scraping supported as an API) will be used/found anyway by sophisticated users, so why bother "blessing" certain functions with a different API interface? Just make the actual URIs of the pages and functions that are invoked work just as well for mashups and other programs and front ends as they do for users of jamwiki's own web interface. This has several huge advantages:

  • there will never be a gap in the functionality, i.e. API doesn't do something the main interface does do, which leads to people screen-scraping it anyway
  • it forces strict URI discipline on jamwiki which removes garbage and cruft in URIs and forces them to be mnemonic and human-readable as all good URIs must be - it will also force verbs to be short and hierarchies shallow
  • it will encourage other end user Java components to adopt a similar approach and thereby copy the names of verbs ("save", "edit", "print", etc.) and functionality of jamwiki exactly, easing integration with those other programs

[Edit]Upload / Login should return you to the original page

The folks at work are angry that this doesn't happen and are threatening revolt. After uploading an image or logging in, the user should be redirected to their original page. There are several similar requests for this feature already on this page. -- Ryan 07-May-2008 09:52 PDT

revision 2341 will redirect a user to the page from which he/she clicked "login" (like Mediawiki does). Changes for upload are still to be done. -- Ryan 02-Oct-2008 22:27 PDT

[Edit]SVG Support

Add support to display SVG images. Currently, a

[[Image:image.svg]]
only inserts a link to image.svg, but inline display (like for JPEG, GIF etc.) would be a lot nicer. AFAIK MediaWiki is able to do this.
Currently JAMWiki is using Java's image handling utilities to distinguish images from non-images. For performance reasons and to allow handling of a broader array of image types it might be worthwhile re-visiting that code. Thanks for the suggestion. -- Ryan • (comments) • 16-Jan-2009 07:49 PST

[Edit]subst tag

Are there any plans to implement the subst tag (to use with templates) in the near future? It'd be great to get this functionality added.

This was added in revision 2884 for inclusion in JAMWiki 0.9.0. -- Ryan • (comments) • 20-Feb-2010 18:32 PST

[Edit]Allow External Images

Simple but I think it's important, example:

[[Image:http://jamwiki.org/wiki/images/logo_oliver.gif]]
This is actually a feature that I think would be really nice to have - does anyone know of any extension or plugin for Mediawiki that supports this functionality? I'd like to know what syntax is used and follow another example rather than inventing a custom implementation if possible. -- Ryan • (comments) • 17-Apr-2009 07:32 PDT

EDIT

Does this help ? http://www.mediawiki.org/wiki/Manual:$wgAllowExternalImages

Also, would be nice to 'be compatible' with long urls and spaces, like google graphs for example:

http://chart.apis.google.com/chart?chs=600x250&chtt=TITLE%20WITH%20SPACE&cht=lc&chxt=x,y&chdl=A%20AA%20|B%20BB&chco=FF0000,00FF00&chxr=0,0,30,2|1,0,40,2&chds=0,40&chd=t:40,36,32,28,24,20,16,12,8,4,0|40,39,38,37,36,35,30,25,23,21,18,14,12,9,1&chm=o,85FF00,1,-1,5

Perfect, thanks. This is a feature that I'd like to get implemented, so please feel free to add (gentle) reminders if the 0.8.0 release cycle drags on and I forgot to write some code. Thanks for the suggestion and follow-up. -- Ryan • (comments) • 17-Apr-2009 08:23 PDT

[Edit]Enhancements to Existing Features

[Edit]Authorization, permissions and other monolithic ratings

[Edit]Per-page Permissions

Allow some pages or namespace or whatever to be readable/editable/whatever based on user permissions. For example, the LeftMenu, BottomArea etc. are current editable topics, but only site administrators should be changing them. Similarly, it may be desirable to include content from mailing lists and other sources, in which case that content should be read-only (allowing changes someone's original email would be wrong and confusing).

Perhaps a new user group (call it "moderator" or similar) who has rights to make topics read only, and other types of low-impact admin tasks, but unable to do proper admin tasks (e.g. can't access admin pages). -- scroco 13-Aug-2006 23:07 PDT

This ties in well with the User/Group permissions functionality below. -- Ryan 14-Aug-2006 01:23 PDT

[Edit]File Download Permissions

Currently I'm using Jamwiki 0.6.6 Version. I could see that if any user having view authority is able to download the file attachments. Is there any role (ROLE_DOWNLOAD) for restricting Download feature based on user access. Please help me how to create this functionality. -- Venkat 13-Apr-2009 10:32 PDT

At present you can use ROLE_UPLOAD to restrict who can upload files, but there isn't a similar way to restrict downloads. It should be possible to configure Spring Security to protect the upload directory from users without a specific role - I haven't tried it, but general instructions are available at Configuration#Overview (note: documentation is for JAMWiki 0.7.0 or later, but Spring Security for 0.6.6 should also allow this functionality). Hopefully that helps! -- Ryan • (comments) • 13-Apr-2009 07:48 PDT

--Ya, I got it Ryan.First of all, I want to Thank you for quick response. Please help how to handle this scenario. I have 10 users in 3 different accounts(say bakery,cosmetics,medical). I have put a page level access for 3 accounts by changing the applicationContext-acegi-security.xml file. But if any registered user from (bakery account) does a search for document from (medical section), it is allowing him to download the document.If it is posssible to restrict while searching,then it would be very much helpful for me. Please help me if there is any way to restrict this access. Venkat 17-Apr-2009

[Edit]Implementing a UserHandler to access external user data

Archived from the Feedback page:

I am trying to setup a JAMWiki for http://publicpress.org , a site that already has a user base with its own set of usernames/passwords etc. I implemented a UserHandler but it only seems to get invoked if I try to login with a user that I have created using JAMWiki. I don't really care about the "All Users" listing etc, so there is a way to easily make JAMWiki completely depend on my UserHandler? It seems to do some checking against some notion of an internal list of users, then not finding the user I want to authenticate, doesn't even call my UserHandler.

JAMWiki needs to maintain an internal list of authors so that the wiki can determine how to credit each user. It is possible, however, to use an external system for authenticating those users. It sounds like the feature you need is for JAMWiki to automatically create a jam_wiki_user record for any user who is authenticated but does not yet exist in the JAMWiki database.
That's a pretty basic feature, but since no one has requested it before it was never included in the default wiki code. If it's something you'd be interested in adding let me know, otherwise if you're willing to wait a bit I can investigate when next I have time to sit down and write code. In either case, it's a feature that will eventually get added, it was just waiting for someone to come along who needed it :) -- Ryan 22-Oct-2007 21:25 PDT

[Edit]Create/Manage User Accounts for private Wikis

When using JAMWiki for a private Wiki you have to deny access to Special:Account for non-authenticated Users, to prevent others from registration. If you are authenticated, there is no possibility to manage other Accounts than your own.

I solved this problem for me with a little jsp (which I can submit, but it is ugly and german), of course the access to this jsp must be controlled by applicationContext-security.xml. A Spring Controller using the default layout for Special:-Pages would be more beautiful of course.

Wouldn't it be nice to have this - quite easy to implement - feature in standard jamwiki? --hp 07-Jan-2010 02:04 PST

It's definitely doable, and provided you're willing to check in on a regular basis to remind me to keep working on it I'd be more than willing to add it to the Roadmap for 0.9.0. I've got a number of things to get to first, so please just check in with gentle reminders on occasion to make sure this doesn't get overlooked - user enthusiasm plays a big part in getting things implemented :) Alternatively, if you want to push your version via Subversion we can work on cleaning it up together and getting it rolled into a release - let me know. -- Ryan • (comments) • 07-Jan-2010 22:04 PST
Ryan, my code (this little jsp) depends on CustomJSPServlet (Tech comments:addon#An simple (but ugly) attempt), so it doesn't make sense to submit it "as is". I hopefully have the time to create a new version, integrated into Special:Account or Special:Roles (where does it fit best?), which I could check into svn... If you are willing to integrate CustomJSPServlet or something similar, it could be an optional feature for some installations (such as mine :) ). What do you think about? --hp 10-Jan-2010 08:23 PST
There is already a utility to update passwords on Special:Maintenance, so that might be the best place for the (similar) functionality of creating a user account. I haven't had a chance to look at your code yet (I'm starting a new job and have been busy with preliminary work) but will look at it as soon as time permits. In the mean time let me know if there anything specific you want help/advice with, otherwise I'll try to get a bit more involved in the coming week. Thanks for taking the initiative on this! -- Ryan • (comments) • 10-Jan-2010 21:25 PST
I created a new branch ("hp") and checked in changes for this feature. Although this integrates well with Special:Maintenance, maybe it is time for a new special page "Special:AdminUsers" or something else... I think for people new to JAMWiki it is quite hard to learn that on Special:Specialpages the title "User registration" is NOT for registration of others (new users), while you can do this in "Maintenance". Furthermore, wouldn't it be nice to put password resets, user adding and role/group management under one hood? Another requested feature would also fit in here. What do you mean? --hp 11-Jan-2010 06:48 PST
The code looks good and the feature is useful, so I've merged it to trunk in revision 2838. Thanks! Regarding its placement on Special:Maintenance, you're right that the Special:Maintenance page would benefit from splitting into separate pages, as would the Special:Admin page, although I'm not sure if more tabs would necessarily be the best solution. Would a more traditional left menu navigational structure (menu/sub-menu) make more sense? IE, a structure similar to the following:
  • System Configuration
    • Database Settings
    • Parser Settings
    • ...
  • User Management
    • User Account Management
    • User Roles
    • ...
  • Virtual Wikis
  • Database Migration Tools
  • Etc.
That helps better organize administrative tasks without the risk of eventually having 20 tabs on the screen... I'm using Wordpress and am very impressive with their admin tools, so doing something similar in JAMWiki might make sense. Just a thought, and suggestions are very welcome. -- Ryan • (comments) • 11-Jan-2010 17:07 PST
Would you see this menu navigation in Special:Specialpages? Or do you think about something new? I made my previous comment, because on Special:Maintenance the half of fields are now for user administration, while the other half has nothing to do with it. If the user administration part grows, I think it would be neccessary to put it into something new (maybe combined with role management). Just my two cents... --hp 11-Jan-2010 22:50 PST
Sorry, the new navigation structure would be on all of the admin pages, but Special:Specialpages would probably just show links to new pages. -- Ryan • (comments) • 12-Jan-2010 08:00 PST
Sounds good to me! I think the navigation through administration is pretty needed... I don't know if a left menu, right menu or tabs would fit best.
--~~~~

[Edit]Display jam_wiki_user.display_name in history and recent changes

In our Wiki, everyone logs into with his Domain-User, which is a number with three letters and 8 digits. Nobody knows who had made the change if there is only the login displayed.

Although this change is a bigger one, I think it's worth the effort. I have started to implement this feature, but I think it doesn't make sense to make such a deep change with my little insight (and for every version again). Sadly it cannot be made on Database-Layer only (instead of the login), because the login is also required for linking to the User-Page.

Am I the only one which would like this feature? --hp 07-Jan-2010 03:00 PST

This is something that would be easy enough to put in place as a user-configurable option. I'm happy to do it for 0.9.0 provided you remind me occasionally (when work gets busy it's easy to let things drop if it seems like no one is really interested in them), or if you are interested in putting together an implementation I'd be happy to work with you on it. Thanks for the feedback. -- Ryan • (comments) • 07-Jan-2010 22:06 PST

[Edit]Virtual Wikis

Also see Tech:Virtual Wiki Enhancements for discussion.

[Edit]Virtual Wikis

Have started looking as virtual wikis. 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 enter http://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

Hey, I was wondering if there is some kind of feature allowing searching across virtual wikis from either a different virtual wiki or the main wiki? The results I'm finding do not seem to include pages found on different virtual wikis and I see no documentation stating one way or another that searching across virtual wikis is possible. Thanks, cornwe19 23-Jun-2008 13:56 PDT

That's not currently available, but if it's something you're interested in keep leaving messages here and on the Feedback page and it should be something that can be added for an upcoming release. -- Ryan 26-Jun-2008 16:42 PDT
Alright thanks Ryan, hopefully it can be incorporated soon. It would help me a lot. --cornwe19 30-Jun-2008 12:24 PDT
  • It would be quite comfortable to disable virtual wikis at all. Most ppl need only one wiki. e.g. localhost/jamwiki/MainPage

[Edit]Virtual Wiki Title

I understand I can update the common.sitename field to change the site title. However, can I use virtual-wiki specific titles. My first time using this site so my apologies if this isn't the right place for this question.

Perfect place for this question. At present there isn't a virtual-wiki specific way of setting the site title, but given the number of people asking for similar features it's definitely something that should be considered for a future release. If you (or anyone else) is interested in starting a Tech:Virtual Wiki Enhancements topic it would help to collect together all virtual wiki-related changes that people are interested in. -- Ryan 02-Jun-2008 12:45 PDT
Started discussion for Tech:Virtual Wiki Enhancements 02-Jan-2008
Note that revision 2646 converts site name from a message key to a configurable (Special:Admin) property. It is still not configurable per virtual wiki, but I wanted to note the change here lest any get confused while reading this entry. -- Ryan • (comments) • 23-Jul-2009 21:29 PDT

[Edit]Rename Default Virtual Wiki

Archived from the Feedback page:

How can I rename the default virtual wiki from "en" to "something"? Thanks.


At the moment it is possible to create a new virtual wiki, but it isn't possible to change the default from "en". Feel free to add a feature request under Roadmap#Unscheduled since this would be a useful feature to have. -- Ryan 13-May-2007 18:05 PDT

[Edit]Rename Virtual Wiki

Add support to rename a virtual wiki other than the default wiki.

[Edit]Delete Virtual Wiki

Add support to delete a virtual wiki.

[Edit]Virtual Wiki automation without restarting container

Archived from the Feedback page:

Is there a way to automate virtual wikis so the web.xml doesn't have to be updated and the container restarted? I want to automate the creation of virtual wikis and I don't want any of these manual steps in there. -Will 10/30/2008 2:00 MST

I'm sure it's possible, but without digging into the code no ideas for implementing this come immediately to mind. If you've got ideas then patches are welcome; alternatively the way I work is to implement those things that I'm most interested in OR that people continually bug me about. Since I don't personally do much with virtual wikis, frequent reminders is probably the best way to prod me into coding this functionality :) -- Ryan 30-Oct-2008 21:44 PDT

[Edit]Multiple Image Upload

We're using JamWiki at our company as an internal information database. For some documentations we're missing a feature to upload multiple images at once and I've not yet seen a way to do this.

Example: http://wiki.anotherwebcom.com/Category:MediaWiki_Multi-File_Upload

[Edit]Excluding stylesheets from spam filter?

To adjust our wiki to our corporate design we use a combination of changes in one jamwiki JSP and the wiki stylesheet. To minimize the JSP changes we wanted to use display:none which is not allowed by the default spam filter. So we changed the spam filter settings.

My question is now: would it be a good idea for future versions of jamwiki to exclude the stylesheets from the spam filter? The stylesheet usually is accessible only for special users and should not need a protection by the spam filter. On the other hand there are strong reasons for not allowing all users the use of display:none --HB 21-Jan-2009 23:46 PST

It might actually make sense to exclude all protected pages from the spam filter... -- Ryan • (comments) • 26-Jun-2009 14:09 PDT

[Edit]Internally convert Windows path to file protocol

We already can use links to the local file system like this file:///C:/link/to/path%20with%20spaces. It would be more convenient if the JAMWiki parser could do the conversion from Windows to file:// syntax, though. I propose something like [[FILESYSTEM:C:\link\to\path with spaces]]. FYI, DokuWiki is an inspiration for this. --tapaya 02-Apr-2009 08:10 PDT

Thanks for the suggestion and the link to the DokuWiki documentation. Time permitting it probably wouldn't be hard to implement something like this, although it would probably need to have a configuration (on/off) option for non-windows systems. As the 0.8.0 development cycle moves on please add (gentle) reminders and I think this is something that would be doable. -- Ryan • (comments) • 02-Apr-2009 21:06 PDT
This shall be a gentle reminder.

And another feature that would be awesome: muliple file uploads! Is this feasible? --tapaya 14-Apr-2009 01:39 PDT

Thanks for the reminder - I tend to write code based on what I'm interested in and what people frequently ask for. I'm probably not going to get to it before the weekend at the soonest, so feel free to add further reminders if the 0.8.0 cycle drags on without further updates. As to multiple uploads, that would be more involved - is there a significant advantage to being able to upload multiple files at once beyond ease-of-use? Is there another wiki that implements this feature that could be used as a model? Thanks. -- Ryan • (comments) • 14-Apr-2009 21:04 PDT

[Edit]login/logout

I have kept only the registered users to see the content of my site. Once the users clicks the logout link, its redirecting it to Starting points with login screen with "You do not have permission to access StartingPoints.".Is it possible to show some page with following data " Thanks for using Jamwiki !!! Please Click OK button to go to the login page". Or else is it possible not to show any message on the login screen. Thanks in advance --Venkat Raman 28-Apr-2009 04:34 PDT

I believe that this can be controlled by updating the applicationContext-security.xml file - I'll verify and try to get some documentation available on jamwiki.org. If it can't be configured I'll leave this request open and hopefully it will get implemented in an upcoming release. Thanks for the feedback! -- Ryan • (comments) • 29-Apr-2009 07:18 PDT

[Edit]New Features

[Edit]Automatic Links to Words Matching Page Names

An option to enable words which match existing page names to be automatically linked. For example, if the pages /en/cat and /en/dog existed regardless of capitalization, then the page content would automatically be parsed as following.

The Dog chased the Cat.  The cat ran from the dog.

The [[dog|Dog]] chased the [[cat|Cat]].  The [[cat]] ran from the [[dog]].
This sounds like an interesting idea, and would be ideally suited as a plugin implementation. Longer term I would like to make the editing and page display code into a chain of filters, thus allowing plugins to be inserted. An application such as the one you've suggested would then be fairly easy to implement as a filter could be created to scan edited text for topic matches. Changing to a filter-based flow is probably a longer term change, however, so unfortunately I probably won't personally get to a request like this one for some time. -- Ryan 04-Jan-2009 20:24 PST

[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
Is there any update on when this might be done, or is it in the repository? We could REALLY use this feature. Thanks! Gene 2008-Oct-17
I can try to put this in place for JAMWiki 0.7.0 - features tend to get implemented based on either someone being interested in implementing it OR someone asking repeatedly, so please add reminders to this thread if there isn't an update indicating that the feature is available in the next week or two. -- Ryan 17-Oct-2008 11:12 PDT
Getting it into JAMWiki 0.7.0 would be great if possible. If you don't, I expect you'll see some patches sent your way to hopefully be included in later releases. You did mention making this a configurable option - any reason not to make a list of valid tags a configurable option? Or is that what you were planning? Gene Oct 29 11:58:39 EDT 2008
Thanks for the followup - the long term plan is definitely to add an option for allowing/preventing each HTML tag, but the current parser architecture would probably require some fairly disruptive updates so it hasn't been done yet. I've been busy with other things lately and haven't been able to write much code, but will hopefully have some time over the next couple of weeks to get to the embed tag issue for 0.7.0 - if not, please keep adding reminders! -- Ryan 29-Oct-2008 14:06 PDT
You could also do this using a lightbox javascript library, possibly with no changes to the wiki code.

[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]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]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]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]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]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]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]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]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 ;-).

About two years since previous post. Storing files in DB are planned or no?

this isn't on the immediate Roadmap but I suspect that during the lifetime of the project it is a feature for which support will be added. -- Ryan • (comments) • 17-Sep-2009 07:23 PDT

[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]Tag and category integration

Redirecting the name of a category to that category should be an option across the whole wiki, and should automatically create a tag with the same name as the category. That is, if there's a [[category:trolls]] and no article [[trolls]], then the latter should be automatically REDIRECTed to the former.

Easy listing of tags (as in blogs) so that tags can be listed as "in" a category, makes it very easy for searches of tags in tag-based search engines to pick up and list wiki pages.

In combination with wiki nesting/import, this also permits EXTERNAL pages that have the tag to be listed below INTERNAL pages that have the category applied. It should also be possible to have pages that have similar search terms added.

With all these features implemented, one's own wiki becomes a lens by which to view all other blogs and wikis, and one is far less reliant upon categories to organize information, except for those categories one uses internally.

[Edit]Authorization, permissions and other monolithic ratings

[Edit]Jabber support

The jabber ID is in use now as a universal single login for multiple wikis. Wikimedia proposed using it as it is a far more distributed and already-implemented infrastructure than OpenID, with none of OpenID's many problems (most notably the way OpenID is biased towards identifying everything with a person's body or "real name" rather than merely a persistent account name). It should be implemented before OpenID because there will be far less resistance to it, and because jabber clients also support all the chat networks.

[Edit]Forgotten passwords

Implement the capability to email a new password when a user clicks on a "forgot password" link. See also ForgottenPassword.

[Edit]Hardwired reputation system

See http://www.firstmonday.org/issues/issue11_9/cross/index.html for a discussion of some issues. In order to better handle vandalism it might be nice if there was some way to recognize reputable editors and then give an idea when viewing changes and history as to how reputable an edit actually is. This system could probably be enhanced by using spam filters, edit patterns (see http://en.wikipedia.org/wiki/User:Tawkerbot2), etc.

See also http://www.firstmonday.org/issues/issue8_8/jordan/ for a discussion about Augmented Social Networks -- Jack 07-Mar-2007 15:01 PST

[Edit]no reputations not encapsulated by (social) factions - a contrary position

Any definition of "reputable" is wrong or at best controversial. While it's a very sound idea to ORDER PRIORITIES of administrative actions based on some metric that an administrator chooses to trust, that can't be one imposed by the system, so to work it has to be very customizable. It has to be social and dealt with as part of a suite of social features like friends and etc..

The least controversial thing to do is encapsulate the "reputation" system so a "faction" of users agrees to use and maintain it. The default could be that all administrators form one faction, but anyone could form a new faction and adjust the parameters of the system or simply hand-undo the way people or IPs have been labelled. In any case the system itself must not impose one way of assessing "reputation" or, sure as slashdot, it'll be gamed as a moral obligation by all those people who object to such systems on principle. That's far less likely if the whole thing is properly labelled as merely one faction's choice of how to set its own internal priorities.

In especially contentious wikis or those with a real need to express fairness, the factions could compete as parties do in elections to set the dominant mode of reputation.

Anything less is an administrative power grab, so no "reputation" system should be implemented until it's very clear that subscribing to a reputation system is voluntary and that any group of users can set up their own independent of that which the administrators prefer.

Ten minutes on Slashdot and you can see exactly what's wrong with having one monolithic "reputation system" - insightful posts by strangers sit at zero as crap authored by trolls gets modded up to +5 by each other as sort of a game. Administrators are just old trolls - they'll censor those who they don't understand or like, and drive everyone else off, if they can. Wikis just don't work if users rank and rate each other rather than the pages, and they won't work also if pages disappear just because someone unknown wrote them.

[Edit]Social features - networks, notifications, messaging and peer-run ratings

[Edit]New message notification

Add an icon next to the "User comments" link in the user menu to indicate that a new message has been added to a user's talk page, similar to what is done on Wikitravel.

Ideally, send the message itself to a chat network, possibly one tied to the email registered. It really is not difficult to find an MSN or Yahoo or jabber account matched to that email, or to ask for it up front when registering. If the user who left the message also has such an account, jamwiki could even set up the two in a chat to talk to each other live.

Yes, please, such a mechanism is needed as wiki novices never notice a new comment. --Rudi Wiesmayr (AT) 15-Feb-2009 11:12 PST

[Edit]Email Support

JAMWiki will eventually need to be able to send email in order to support registration confirmation, "email this user" functionality, forgotten password functionality, etc. There is code in the codebase currently to support sending email, but it is untested, orphaned, and un-reviewed. Tech:Email

Also would be nice to have an option to receive an email anytime something on my watchlist changes... --Arthur Blake 22-Feb-2010 13:23 PST

[Edit]Mailing List Integration

Create tools to do things such as integrating with mailing lists. It is difficult to follow the discussion on a mailing list due to a lack of context, so it would be nice to allow a Wiki interface to follow those sorts of discussions. Add a message on the Wiki should (optionally) send a message to the mailing list.

[Edit]RSS

The old Very Quick Wiki code had RSS support, but it was unmaintained after the JAMWiki fork and has been removed. Re-implementing RSS should be a relatively simple matter, although it would be best to match Mediawiki's format when it is done.

I've done some work on this - see Tech:RSS -- Rainer 22-Dec-2006 11:23 PST
How about a RSS Reader/Aggregator? Andreas Eriksson, Sweden 4-April-2007 11:25 GMT+01:00

[Edit]RSS Enhancement

It would be great if there were feeds not only for the whole virtual wiki but for

  • Category-Pages
  • Users Watchlist (commented on Tech:RSS): The personal watchlist via RSS would be a nice feature but perhaps not wanted, because it opens the possibility to see the watchlist of other users...

--hp 03-Dec-2008 01:35 PST

The folks where I work have been asking for more ways to be notified of changes to articles to make it easier to collaborate, so your suggestion of making RSS feeds more flexible is a good one. My focus right now (when I can find time) is entirely on the Spring Security enhancements, but hopefully after that there will be time to give some attention to usability issues like this one. -- Ryan 03-Dec-2008 21:25 PST

One other area I think would be great for a RSS enhancement would be to have a configurable URI prefix. In our deployment we use an Apache reverse proxy to a app server bound only on localhost making the URLs embedded in the RSS inaccessible.

--72.70.37.162 23-Dec-2008 13:17 PST

[Edit]social networking integration (OpenSocial API, user page templates)

Wiki user pages are actually much more functional than typical social network applications like Facebook or MySpace, since they can be arranged arbitrarily and users can develop their own conventions to signal things (for instance the way Wikipedia users explain their expertise and language mastery to each other with tags on the pages) to each other without having to be programmers.

Also, wikis do a far better job of letting someone track individual topics of interest (rather than "groups" which tend to be larger grained), and letting others review your contributions to find points of common interest.

However, creating such user pages requires more work than say Facebook pages which typically can be created by agreeing to a few things with single clicks. Some user page templates need to be built in to make it easy to make a Facebook-like or Wikipedia-like profile with whatever tags seem relevant to that wiki.

Until now also there was no standard way for developers to extend the social functions, for instance, introducing people based on common interests as signalled in watchlists (without revealing necessarily what those are) or contributions. But now there is, the OpenSocial API. Using that, "developers can create applications, using standard JavaScript and HTML, that run on social websites that have implemented the OpenSocial APIs. These websites, known as OpenSocial containers, allow developers to access their social information; in return they receive a large suite of applications for their users. The OpenSocial APIs expose methods for accessing information about people, their friends, and their data, within the context of a container."

So if JAMWiki user page templates report the social information to code that publishes it via the OpenSocial API, every jamwiki web site becomes such a container. This works especially well with a single login and blogs since signing pages in other wikis can trace back easily to the profile that includes the most social information. This in turn would prove especially useful for resolving disputes - you might find it really easy to find mutual friends who could moderate the discussion on some controversial or inflamed topic. This could even be automatically invoked on say violations of the 3RR.

[Edit]Factional reputations

The hardwired reputation system can be easily replaced once social networking and OpenSocial are supported - just use the typical filter sharing and heavily friends based recommendations and ratings systems typical of social networks, rather than a gameable horror which only slashdot trolls will love.

[Edit]3RR

Detecting whether the same version has been restored three times (or some other number set by the system) could be built in and trigger a log. While there are legitimate reasons to do this, like wiki spam and wiki vandalism, generally other solutions such as captcha and block IP should be used for repeated offenses. The 3RR exists for human disputes and the system could help resolve them with a 3RR log and, in conjunction with the social features possible with OpenSocial, find a mediator.

This is a notification/messaging concern because the system itself should not set hard policies about inter-user disputes.

[Edit]Blog

I'd like my wiki engine to be a blog engine as well. Maybe, each user could have a Special:Blog page. The n latest entry would be displayed there. Writing an entry should allow wiki syntax with links to real pages, obviously. And trackback must be supported. Ideally, the API of a major blog engine should be implemented in order to allow web site integration. -- Régis Décamps

Have a look at Axel's project Bliki. The goal is to create a Wiki-based blog, and it supports JAMWiki. -- Ryan 13-Oct-2006 16:30 PDT
You can test the Plog4U Wikipedia Formatter in this Groovy-News Roller instance. If you define a template _wiki you can define your prefered default wiki instance. In my blog I defined for example the english wikipedia as the default with the following template definition: 
wiki_url=http://en.wikipedia.org/wiki/${title}
image_url=http://www.groovy-news.org/e/axelclk/${image}
Additionally you can use interwiki prefixes. For example the interwiki prefix jamwiki links to jamwiki.org. See the test blog http://www.groovy-news.org/e/page/test for some other examples. -- Axel Kramer

[Edit]blogs aren't compatible with wiki interfaces - contrary position

Not that anybody asked me, but ... I don't think building blog functionality into a wiki is the right way to go. They are fundamentally different in purpose. Blog is a publishing tool for non-editable content. Wiki is a collaborative editing tool. I think it's fine to have sister projects that are compatible, but I would not recommend combining them into one piece of software. -- scroco 13-Oct-2006 16:47 PDT

I agree that JAMWiki shouldn't force a blog engine onto users, and I don't plan on ever integrating a blog engine directly into JAMWiki. However, if people are interested in using JAMWiki as a base to build a blog engine (or anything else) I'd like to work with them to make it possible for them to do so, either via an extension mechanism or some other method. Having projects out there that are using the JAMWiki code provides a great opportunity to gather feedback about how to extend JAMWiki functionality, and in the long run should be helpful for developing methods and APIs for extensions and inter-operability. Long-winded response, but just wanted to clarify that JAMWiki won't become a blog engine, but that I'm very much in favor of having "sister" or "child" projects out there trying to extend JAMWiki functionality, and I'd like to be very open to feedback from those projects about how to improve integration with JAMWiki. -- Ryan 13-Oct-2006 17:23 PDT

I'd like to see an extension to add blog functionality to JAMWiki, too. I used many Wikis and occasionally I want to add blog entries. I like the freedom of Wikis to design my entries with wiki syntax and arrange them howsoever I like. But the software could support me, especially with overview pages and tagging :-) Mike 21-Jul-2007 18:46 PDT

[Edit]a "publish" tab and "subscribe" mechanism

Another option would be to put a "publish" tab on every page, similar to the page history, which shows only those versions that a given faction or group of users has chosen to "publish" as their approved version. This capability, minus the democratic ability to have multiple such factions, was discussed extensively as a "sifter" or "official Wikipedia" back in 2003 or so by Larry Sanger (in Sanger's version, he himself would lead the only faction able to make publishing choices, but there's no inherent reason for this exclusivity).

Then the "blog" interface consists of the published version and all comments on any published version by any faction that one "subscribes" to (say via RSS). If one subscribes to the published version one sees only publications by some faction, not all edits by everyone. It would be clear which version a comment was attached to (which is very UNCLEAR in wiki talk pages) but all comments would be visible at once with the latest version, and it would be easy to look at the earlier published versions. Looking at the entire page history would be possible but not mandatory. This would make it easy for private wikis to publish to public websites.

[Edit]Using existing blog software to show wiki pages as blog entries

Does someone already tried something like this? For example a redesign/integration of the Pebble blog software, so that every blog-entry gets its content from a wiki-page defined in a special User:XXX/blog/subdirectory sorted by date of publishing? Or a Special:Blog page where every user can define the entries he like to be published or bookmark on his User:XXX page with a tag like <blog />?

[Edit]User Interface

[Edit]Option to Delete Original Page when Moved

When you move a page a new page is created. The content from the old page is relocated. The original page is kept but now blank. And the old page automatically redirects to the new page. Sometimes when you are moving a page you do not want the old page to be kept or for it to redirect. Currently you must go to the old page, be redirected, click on the link to force going to the old page, and then delete it. It would be convenient to have a checkbox when initially moving a page that is labeled 'Do not redirect and delete previous page.' which changes the default behavior. j_teer 06-Jan-2009 14:00 PST

[Edit]Global Find and Replace

A way for finding and replacing text across multiple wiki pages within a specified URL (e.g. all pages under /en/*). Optimally you could confirm or select which matches would be changed. j_teer

[Edit]Export to PDF/HTML/ODT/DOC/Other

Wikis are a valuable tool for design since they allow users to collaborate to work out design details. Once something is "complete" there should be a way of exporting that information, either as a series of HTML pages or in some other format. Note that this request envisions designs that encompass multiple topics - for single topics there is always the "Print" tab.

Ideally the print tab should have the option to print as PDF or HTML or even ODT (OpenOffice, which is also based on Java) or DOC files (Microsoft is still widely used, sadly).

The request below copied from the FAQ page:

It would be nice to allow a PDF export of single pages or group of pages. It should be very helpful to organize pages also into trees. This feature will enable the usage of JAMWiki in order to create manuals or documentation.

Exporting pages or groups of pages would definitely be useful. I'd like to get the parser interfaces somewhat more stable before doing any work on alternative output formats, but once the parser settles down it should be relatively easy to allow output of almost any form. If anyone knows of any particularly simple & free PDF tools that would also be helpful. -- Ryan 26-Oct-2006 02:05 PDT
the german wikipedia clone (written in java) at http://www.wikiweise.de has the discussed PDF export features and claims to open source the wikiweise software in the near future.
I see that wikipresto, the wiki software behind wikiwiese, is already available as OS under the GPL, or you can buy a commercial license from the author. I think this model is fairly incompatible with the LGPL of jamwiki... and it would only harm to look at the PDF implementation of it. I really don't believe the author will change this to a business-friendly license like LGPL, as I also don't really believe the wikiweise site will have any better content than wikipedia in the long run... I had a distinct feeling of "censorship we need" when reading it... and I can't really explain it why, but I feel more censorship will never result in better content, just a differently flawed one. Cheers, Csaba 28-Nov-2006 05:31 PST
I've once tried to create a PDF exporter WikiPDFExporter.java in the Eclipse plugin, but I don't have much background knowledge of PDF and the iText library and so the output doesn't look very beautiful. -- Axel Kramer 28-Nov-2006 08:49 PST

If you (or anyone else) are interested in helping LGPL-ing the pdf creation feature of Wikiweise, drop me a line (mail @ ulrich-fuchs . de). I alone cannot maintain that code as good as I want to, and I think that code has a lot of potential (it's the Tex algorithm implemented in Java with the additional feature of placing images near the text they belong to - as far as I know there is nothing else like this worldwide), but it's in a state where it needs a lot of refactoring. - Uli

A number of projects are using the OpenOffice jar files and binaries to generate PDF files, and even interoperate with OO documents of all kinds, which implies interoperating with MS Office documents as well. Memory suggests that this is a well-documented capability. -- Jack 07-Mar-2007 14:56 PST
OpenOffice API is fairly mature. We are using OpenOffice API for document conversion from odt to doc and pdf. It has fairly good support for html to other formats (rtf, pdf and odt). The downside is a listener service needs to be running and as of Openoffice 2.4, conversion requests were handled synchronously. OpenOffice 3.0 was suppose to resolve this issue of multithreading, not sure if it does. --- Satish 12-Nov-2008 21:55 EST

The approach described here Generating PDFs for Fun and Profit with Flying Saucer and iText seems to create acceptable PDF files Axel Kramer 14-Jul-2007 07:39 PDT

What are the current supported export formats? -- Van 02-Jul-2008 09:23 EDT

[Edit]WYSIWYG Editor

From Evan Prodromou:

I really think that before your syntax gets too complicated, you should take a look at Wikiwyg:
http://www.wikiwyg.net/
It's a fantastic in-browser WYSIWYG editor specifically for wikis. It works by using JavaScript regexes to convert from Wiki markup to HTML and back again, so that users can edit however they want, but the backend only sees Wiki text.
Making it work for MediaWiki right now would be tough, but you're early enough that you can probably make it handle all the syntax your engine does. If you integrate it now, and add new features in a way that keeps it up-to-date, by the time you have full MW syntax parity, you'll have a significantly better product.
Just a suggestion.

A WYSIWYG editor would be a great option for JAMWiki. There is currently some WYSIWYG code that has been commented out from edit.jsp, but it would be nice if it were possible to have a configuration setting allowing an admin (or even a user) to choose a WYSIWYG editor. One consideration is that JAMWiki allows anyone to use a different parser, so it cannot always be assumed that the standard Mediawiki syntax set is being used.

The editor using in Atlassian-Confluence, has more improvement User-Experience i think. Farther more, the edit-cacheing system is very useful.
http://www.atlassian.com/software/confluence/ConfluenceDownloadCenter.jspa
But seems it`s NOT open source. :( -Ray
if someone needs a really neat open source editor, take fckeditor.net. I use it at work in your tomcat apps. performs great!
i think fck generates html output and no wiki syntax. you have to replace the fck javascript parser to use fck in a wiki.

Just a note to say that, as suggested above, http://www.fckeditor.net/ looks like a good option. Any implementation would probably need to give users a configurable preference so that they could choose between the GUI editor and just entering plain text. -- Ryan 26-May-2008 19:05 PDT

I found something interesting, FCKEditor has a sub-project called MediaWiki+FCKeditor, so integration with JAMWiki will be much easier (I guess). Here is the link: http://mediawiki.fckeditor.net/

-- Matias 1-Jul-2008 18:00

[Edit]FCKEditor for Java Application

Has someone tried out this implementation? -- 192.109.190.88 23-Oct-2008 02:58 PDT

I haven't looked into graphical editors closely yet, but thanks for the pointer! There have been a number of people asking for additional options for GUI editors, so hopefully if I don't get to that feature soon then someone else will implement something. I'm hopeful that any implementation will be generic enough that something like FCKEditor or any other implementation would be easy to put in. -- Ryan 23-Oct-2008 07:42 PDT
I looked into MediaWiki+FCKeditor and it looks good for my own implementation. Its stated on the roadmap area that 0.7 version might have the GUI Editor. Just for clarification, is it the WYSIWYG editor you guys talking about or something else. If yes then is WYSIWYG editor gonna be comparable/better to MediaWiki+FCKeditor or it gonna be basic for first release?--FMasood 17-Nov-2008 16:06 PST
To be honest I've been completely focused on the Spring Security Upgrade and haven't even looked at GUI editors yet, but the plan it to implement the Javascript-base WYSIWYG editor if possible. -- Ryan 18-Nov-2008 07:55 PST
I started out on the integration of JAMWiki with http://mediawiki.fckeditor.net/ during the past weekend, but it turned out to be a bit more involved than expected. I'd still like to get some sort of GUI editor integrated and also provide a plugin infrastructure for integrating others, but for now only the basic support (store editor preference for users) is done, and actually implementing GUI editor support remains on the to-do list. It may turn out that integration with a simpler editor like http://www.wikiwyg.net/ will be easier and may get implemented first. -- Ryan 04-Jan-2009 20:19 PST
Hi Ryan, i did a basic integration of fckeditor with jamwiki. I haven't yet hooked up file/image upload etc, but basic editing is working. It's a ugly hack, does wiki->html when opening editor and html-> wiki(using bliki parser) while previewing and saving. I can share my code for your feedback on my approach and if it makes you release wysiwyg editor sooner :). --ronin 14-Mar-2009 06:35 PDT
I'd definitely be interested if you've got something working - I spent a day looking at this prior to the last release but decided it was more work than I wanted to put in at the time. I'm literally hours away from hopping on a boat and heading out to sea for a week, but if you have a Sourceforge ID and want to create a branch in Subversion for your changes let me know what your ID is and I can set up access. -- Ryan • (comments) • 14-Mar-2009 06:41 PDT
I'm definitely interested. sourceforge id: ronindump --ronin 14-Mar-2009 07:56 PDT
Great! I've set you up with Subversion access, so go ahead and create a branch off of trunk for any changes you want to make. I'm going to be leaving some time in the next 2-5 hours but I'll check jamwiki.org until then, so if you have any problems or questions let me know, otherwise I'll take a look at the code when I get back and we can figure out how best to merge it for the next major release. Thanks a lot for contributing! -- Ryan • (comments) • 14-Mar-2009 08:07 PDT

This would be awesome ... --Random user

Just a note, but fckeditor has just had a major version update and rename to ckeditor.com. New version is much faster. Are you still planning on integrating it?

See Roadmap. Integration with (F)CKEditor has proven challenging, and while it's still on the radar it will not be a part of 0.8.0. -- Ryan • (comments) • 07-Sep-2009 21:38 PDT

[Edit]Special:History

Archived from the Feedback page:

On the Special:History-Page the username of the author is listed (usernames are stored in [jam_recent_change]). Wouldn't it be nice if the displayName of the user (if a displayName exists) would be printed instead? --hp 08-Jan-2009 23:30 PST

The current implementation was done to match Mediawiki - I believe that they use the login to prevent malicious users from trying to impersonate other editors since logins are unique and cannot be faked. It might be possible to provide a configuration option that allows site administrators to change this behavior; I'll move this comment to the Feature Requests page so that others can comment. -- Ryan 09-Jan-2009 07:24 PST
I can see small friendly user bases and some businesses enjoying a feature like this. If implemented I would make it more generalized and use a template string to determine how identity is displayed across the entire wiki. For example, in signatures, various special pages, and at the top by your account when you are logging in.
You could make it simple and have a check box to switch between two template strings. For example you can pick either by Id or by Name. Or you could make it very flexible and allow the administrator to enter the template string in a text field. Some examples 
"$(userid)" displays as wrh2
"$(FirstName)$(LastName)" displays as Ryan Holliday
"$(LastName),$(FirstName) ($(userid))" displays as Holliday, Ryan (wrh2)
"$(LastName),$(FirstName) (?(userid))" displays as Holliday, Ryan unless there is a duplicate Holliday, Ryan in which case it displays as above
This would allow an administrator to format it however they want. Either way, by default it would be user name. j_teer 09-Jan-2009 12:23 PST
The new custom signatures for JAMWiki 0.7.0 work very similar to the solution you proposed - if/when the ability to use non-logins on history page is implemented it wouldn't be hard to do something similar there. -- Ryan • (comments) • 12-Jan-2009 19:35 PST

[Edit]Testing

[Edit]"Fuzz Testing"

From NickJ:

Hi Ryan, The Fuzz Tester source code is now on the web. There's also a video that was shown today at the WikiMania Hacking Days about Fuzz Testing MediaWiki if you're really keen - it's 220 Mb, and in XviD format. From your perspective, what you'd want to do would be to update the configuration section (to remove the dependency on MediaWiki's commandline.inc, which is only used for getting the command-line options and for knowing the path to some things which are then used in the configuration section) (or alternatively if you have a MediaWiki install, just drop this into the maintainance directory and use the command-line options to specifiy the URL to your wiki plus which specific tests to run), and then write a test class or classes specific to JAMWiki (you'd probably copy one of the other tests that extend pageTest, such as editPageTest). If you do end up doing such a thing, please send me your changes and the bits that I can include (e.g. any JAMwiki test classes) I will be happy to add to the fuzz tester. -- All the best, NickJ.

[Edit]Webtests

I do have a "feature"-request for the html - generated by jamwiki!

For the development of webtests It would be nice to have unique Id-attributes in every Error-Message.

At this moment for examle I see:

<p>Ein Systemfehler ist aufgetreten. Die Fehlermeldung lautet:</p>
<p>
 <font style="color: red; font-weight: bold;">javax.el.PropertyNotFoundException: The class 'org.jamwiki.model.WikiUserInfo' does not have the property 'writeable'.</font>
</p>

Better for webtesting would be:

<p id="system-error">Ein Systemfehler ist aufgetreten. Die Fehlermeldung lautet:</p>
<p id="system-error-0">
 <font style="color: red; font-weight: bold;">javax.el.PropertyNotFoundException: The class 'org.jamwiki.model.WikiUserInfo' does not have the property 'writeable'.</font>
</p>

The Id inside the p-tag would be nice to identify the existence of the element inside the page. Don't know if there can be more than one specific error-message. So maybe only one Id would be enough.

When I tried to run the three webtests on the actual revision (http://jamwiki.org/wiki/en/Bug_Reports#Bug_in_svn_Revision:_2344) I got an error page. For future testing it would be nice, if I could check for the non-existence of an Html-Element with an error-ID. Thanks. -- mbert 04-Oct-2008 03:19 PDT

That sounds good - feel free to make the necessary change to the /WEB-INF/jsp/error.jsp file. Since there can only be one error message it would probably be better to use something like "system-error-message" instead of "system-error-0" just to keep things descriptive. In the future, if you need IDs on any other elements feel free to add them as I think it adds value to the site, and anything that makes testing easier is a good thing. -- Ryan 04-Oct-2008 13:15 PDT

[Edit]Installation

[Edit]Fewer Options

Simplify the install procedure by removing unnecessary options which could be manage from the Maintenance page. This would promote adoption and create fewer install mistakes.

Upload Directory - This could be removed since there is no penalty to have it set to the default and then changing it on the Maintenance page.

Database - If it were possible to migrate data or recreate the database from the Maintenance page. This option could also be removed and by default the built in database could be used. After installation you could configure it.

[Edit]Checksums

Publish MD5 and/or SHA checksums on the download page.

[Edit]Allow the option for a script-based install

Some users may prefer to install / upgrade JAMWiki using scripts rather than via an automated web interface. It should be reasonably easy to implement this functionality, in which case the install instructions would just be slightly different.

[Edit]Database owner vs. database user

Provide the capability to specify a "database owner" who can create and modify tables vs. a more standard "database user" who can simply query and update tables.

[Edit]Technical Features

[Edit]OpenSocial API support

See above under social features.

[Edit]JSR-168 Portlet Support

See also Comments:JAMWiki as JSR-168 compliant portlet. Consider adding JSR-168 / JSR-286 capabilities to JAMWiki. More and more standard compliant portal platforms emerge on the commercial or open source market, and most portal projects need a wiki system.

There are more and more portals, true. But JSR-168 is not very easy to implement, I think. And WSRP (webservice portlets) might have a brighter future. Régis Décamps 24-Jul-2007 14:17 PDT

[Edit]Java content repository

Keep an eye on JSR-170 (Java content repositories) and consider its applicability to Wikis.

I am building a subject map engine (subject maps = topic maps on steroids) using the JCR. It's my present intention to federate JAMWiki with TopicSpaces (will be LGPL when released). A topic map serves as a fully relational index into local and foreign information resources, all indexed against subjects. It strikes me that JAMWiki is an ideal platform for generation of content to be indexed and federated with indexed information resources located elsewhere on the web. For the moment, I don't see a need for JAMWiki to use the JCR, though I won't say it's out of the question. From my perspective, content as found at a wiki is self indexed (full text), but would also be full-text indexed in TopicSpaces such that a query to the subject map will turn up more instances than found locally. As I have mentioned in another post on the WikiReference object, I'm interested in rendering information resources more addressable than simply at the page level. That's because, it seems to me, the comments fields and other content may end up representing discussions that are mappable themselves in the IBIS (Dialog Mapping) format. I want to be able to point to specific instances of pro/con arguments, questions, and responses to questions. All in all, JAMWiki looks to be the platform of choice for federation with TopicSpaces. --Jack 07-Mar-2007 14:49 PST

IMHO it would be nice to have a common JSR-170 based framework for all the Java wikis around in an apache.org based project. See:

-- Axel Kramer 19-Sep-2007 11:30 PDT

[Edit]Store less text for topics

Currently even the smallest change to a topic will store an entire copy of a topic as a version in the database. For a site such as Wikipedia that would mean huge amounts of data would need to be stored due to the size and number of articles. Storing changes as diffs has its own problems due to the need to apply numerous diffs to view changes between article versions, but there may be an another solution - perhaps a hybrid solution, or some other option.

You could consider implementing a "continuation edit" feature. If a version is changed consecutively by the same user within a specified time period (say 20 minutes), instead of a whole new version, just update the version to reflect the continuation change. That doesn't exactly solve the problem entirely, but it's one step in the right direction. -- scroco 28-Aug-2006 14:40 PDT
That might work, the only problem would be if a user wanted to revert one of his own changes. This issue is probably not going to be addressed for a long while, so hopefully someone will eventually come up with a suggestion that is totally obvious, and really easy to implement. Or at least I can hope for that :) -- Ryan 28-Aug-2006 15:14 PDT
I would like to support this continuation edit, it is a real blessing. For example it is implemented in TWiki with a 60 minute time span. The problem with the user desiring to go back is made transparent you allowing as part of the save option, to save as a "checkpoint". Normal save will work in continuation edit, checkpoint will force a new version. -- I would like to add that the technical level of storage requirements may be even less important than the social one, the ability to compare meaningful versions. Having 4 versions per user within a few minutes makes version comparison a task for experts, not normal users.
I sugguest using reverse diff. We store the latest version in the DB, and diff between each other versions. That way, reading the currect version is very fast. Comparing revisions is slower, but it's not what people ask the most.
That solution could work very nicely. At the moment I don't think there are any fast Java-based diff tools, but given some time that will hopefully change, and this approach would address pretty much any concern about tradeoffs between speed and storage. Thanks! It will definitely be looked into! -- Ryan 13-Oct-2006 16:33 PDT

Zipped topic content discussion moved to Tech:Zipped topic content

And what about a SubversionDataHandler? Actually, that would require to change the API of DataHandlers to split what deals with metada and article content.

[Edit]Architecture and design

[Edit]Addon, plugin, extension

It would be a huge design improvement to have the ability to write extension / plugin / addon. However, Java provides good tools for this and it's less reliable to have two ways to do this. If mediawiki extensions can't be supported then probably the Java environment has to be leaned on heavily.

See Tech comments:addon

[Edit]Wiki Engine

There is a wiki engine called Radeox on http://radeox.org. Someone had a look at it or have experience with it? I'm curious. Mike 12-Jul-2007 13:57 PDT

I had a look on SnipSnap (which is now a dead project) and Radeox was the engine behind it. Radeox seems to be pretty inactive, too. User:Régis Décamps 29-Jul-2007 15:12 PDT
Radeox has been forked be the former lead maintainer. see Forking Radeox Kees.

[Edit]Hibernate

I personally like the ease of Hibernate to support at least 20 different databases out-of-the-box. Don't mention the avoidance of writting SQL code. I don't mind write SQL scripts, however it annoys me to write and maintain SQL code for more than one database. Why have you chosen to use the current approach? Mike 16-Jul-2007 17:57 PDT

The short answer to why Hibernate isn't being used is that it's not a technology that I'm familiar with, and it wasn't a part of the original Very Quick Wiki code base on which JAMWiki was built. The longer answer is that when I started re-organizing and re-writing the database code I looked at Hibernate, but based on their documentation these were the pros & cons that I saw:
  • Database-independent, meaning that once database code is in place to manipulate an object it should work on any supported database.
  • Integrated caching, which would simplify any caching architecture used by JAMWiki.
  • Connection management, which is always a good thing.
vs.
  • Additional learning curve for contributors, myself included. Most web application developers know SQL, but not everyone is familiar with Hibernate.
  • The JAMWiki database schema is intentionally quite simple, which means that most SQL code can be written once using ANSI SQL and only translated into a database-specific version for corner cases.
  • I'm generally suspicious of abstraction layers - the devil is usually in the details, and I didn't want to commit to Hibernate only to later discover that some minor capabilities that might have been simple with SQL would be complex with Hibernate.
  • Although it's grown significantly, I'm generally trying to keep the final JAMWiki WAR file as small as possible, and only include libraries that absolutely need to be there.
So that's the long answer. I'm definitely not opposed to Hibernate, but I don't want to switch without having a list of reasons why doing so is a good idea, and also some reassurance that using Hibernate will simplify the JAMWiki code and we won't still need database-specific hacks to deal with issues such as the fact that HSQL requires its tables to be created with the HSQL-specific "CACHED" parameter. If anyone can make a convincing case as to why Hibernate should be used (and ideally write the code!) then it's definitely something that could be integrated. -- Ryan 16-Jul-2007 21:15 PDT
After the release of 0.6, I would like to write something like a HibernateDataHandler. I will implement it in addition to the existing DataHandlers as AddOn, so it can be tested if it stable, easy to understand and maintainable. I already found the option for the cached tables with HSQL: cfg.setProperty("hibernate.connection.hsqldb.default_table_type","cached");

I'm going to write a draft on Tech:Hibernate Mike 03-Sep-2007 12:45 PDT

Provided it can be done as an option rather than a default it sounds like a great idea. If it proves to be easier to maintain and there aren't any evil corner cases then we could consider getting rid of the legacy code, but that code is fairly well tested at this point so I don't want to toss it overboard yet. Thanks for looking into this! -- Ryan 03-Sep-2007 20:14 PDT
I've just committed a change to fix a DB2 issue that changed the majority of the SQL constraint names - hopefully that doesn't mess up any work you're doing on Hibernate, but if it does and you need help integrating the new SQL let me know and I'd be glad to help make updates to any Hibernate code. -- Ryan 04-Sep-2007 23:24 PDT

[Edit]Use of Spring Dependecy Injection

I would like to see WikiBase and Utilities as Spring Bean. I want to test my TiddlyWikiParser, but it directly invokes "WikiBase.getDataHandler().writeTopic()". Because WikiBase is a Singleton class I cannot override it in my test case with a mock class to check if this call is invoked correctly. I'm going to check what have to be done for this. Mike 20-Jul-2007 10:51 PDT

Here are my results. There are a lot of singleton classes, which depend on each other. Eg WikiBase depends on Environment, UserHandler, DataHandler, Utilities and SearchEngine. Changing WikiBase to a Spring bean would require to touch almost every class, even all servlet classes, because instead of static methods they become instance methods. However it's currently very hard to write test cases, because these singletons have hardcoded relationships between them. In my opinion it's worthy make them Spring Beans, because JamWiki already uses Spring library and it much easier to write test cases. Mike 20-Jul-2007 12:55 PDT
Is is sufficient to simply make the constructors of these classes public, or do the utility methods need to be non-static? I'd rather avoid having to do: 
Environment env = new Environment();
String value = env.getValue("PROPERTY_NAME");
every time a utility method is needed, but if making the constructors public solves the problem then that would be an easy solution. -- Ryan 20-Jul-2007 15:35 PDT
I must commit that it would be really a bloody operation. In fact it rather looks like that:

There would be definitions of beans in WEB-INF/jamwiki-servlet

<bean id="environment" class="org.jamwiki.Environment">
</bean>

<bean id="wikiBase" class="org.jamwiki.WikiBase">
  <property name="environment" ref="environment"/>
<bean>

and instance variables in classes

class WikiBase {
  Environment environment; // + Getter/Setter methods
  otherMethod() {
    environment.getValue(PROPERTY_NAME);
  }
}

It's described in details on http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-dependencies The Spring Framework will create one instance of Environment and fill the environment variable in WikiBase when it is started. It's a nice way of a more loose coupling of classes. However static methods call must be replaced with instance calls in these case. Mike 20-Jul-2007 17:16 PDT

[Edit]Add ability to parse jsp tags

I would like to see the ability to use jsp tags from within wiki pages. Especially because in our case JAMWiki runs on top of another server, that has its own tags library. If we could use those tags from within wiki pages, it would make the wiki very powerful.

I found a page where a workaround is described that could solve this problem: http://groovy-news.org/e/page/axelclk?entry=how_to_integrate_a_gwt (I didn't try this myself yet)

It would be great to have this as default functionality. Hans 29-8-2007 21:25 CET

It would be useful for protecting parts of topics (such as passwords in tech documentation) with some <security:authorize ifAllGranted="ROLE_ADMIN">...</security:authorize> tags. -- Francois 22-May-2009 03:22 PDT

[Edit]"All Templates" Page

It would be a convenient resource if one of the special pages available to users was an "All Templates" page, which (obviously) lists all templates that are in place in a given Wiki. Something like "Special:Templates" would be appropriate.

This feature has been requested previously - my only concern with implementing it is that Mediawiki offers this functionality using their namespace search. Namespace search for JAMWiki probably isn't going to be available for a while, so provided no one would be upset if the AllTemplates page is removed once JAMWiki namespace search comes along then it should be easy to add.
On a side note, the section edit links on this page seem to be messed up. I'll investigate. -- Ryan 04-Dec-2007 08:40 PST
A a follow-up, I decided to try solving the "All Templates" problem by simply putting a [[Category:Template]] tag on all my templates, inside a of a NOINCLUDE tag. However, it seems that the Category parser does not work properly when Categories are listed inside of NOINCLUDE tags. The Category box still gets drawn at the bottom of the template's page, but the Category Listing itself does not contain the template. For example, if I put 
<noinclude>[[Category:Template]]</noinclude>
on the Template:MyTemplate page, the Template:MyTemplate page will list that it is part of Category:Template, but the Category:Template page itself will not show Template:MyTemplate on its listing. I hope that was clear.
For now we're probably just going to write our own tool to generate an All Templates page. P.S. The edit link for this section is still broken. --Ean 31-Jan-2008 10:44 PST

[Edit]JavaScript to create Charts/Graphs from data in a wiki page

I keep an array of time related data in a wiki page and I'd like to graph it. There are various somewhat straight forward libraries floating around such as Flot and also jQuery Sparklines. Flot example How much work is involved at achieving this? Scott 15-Oct-2008 04:04 PDT

If your charts can be created simply by including some Javascript tags then you should be able to enable Javascript from the Special:Admin page (the option is "Allow Javascript") - if you encounter issues then they can be reported on the Bug Reports page although I haven't seen any Javascript-related bug reports in a while. If you need deeper integration could you further describe how you would envision this integration working? Do you just need a custom way of including some <script> tags on every page or is there something more? -- Ryan 15-Oct-2008 07:29 PDT

[Edit]YUI Integration with JamWiki

We're trying to use JamWiki to display YUI DataTables YUI DataTable for their ease of use and general uniformity. They work pretty well too, except for one teensy problem I suspect many of you can predict. We have a datatable with a number of values that individual users need to update on a regular basis. We decided to use a Wiki to perform this, but realized quickly that in order to make changes permanent, we needed to submit the changes through the edit servlet. This posed a challenge however, as we do not have access to the following values on a normal article page:

  • <input type="hidden" name="topic" value="CurrentTopicPage" />
  • <input type="hidden" name="lastTopicVersionId" value="4216" />
  • <input type="hidden" name="section" value="" />
  • <input type="hidden" name="topicVersionId" value="" />

These values are obviously required by the Edit Servlet, and we could perform a AJAX call to the edit page, parse it to obtain these values, and then perform the submission, but it would be easiest to simply have access to these values in the current page's DOM, and would prevent us from having to perform screen scrapes that would be problematic at best.

This lead me to download the source to investigate how best to make this data available in the normal article page view. By making a few changes, it would allow Javascript to read these values directly and make them available to Javascript for submission to the edit servlet, thus saving the changes permanently. I know the wiki is probably not the best platform for this type of change, since the Javascript controlling all this is editable by anyone (here comes the but), but the ease of setup and operation makes it a very good solution for our problem.

I have not yet implemented this change in the source code, and wanted to check that this feature didn't already exist or that it was already considered and specifically disallowed by the app designers for some reason. I would like to get your thoughts on this before I proceed. I do intend to implement this feature for my own purposes, and would gladly submit this to the community at large if they wanted to have it.

Any feedback would be appreciated. --Shaka 18-Mar-2009 12:16 EDT

I'll need to read through your comments a bit more to make sure I understand fully, but would you be able to use a combination of magic words and page values to get what you need? For example:
{{FULLPAGENAME}} : Feature Requests
{{REVISIONID}} : REVISIONID (not yet implemented, but easy to add)
The topicVersionId value can be empty unless an old topic version is being edited, and I can add the section name ID in the HTML if necessary. Would that work? -- Ryan • (comments) • 21-Mar-2009 18:34 PDT
Ryan, yes I think that would be the perfect solution. I did not even know Magic Words existed. Thanks for pointing that out. The real question is would it work if those magic words were used inside some embedded Javascript, and I can't imagine a scenario where it wouldn't as the page would be rendered by the app server first. Yes, that would totally work. Obviously, {{FULLPAGENAME}} is already implemented, so if we had something like {{lastTopicVersionId}}, {{topicVersionId}} and {{sectionID}} implemented, we would be in excellent shape. (I would like to see all those items implemented in case someone does decide to edit a historical page---just for maximum flexibility.) I'm glad I took the time to stop and ask the community before running off and implementing the first thing that popped into my head. Thanks Ryan!!
The last question I have is implementation and release related. How long would it take for you to do it, and if you're swamped, can I help you in any way? --Shaka 23-Mar-2009 10:50 DST
I'd like to work on getting a release candidate for 0.7.1 ready this weekend, so I should have time to work on it then. I'll do a bit more investigation during the upcoming week, and if I haven't updated this discussion in the next 2-3 days please add a reminder so I don't forget. Hope that works! -- Ryan • (comments) • 23-Mar-2009 20:04 PDT
Hi Ryan. I wanted to check to see if you had a chance to look into this at all, and if not, whether I can roll up my sleeves and take a shot at implementing these Magic Words I'm looking for. I'm ready to do anything to help out! Just let me know.--Shaka 31-Mar-2009 2:04 DST
I haven't had a chance yet - life has gotten a bit crazy lately. If you're interested the place to start would be /jamwiki-core/src/main/java/org/jamwiki/parser/jflex/MagicWordUtil.java. If you have a Sourceforge ID let me know and I can give you Subversion access so you can set up your own branch (see How to Help#Programmers). The only request I have is that I'd like to keep any parser changes compatible with Mediawiki, so any new magic words should ideally match the syntax of what Mediawiki uses. Thanks for following up! -- Ryan • (comments) • 31-Mar-2009 12:56 PDT
No problem Ryan. I know how it goes. My Sourceforge ID is shakatard. I understand about wanting to keep things in sync with MediaWiki, and in cases where I'm not sure what to do, I'll confer with you about any changes. I'll also ask you for a code review once I'm done, and definitely have you merge to trunk once we're all happy with the changes. So, I'll go download the source, and get it to build, then make my changes and do some testing, and get back with you about permission to upload. Thanks for your quick replies!! -- Shaka 1-Apr-2009 5:09 DST
Ryan, I can't seem to build JamWiki from Maven...the instructions seem to indicate I can download bliki-core:jar:3.0.12-SNAPSHOT from /repository, but it appears /repository is empty. I can't seem to find 3.0.12 anywhere. The only revision available from Google is 3.0.11. Am I missing something obvious? Thanks! --Shaka 1-Apr-2009 7:09 DST
I've added you with developer permissions in Sourceforge. As to build errors, Axel just updated the bliki configuration and I haven't tried to build with the new changes, so you might try reverting his most recent changes in your local build to see if that helps - trunk was definitely build-able as of Sunday. Next chance I get I'll try to figure out what might have gone awry - thanks for the report. -- Ryan • (comments) • 01-Apr-2009 07:20 PDT
Sorry I'm relatively new to Maven. I now added the http://gwtwiki.googlecode.com/svn/maven-snapshot-repository/ to the pom.xml. -- Axel Kramer 01-Apr-2009 11:53 PDT
It's alright Axel. I got the file and installed in locally accordin gto the directions and everything compiled perfectly. I will now commence to implement this new feature. Wish me luck! :D --Shaka 1-Apr-2009 16:09 DST
This feature request now has a new Tech page Tech:MagicWord Enhancements supporting YUI Integration

[Edit]Specifying image height

Apparently we're currently only able to specify the image width (like [[Image:MAKE.DESC.png|160px]]). Giving it a height (like [[Image:MAKE.DESC.png|x100px]]) would be equally useful. --tapaya 26-Mar-2009 08:34 PDT

http://www.mediawiki.org/wiki/Help:Images has the Mediawiki specifications for images, which have changed somewhat since this was originally implemented for JAMWiki. Time permitting I'll see how tough it would be to bring JAMWiki back into compliance. -- Ryan • (comments) • 26-Mar-2009 13:44 PDT
It should be fairly easy to add the widthxheightpx syntax. Where is the image resizing code implemented? --tapaya 14-Apr-2009 01:44 PDT
That code is in org.jamwiki.utils.ImageUtil.java. Unfortunately that particular file is a bit convoluted, but ImageUtil.resizeImage does the actual resizing. The only concern is to be careful about performance as image resizing is about the slowest of any server-side tasks. -- Ryan • (comments) • 14-Apr-2009 21:00 PDT

[Edit]File storage/access from Microsoft VSS

I feel really great to Use JamWiki for my CMS.I could see that JamWiki Storing documents in a folder and uses seperate Indexing method. Is there any way to access same documents from Microsoft VSS ? Also,if the above is possible, Please let me know how to upload/download docs from it... Thanks in advance.. -- Venkat

Storing files somewhere other than in a database currently isn't supported, but a sufficiently motivated person would probably be able to build this functionality be creating a new implementation of the org.jamwiki.DataHandler interface for accessing a system like VSS. Thanks for the comments! -- Ryan • (comments) • 11-Apr-2009 08:43 PDT

[Edit]Document/Content Level Search

Currently, "Search" Feature supports searching of keywords within the Web Pages.Is there any way to search a given keyword in all of the uploaded documents too. Please let me know how to utilize Lucene search engine to search inside the documents(like eg.doc,ppt,txt,etc) -- Venkat 15-Apr-2009

JAMWiki does not currently implement indexing of uploads, but provided Lucene offers this capability it is probably worth implementing. For performance (and possibly security) reasons it would need to be a configurable option... feel free to add gentle reminders to this request as the 0.8.0 development cycle continues and if there is sufficient interest I suspect it could be something that would make it into that release. Alternatively, if you are interested in implementing it have a look at the org.jamwiki.search.LuceneSearchEngine code and the How to Help page. Thanks for the suggestion! -- Ryan • (comments) • 15-Apr-2009 08:02 PDT

[Edit]Searching keywords in all Virtual Wiki

Currently if we do any search , it performs a search in the Wiki which we are using. Is it possible to perform a search in all Virtual wiki's and provide me a result. If it is possible, plz let me know how to do tat? -- Venkat 15-Apr-2009

Virtual wikis are self-contained by design, but if there is enough demand it probably wouldn't be terribly difficult to add a "search all virtual wikis" option. It would take a few days to implement fully, so I probably won't personally get to it unless enough people seem interested or there is a very compelling argument for implementing it - please feel free to make a case, and if any other wiki implements a similar feature and you can point to references that makes it even easier as there would be a template to follow. -- Ryan • (comments) • 15-Apr-2009 07:58 PDT
I also join the offer to realise search in all virtual wiki. There can be this problem not the highest priority. But such search would be very useful. --shar 17-Apr-2009 06:51 PDT

This feature would be great (and very useful, btw). -- Francois 20-May-2009 01:26 PDT

I did something for this feature in my local installation of JamWiki. If you are interested, I can send you my code. -- Francois 26-May-2009 06:05 PDT
If you're willing to create a branch with your changes in Subversion that would be great - just let me know your Sourceforge ID and I can set you up with Subversion access. See How to Help#Programmers for more info, and thanks! -- Ryan • (comments) • 26-May-2009 09:48 PDT

[Edit]Create a JAMWiki version which works on Google AppEngine for Java

Would be nice to have a JAMwiki version which works with Google AppEngine.

See:

What changes are needed for such a version (datastore, lucene searching, no file system updates,...)?

Google AppEngine isn't something I'm very familiar with, although it looks like a cool idea. Having just quickly skimmed over their docs, I could think that the first step would be attempting an install and then seeing what didn't work, and then addressing issues from there. This probably isn't something that I would personally have time to work on in the near future, but if anyone is interested I can definitely help out with getting it working. -- Ryan • (comments) • 11-Apr-2009 08:45 PDT

Development of a JAMWiki port for the Google Appengine platform (very, very basic at the moment):

[Edit]Using different language stemmers for Lucene

It would be nice to have an option to use a language stemmer for Lucene search indexing:

[Edit]Restricted Search Feature

Currently Search facility is allowing any anonymous user to extract data/documents from any pages. Is there any way to restrict Search facility for Anonymous users? Also, Can we restrict Search facility based on Login Credentials? --[[User:ramanindya55|Venkat Raman]

Have a look at Configuration#Spring Security, which explains how to restrict portions of the site from certain users. Unfortunately there is currently no way to filter search results based on user type/login, but you could at least limit access to the search functionality. -- Ryan • (comments) • 30-Jul-2009 08:00 PDT

[Edit]Other Requests

Is there a way to have an external link (or an internal link for that matter) open the link in another target browser window? I couldn't find any way to do it (even trying to create the link directly with html doesn't work!!) --Arthur Blake 19-Feb-2010 14:33 PST

There isn't a way to do that with internal links, but from Special:Admin there is a configuration option for " Open external links in new window" in the "General Settings" section. -- Ryan • (comments) • 19-Feb-2010 14:48 PST
Thanks! that fills my need for the moment. I think it would be nice if there was a special wiki syntax for doing that on a per-link basis. (I don't know if MediaWiki can do that or not.)
I generally try not to deviate from Mediawiki syntax (even when I disagree with it) since there are so many users that are familiar with it, so if Mediawiki offers that capability please let me know (post an example or a URL that explains the implementation), otherwise it may need to wait until eventually JAMWiki supports extensions to the parser (something that hopefully isn't too far off). If it becomes a significant issue it would probably be relatively easy to copy the current JFlex parser code, make a minor modification, and then run a custom parser on your site - the downside is that you'd then need to track changes from trunk to make sure your code was always up-to-date. -- Ryan • (comments) • 19-Feb-2010 15:37 PST