Current development on JAMWiki is primarily focused on maintenance rather than new features due to a lack of developer availability. If you are interested in working on JAMWiki please join the jamwiki-devel mailing list.

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:

Contents

Mediawiki Compatibility[edit]

Implement FreeMindMaps[edit]

Apparently this function does not exist within JAMWiki while it does perfectly with MediaWiki. http://www.mediawiki.org/wiki/Extension:FreeMind?uselang=de

Included Template Links[edit]

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

Allpages pagination[edit]

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

I like when the index uses meaningful labels like http://en.wikipedia.org/wiki/Special:Allpages, but the page is a bit confusing: 2 links on each line point to the same page. Also long list of ranges looks strange. I would suggest to render it as a pop-up menu. Especially because multi-level narrowing makes each menu not very long.
Similarly the "recent changes" page may order and group pages by timestamps breaking the whole history in the ranges in one menu and by Years/Months/Day in another menu. -- cab 17-Jul-2013 0:52 EDT

Non-Image file upload naming[edit]

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
So is there still anything planned that would enable pdf-file content to show up in the search index? It would be really great to simply upload pdfs of documentations knowing that they would also be searched for keywords.
Cheers, AM 09-Aug-2012, 12:16 GMT+1:00

displaying local time in signature[edit]

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

Feature is available from V1.3.0 -- Charles 31.07.2012 14:15 CEST

Make "Minor Edit" a User Preference[edit]

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

Add Comments[edit]

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

Is there any other stylesheet available for Jam wiki?[edit]

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

Credits[edit]

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.

integrate into BottomArea, make easy to remove[edit]

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.

CC+ support ?[edit]

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.

Anonymous user talk pages[edit]

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

Mediawiki compatibility[edit]

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:

syntax[edit]

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.

backlinks[edit]

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

wanted/orphaned/most/least popular[edit]

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.

Special:OrphanedPages was added in JAMWiki 0.7.0 and enhanced in JAMWiki 1.0.0. -- Ryan • (comments) • 21-Jan-2011 10:21 PST

feed aggregation[edit]

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.

recent visitors and other analysis[edit]

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

most transited links[edit]

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.

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

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

Cancel Button in Edit Mode[edit]

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

Clean up inconsistent EN language translation[edit]

"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?

Multi-server Support[edit]

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.

Mediawiki API Support[edit]

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.

Support for API[edit]

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

SCRAPI - a contrary position?[edit]

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

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

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

SVG Support[edit]

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
SVG Support would be nice! Felipe Avilis • (comments) • 26-May-2011 08:44 PDT

Allow External Images[edit]

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
What is the status of this feature request? Having something comparable to Manual:$wgAllowExternalImages would be very useful to me. My use case is a Wiki which can be comprehensively and cleanly exported and imported between dev, test, and production instances. Because Image files are not currently included in Export (only the file metadata is exported, not the binary), a content writer who uploads a screenshot on the dev instance would also have to upload it individually to the other instances. To work around this, we would like to disable File Uploads, drop the images directly into the webapp's /images/ directory, and externally link to that directory. The referenced images would then be a part of our base JAMWiki deployment. Regards, -- BU 14-Dec-2011 05:19 PST
Aside from the original request there were never any additional requests for this feature, so it never got implemented. I'll put it in Jira, although it's pretty late in the 1.2 development cycle so it might be difficult to get it into the next release. See also Feature Requests#Image Storage, which would allow storing images directly in the database and might also meet your use case requirements. -- Ryan • (comments) • 14-Dec-2011 07:23 PST
I have a fast and dirty workaround coded for myself, so no need to raise the priority on this if no one else has requested it. I'm essentially shortcircuiting ImageUtil.buildImageLinkHtml() to identify custom Image tags in the form
[[Image:Local:filename.jpg|options|caption]]

and build HTML to load the image from an environment-specific location (based on new Environment variables local-image-prefix and local-image-dir). I suppose I could have made a brand new tag, but didn't feel comfortable messing with the parser yet. Thanks for making the code so easy to work with! -- BU 14-Dec-2011 11:26 PST

Enhancements to Existing Features[edit]

Info needed on StartingPoints page[edit]

  1. How to set a Main Page (optional: what it is. Because this will become clear while following your instructions)
    1. A simple search will reveal how many people have persisted with your product in spite of the lack of instruction on how to configure this fundamental item: a landing page. Not everyone installing JAMWiki has installed a Wiki before.
Special:Admin => Virtual Wikis => Pick your virtual wiki => change default topic => save. -- Michael Osipov 03-Mar-2011 02:42 PST

Glad I checked back: so I did that. In the process, I learned that I need to select the virtual wiki to configure (out of a selection of 1). I also learnt that all wikis in JAMWiki are virtual wikis. This is important because the concept is not well known. I'm sure that it's very useful for complicated organizations with multiple teams - but remember: JAMWiki is supposed to be quick and easy. I'm not suggesting that you should have a "moron config", just a sentence of explanation somewhere is enough! Your instruction above was enough (I only had to do a couple of quick searches for "virtual" concepts).

I'm being paid to develop code, I got JAMWiki so that we can pool and retrieve our information quickly. I'm not being paid to learn to use a 3rd-party product (which I know is good - that's why I downloaded it :-).

Er, unless I've fundamentally misunderstood your expectations of your users, I think there's a bug in your dispatcher servlet (or filter - don't know what that's for): I can only land on my landing page if I explicitly add the "/en" (for the default virtual wiki) to the URL. If the URL doesn't specify a particular virtual wiki, the default "/en" is used but the default topic is selected as "StartingPoints", even though I have configured it as MainPage as per your instructions above (and verified that instructions were saved - and created the MainPage topic - and tested with multiple browsers in case there was some kind of caching issue).

I'm not complaining (much ;-) - mine is not a public wiki so I can happily supply the URL with the extra "/en" to people. But you might use this information to understand why your excellent product is not being used more!

Documentation is very much a weak point for JAMWiki, but I haven't personally had a lot of time to improve the situation and efforts to get other contributors involved haven't been very successful. If you've got suggestions for improvement please go ahead and update jamwiki.org as you see fit, and any suggestions you have for getting more people involved in improving the documentation on this site would be very much appreciated. One of my TODO items is to try and do some overall re-organization of how the documentation is laid out (I'm thinking either Mediawiki or Wordpress would be good models to follow) but again, feedback and contributions would be greatly appreciated. -- Ryan • (comments) • 03-Mar-2011 08:26 PST

Authorization, permissions and other monolithic ratings[edit]

Per-page Permissions[edit]

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

File Download Permissions[edit]

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

Access denied page configurable?[edit]

Moved from the Feedback page:

I have been looking around and i can't see that it is - it looks like it has been hard coded to redirect to Special:login - but maybe there is something I haven't found? If it isn't configurable i think it should be - I am using CAS, so I dont want users redirected to the wiki login page as that is useless, and in fact I dont really want the logged in users to be redirected to a login page at all - maybe just a generic permission denied page.

For now i guess i'll change the 403.jsp but it would be nice to have a config param for this.

At the moment you can modify it via the /WEB-INF/web.xml <error-page> parameter, which may help. I'll see if it's possible to make this functionality a bit more flexible, but please remind me if there aren't any updates to this discussion in the next few days as I'll be traveling. Thanks for pointing this issue out. -- Ryan • (comments) • 21-Mar-2009 18:26 PDT

Implementing a UserHandler to access external user data[edit]

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

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

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

Virtual Wikis[edit]

Also see Tech:Virtual Wiki Enhancements for discussion.

Virtual Wikis[edit]

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

Virtual Wiki Title[edit]

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

Rename Virtual Wiki[edit]

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

Delete Virtual Wiki[edit]

Add support to delete a virtual wiki.

Virtual Wiki automation without restarting container[edit]

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

Default Virtual Wiki[edit]

Moved from the Bug Reports page:

I added a new virtual wiki (de) to my wiki and wanted this to make default redirect for http://www.myserver.com/jamwiki/ There is unfortunately no option for. It always redirects to the en version.

My suggestions:

  1. let me change my default wiki just like I want in Special:Maintanence for the default /jamwiki/ mapping
  2. let me set the default wiki loaded depending on browser locale (like wikipedia.org)
  3. let me set a new startpage which shows all wikis available like wikipedia.org does
  4. load en wiki if no other appropriate wiki is available
  5. opening a non existing wiki like /jamwiki/fd displays a regular tomcat 404 instead informing me that this virtual wiki does not exist!
This is definitely a feature that is needed - it has been requested before (see Roadmap#Rename_Default_Virtual_Wiki) and will definitely appear in a future release, there just needs to be someone who has the time to implement it. Apologies for the inconveniences it's causing now. -- Ryan 21-Jun-2007 10:44 PDT
Ryan, sounds great. However, the roadmap refers to point 1 only. I hope the other 4 points are being taken into account too ( to some extent).

Default Language Page[edit]

Moved from the Bug Reports page:

I just installed JAMWiki and en virtual wiki has been created automatically. What confused me that the en part has been loaded with german translation since my firefox is set to de_DE primary. I think this is false behavior becaause en implies that the person wants to have the entire site presented in english. Language settings should only be changed if the user does so in his account settings.

Multiple Image Upload[edit]

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

Excluding stylesheets from spam filter?[edit]

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

Internally convert Windows path to file protocol[edit]

We already can use links to the local file system like this [1]. 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

login/logout[edit]

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

Templates i.e. Infoboxes and introduction of advanced extensions i.e. iframe[edit]

I realise that the last update on template similar to Mediawiki functionality was done in early 2008. Have there been any updates on the Mediawiki Parser and is there anyway to have the ability to introduce "iframe" either via HTML / Javascript.

Maybe its there but I just havent seem to be able to work it out just yet.

-- User:Jon • (comments) • 25-Mar-2009 16:11 EST

Most releases contain some updates to improve the parser and add additional Mediawiki compatibility, for example JAMWiki 0.7.0 contained a number of changes to allow nested templates, to improve support for magic words, and to fix some Mediawiki incompatibilities. As to iframes, currently JAMWiki won't support those, but if support is available in Mediawiki then please feel free to add a feature request, preferably with a pointer to any information about how Mediawiki supports this feature. Alternatively, if Mediawiki doesn't support iframes then there is a long-term plan to allow JAMWiki site admins to configure which HTML tags are allowed, although that feature may still be some ways away from implementation. -- Ryan • (comments) • 25-Mar-2009 11:28 PDT

New Features[edit]

dock other servlet[edit]

Can please allow other servlet to be invoke in the same web-app? Just HelloWorld servlet is OK. At present, it seems that it doesnot work at all even I put the servlet mapping before jamwiki. I need this feature to work since the web hosting I got only allow 1 web-app. jack 06-Aug-2010 18:48 PDT

Just FYI(in case someone also needs this), this should go with by spring framework, and should be configured in jamwiki-servlet.xml. I just noticed this. jack 07-Aug-2010 08:37 PDT

favicon.ico[edit]

Can JAMWiki support the favicon.ico? I don't know how to make it work. jack 27-Jul-2010 15:19 PDT

For now you can add a file named "favicon.ico" to your docroot, and that will work. It probably wouldn't be hard for JAMWiki to implement the <link rel="shortcut icon" href="/somepath/myicon.ico" /> syntax, however. -- Ryan • (comments) • 27-Jul-2010 17:07 PDT
the problem happens when I install the JAMWiki on the root, rather than as this website install it on wiki. I get around it by implement a filter. Maybe you will consider to allow some request to be normal request and serve them directly rather than as a wiki page. Maybe not many people want this. jack 27-Jul-2010 20:37 PDT
I'll add this to Tech:Virtual Wiki Enhancements. -- Ryan • (comments) • 28-Jul-2010 22:00 PDT

Hide/Show section[edit]

In mediawiki, people can choose to show/hide the content table. This feature is not that interesting. What is really useful is to hide/show individual section. For example, this page is very long, it is very hard to navigate unless you are very familiar with the page. With this feature (the ability to hide/show any specific section/subsection) then the content table is useless. By one click, hide all sections, then only section title is show. what we got is a content table. And when the page is short, by a click, expand all sections, people can see the whole page. Of course, javascript should be enable by default then. jack 20-Jul-2010 11:57 PDT

Is there anyone think this is a good feature to have. I have implemented this in a simple way. As for this page, I removed the content table, and put a control for every section, and by default, I hide all the paragraphs. See the presentation here. --jack 06-Aug-2010 15:54 PDT
There have been a few requests to implement a collapsible table of contents, collapsible sections, etc. This would need to be configurable, and I'm not sure if it makes more sense to add an option to Special:Admin, to make it easier to implement custom Javascript, to support different "skins" for pages, or to implement this in some other way, so suggestions would be welcome. -- Ryan • (comments) • 07-Aug-2010 09:23 PDT
collapsible table of contents as the one in many wiki sites is a really bad idea. Collapsible sections is a good one as the one I proposed (though a little bit ugly). But personally, I believe the client side job should be done at the client side. Personally, I believe that it is a bad practice to use spring MVC, though many do so, Instead, JavascriptMVC can be used, in this way, the server can be more efficient since the server doesn't have to deal with presentation, the server only maintain the content and configuration. All the presentation should be implemented by javascript & CSS. And different set of javascript & CSS constitute different schemes, or to put it simple just provide a few xslt is enough. jack 07-Aug-2010 09:49 PDT

digital signature[edit]

Digital signature should be supported. —The preceding comment was added by jackiszhp (commentscontribs) .

Can you provide some further details? Do you mean that editing should require an SSH key for validation? If so, how would you envisioning that would work? Is there another web site that does this that could be used as an example? Is this a capability that Spring Security offers out of the box? Thanks! -- Ryan • (comments) • 15-Jul-2010 07:49 PDT
Hi, spring security seems focus only on authentication, and authorization. That's useful when manage access control. Digital signature is about integrity. For example, this section by now contains 3 messages, but because they are not digitally signed, anyone can edit as they wish, with digital signature, every message's integrity is guaranteed. As I heard, there are some BBSs with digital signature. There are also many XML signature example online, I guess you have to start with signing your email & verifying received emails first. By the way, mediawiki doesn't support digital signature either. jack 20-Jul-2010 11:44 PDT

Automatic Links to Words Matching Page Names[edit]

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

Flash embed capability[edit]

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.
Reminder: <embed> would be great!
I would love to have the flash embed capability added to JAMWiki if not yet. Is it? Lyubo, 2014-01-20
Unfortunately due to a lack of developer time there have not been any new features added for quite some time. If you or anyone you know is interesting in adding embed support see Help:Tag extensions for an idea on how it could be done. -- Ryan • (comments) • 20:36, 20 January 2014 (PST)

Math. formula support[edit]

jsMath Support[edit]

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

JMathTex Support[edit]

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: jmathtex.png

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

Image Storage[edit]

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

Some years ago I see JAMWiki 0.72 and ask about storing images in database. Now I trying to implement this and I have work prototype for version 1.1.0. I test it with HSQL, Postgres, Oracle, MS SQL and DB2 (DB2 now not work, moreover original version of JAMWiki also not work because of table creation problems). Image storage depends on PROP_FILE_DIR_RELATIVE_PATH parameter and may be on filesystem or in database table. What about inclusion this in future version? --avhohlov2
P.S. Maybe user avhohlov also created by me.

See How to Help#How to contribute. If you have a Sourceforge login let me know what it is, and then you can make your code available on a branch in the JAMWiki repository. Once it's ready to merge then it could be considered for the next major release. Thanks, and let me know if you have any questions. -- Ryan • (comments) • 11-Oct-2011 13:52 PDT
My Sourceforge login - avhohlov --avhohlov2
You should now have access to create your own Subversion branch - let me know if you encounter any issues. It would be easiest if you created your branch off of trunk (which has the latest 1.2 code), but if your code is older and that is not possible then do whatever is easiest and we can try to figure out how best to get it into a review-able and, eventually, merge-able state. -- Ryan • (comments) • 11-Oct-2011 21:03 PDT
I merge code for 1.1.0 version with 1.2 and it seems work. For testing current war archive must be renamed into jamwiki-1.2.0.war (how to determine real application name?). And about DB2 - unique/primary key constraints for jam_topic and jam_watchlist tables can't be created because in DB2 such constraint columns can't be null. When I temporary remove jam_u_topic_name constraint and jam_declare watchlist.topic_name as not null database was created, but it may work incorrect? --avhohlov2
I will try to take a look at this as soon as possible, although things might be busy through the weekend. If there is anything (aside from what you've already mentioned) that I should pay particular attention to let me know, otherwise I'll just do a review of your two most recent commits. -- Ryan • (comments) • 13-Oct-2011 15:56 PDT
(Re-indenting) I took a look at the branch this morning, and overall the approach looks good. I had a few minor concerns, but nothing that would prevent this from inclusion in JAMWiki 1.2:
  • Since both images and non-image files can be uploaded it might make sense to name the table jam_file_data rather than jam_image.
OK, but image and link to non-image are the same i.e. Image:Text.txt?
  • It might also make sense to add a constraint between the jam_image table and the jam_file_version table so that the relationship is clear. That would also allow removing some of the columns from jam_image such as mime_type and image_name.
OK. First implementation was simply "file-system emulator". And about key generation. select max(id) are correct only

when table lock acquired. What about using sequences (or one sequence for all tables) if possible?

  • There will probably (eventually) need to be some way for users to import/export files to/from the database if a site ever wanted to switch from file storage to database storage, or vice versa.
Now no way to do this and only new sites may use database storage. Maybe upload/download all images are not too complex

but now I don't think about it...

  • For performance reasons I suspect it will be necessary to try to cache files on the filesystem rather than having UploadServlet always go to the database.
  • This is a minor issue, but there are some Coding Style concerns (tabs for indentation, for example) and use of scriptlets in JSPs should be avoided.
Some code was written before I read about Coding Style

and I use only previous code as sample. Now all indentation must be done with tabs.

I'd be interested in your thoughts, but I like what you've done and would support adding this functionality for the next major release. -- Ryan • (comments) • 15-Oct-2011 11:55 PDT
Please see my comments under items --avhohlov2
Some non-inline responses:
  1. Yes, links are by default of the form Image:MyFile.txt, but that is for historical reasons. Mediawiki has since changed to File:MyFile.txt, and JAMWiki can be configured to do the same. I should probably change the default...
  2. I will look into more sequence implementation - MySQL and Postgres are currently configured for sequences.
  3. A tool to convert file system to database storage and vice-versa isn't a high priority, but I'm sure it is something that people will eventually ask for. I don't think it would be hard to do based on your implementation, so I could always add it later if need be.
  4. Thanks for the Coding Style fixes you've made.
Depending on how busy work gets I may have some time to write code this week, so unless you object I'll try to begin merging your changes. Thanks again for the contribution! -- Ryan • (comments) • 16-Oct-2011 09:07 PDT

As I think basic functionality are implemented. One thing must be corrected - ImageUtil.getImageServletUrl() now can't determine actual url and construct it from parameters values. Now image storing tested with HSQL, PostgreSQL, Oracle, MS SQL 2005 and DB2C (DB2 have a problem with jam_u_topic_name). -- avhohlov2 19-Nov-2011 13:23 PST

Would it be OK for me to try to start merging this code to trunk, or is there still work ongoing? I anticipate some changes may be required when it gets merged, so I'm not sure if you'd prefer to keep everything on a separate branch until you're done with changes, or whether it's easier to get the code merged to trunk and then make changes there. Please let me know your preference. -- Ryan • (comments) • 22-Nov-2011 12:04 PST
Because my knowledges about jamwiki very limited, I think that code review is needed and after it solution may be done.

I found that since I start work you add only minor changed in three files that I also change:

  • jamwiki-core/src/main/java/org/jamwiki/db/AnsiDataHandler.java
  • jamwiki-core/src/main/java/org/jamwiki/parser/image/ImageProcessor.java
  • jamwiki-core/src/main/java/org/jamwiki/parser/image/ImageUtil.java

Therefore merging seems easy.

First question are database scheme. I add jam_file_data table and jam_u_filev_f_id_fv_id unique key to jam_file_version table for fast search of latest file version. This assumes that generated keys are ordered. -- avhohlov2 23-Nov-2011 12:22 PST

Sorry for the lack of response. I think I'll finally have time to start merging this coming week. To simplify things I may try merging to a temporary branch and then from there merge to trunk as that gives me a chance to resolve any merge issues on a non-trunk branch. Additionally, if there are supporting changes needed (for example, allowing users to select whether they want file system or database storage during setup) then there will be a place to make those changes prior to doing the full merge. -- Ryan • (comments) • 04-Dec-2011 10:35 PST

Now selection between file system and database are made by value of Environment.PROP_FILE_DIR_RELATIVE_PATH. May be comment on setup form (blank value - database) are sufficient?

And second. I newer work with some of supported DBMS (including MySQL) so corresponding sql.property files may need changes. -- avhohlov2 06-Dec-2011 13:37 PST

This merged fairly cleanly to branches/wrh2/dbupload. Before merging to trunk I'd like to review the code more closely - while merging some things that could be improved were:
  • There is some cut & paste that can be consolidated, such as in UploadServlet.upload().
  • It would be best to avoid using scriptlets, such as in view-topic-include.jsp
Prior to releasing JAMWiki 1.2 I'll do some testing with MySQL and other databases, so any SQL changes that are needed can be done then. Overall this looks like a nice implementation, and I look forward to seeing this feature become available. Thanks! -- Ryan • (comments) • 06-Dec-2011 21:38 PST
The following changes have been made:
This is getting closer to being ready to merge to trunk - I need to do a bit of local testing and also make sure that the setup and admin processes include instructions on how to use this capability, then it should be good to merge. -- Ryan • (comments) • 14-Dec-2011 21:12 PST

revision 3880 Error at setup:

ERROR org.jamwiki.servlets.SetupServlet - Setup error
java.lang.IllegalStateException: Unable to find configuration file jamwiki-configuration.xml
	at org.jamwiki.WikiConfiguration.initialize(WikiConfiguration.java:154) ~[jamwiki-core-1.2-SNAPSHOT.jar:na]
	at org.jamwiki.WikiConfiguration.<init>(WikiConfiguration.java:80) ~[jamwiki-core-1.2-SNAPSHOT.jar:na]
	at org.jamwiki.WikiConfiguration.getInstance(WikiConfiguration.java:88) ~[jamwiki-core-1.2-SNAPSHOT.jar:na]
	at org.jamwiki.servlets.SetupServlet.view(SetupServlet.java:232) ~[jamwiki-web-1.2-SNAPSHOT.jar:na]
	at org.jamwiki.servlets.SetupServlet.handleJAMWikiRequest(SetupServlet.java:79) ~[jamwiki-web-1.2-SNAPSHOT.jar:na]
	at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:332) [jamwiki-web-1.2-SNAPSHOT.jar:na]

-- avhohlov2 17-Dec-2011 02:56 PST

Do you know if you were getting this setup error before the most recent changes? I suspect that error may be due to either revision 3823 or revision 3753. Also, what application server and operating system are you using? -- Ryan • (comments) • 17-Dec-2011 08:53 PST

I use Tomcat 7.0.21 & 6.0.24. Error depends on OS. It present in Ubuntu 9.0.4 (Open JDK & Sun JDK) and not present in Windows 2000. When I temporary add fixed directory name /home/administrator into ResourceUtil.getJAMWikiResourceFile function

//File resourceDirectory = new File(Environment.getValue(Environment.PROP_BASE_FILE_DIR), RESOURCES_DIR);
File resourceDirectory = new File(!Environment.getValue(Environment.PROP_BASE_FILE_DIR).isEmpty() ? Environment.getValue(Environment.PROP_BASE_FILE_DIR) : "/home/administrator", RESOURCES_DIR);

(Empty directory /home/administrator are created before Tomcat startup) correct Setup form appears and JAMWiki seems work correctly. -- avhohlov2 17-Dec-2011 12:25 PST

Thanks for the additional info - I'll try to get this fixed quickly. -- Ryan • (comments) • 17-Dec-2011 14:22 PST
I think that revision 3881 may resolve this problem - it adds a check to ensure that the wiki has been initialized when reading resource files. This works on my Windows box, although I haven't yet tested on my Linux machine. Let me know if you still encounter problems. -- Ryan • (comments) • 18-Dec-2011 08:56 PST

Now setup work correctly in Ubuntu. I test image uploading. It work in HSQL and Postgres and not work in Oracle.

ORA-01483: invalid length for DATE or NUMBER bind variable
...
at org.jamwiki.db.AnsiQueryHandler.insertTopicVersions(AnsiQueryHandler.java:1919) ~[jamwiki-core-1.2-SNAPSHOT.jar:na]
...

At this time I don't understand this.

revision 3886 fixes an issue I saw with the Special:Image path - there was a "FIXME" on the ImageUtil.getImageServletUrl method indicating that the method was dependent on property values and needed updating, so hopefully my change isn't unexpected and doesn't break anything for you. I tested with Oracle 10g and didn't see the error with topic versions that you mentioned above, but I'll investigate further. -- Ryan • (comments) • 18-Dec-2011 20:26 PST

There are no bug when I change jdbc driver to latest ojdbc6.jar. Maybe this is Oracle jdbc bug 4488715 (ORA-1483 on changing bind types for numeric/date binds) -- avhohlov2 19-Dec-2011 13:17 PST

revision 3886 immediately after setup

java.lang.NullPointerException at org.jamwiki.taglib.LinkParamTag.doEndTag(LinkParamTag.java:48)

-- avhohlov2 19-Dec-2011 13:39 PST

I'll be on a plane tonight so I may not be able to get this fixed immediately, but will try to investigate while at the airport. -- Ryan • (comments) • 19-Dec-2011 14:03 PST
revision 3887 should fix the null pointer exception. I think this feature is ready to merge to trunk unless you disagree. There are a few more things to do, but the code is solid and there's no reason why the remaining work couldn't be done on trunk:
  • I need to add upgrade code so that users who are upgrading will have the new tables created.
  • I'd like to add some verbiage to the setup and Special:Admin pages explaining how to enable database upload.
  • I need to credit you in the CREDITS.txt file. Do you prefer "avhohlov2", or would you like your full name used? For reference, most people are credited as "Full Name (login)", so I'm "Ryan Holliday (wrh2)".
  • Also, how would you feel about adding a "is_on_fs" flag to the jam_file_version table indicating whether or not the file was uploaded to the database? That way if someone sets up a wiki to use database upload and later changes to use file system upload, nothing will break. I'd be happy to implement that functionality if it makes sense to do so.
Once again, thanks for all of your work on this code - the implementation came out very well. -- Ryan • (comments) • 19-Dec-2011 20:03 PST

Minor bug in view-topic-include.jsp/file versions list: value="${fileVersions[0].fileVersionId}" -> value="${fileVersion.fileVersionId}"

Upgrade: I think about standalone utility for upload all existing images to database. It may read jam_file_version table, read corresponding files and store it in db.

Possible comments in ApplicationResources.properties: admin.upload.help.uploaddirrel=Root path used in <img> and <a> tags; if the file upload directory is /docroot/wiki-files/, then the relative path is /wiki-files/. When blank, files are stored in database.

Equivalent in ApplicationResources_ru.properties: admin.upload.help.uploaddirrel=\u041A\u043E\u0440\u043D\u0435\u0432\u043E\u0439 \u043F\u0443\u0442\u044C \u0438\u0441\u043F\u043E\u043B\u044C\u0437\u0443\u0435\u0442\u0441\u044F \u0432 \u0442\u044D\u0433\u0430\u0445 <img> \u0438 <a> . \u0415\u0441\u043B\u0438 \u043A\u0430\u0442\u0430\u043B\u043E\u0433 \u0437\u0430\u0433\u0440\u0443\u0437\u043A\u0438 \u0444\u0430\u0439\u043B\u043E\u0432 /docroot/wiki-files/, \u0442\u043E \u043E\u0442\u043D\u043E\u0441\u0438\u0442\u0435\u043B\u044C\u043D\u044B\u0439 \u043F\u0443\u0442\u044C /wiki-files/. \u0415\u0441\u043b\u0438 \u043d\u0435 \u0437\u0430\u043f\u043e\u043b\u043d\u0435\u043d\u043e, \u0434\u043b\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0444\u0430\u0439\u043b\u043e\u0432 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u0431\u0430\u0437\u0430 \u0434\u0430\u043d\u043d\u044b\u0445.

About is_on_fs. This flag may be determined by searching in jam_file_data. And in current implementation no way to mix filesystem and database storage. At this time I don't know.

About CREDITS.txt. My name is Andrei Khokhlov. So "Andrei Khokhlov (avhohlov2)" may be.

And last. I think about change in version 1.2.0 key generation mechanism for Oracle. This requires changing all STATEMENT_SELECT_XXX_SEQUENCE queries (this is simple). Creating sequences for each table with auto-generated key (it may be done in one anonymous block). This block also may be used for upgrade (before sequence creation starting number must be determined).

I fixed the bug you reported (revision 3890) and added code so that users who are upgrading will have the jam_file_data table created automatically (revision 3892). If there are additional issues that need fixing you are welcome to commit the fix directly to the /wrh2/dbupload branch. I'll try to get everything merged to trunk tomorrow, including updating CREDITS and adding the help text you mentioned, but unfortunately I didn't have a lot of time tonight.
As to using generated keys with Oracle, support for that capability already exists for Postgres and MySQL (see PostgresQueryHandler.autoIncrementPrimaryKeys and MySqlQueryHandler.autoIncrementPrimaryKeys), but I never implemented generated keys for Oracle since I'm not as familiar with Oracle's SQL syntax. If you'd like to commit an update that enables this functionality for Oracle it would definitely be appreciated. -- Ryan • (comments) • 20-Dec-2011 22:02 PST

Oracle documentation declares support of getGeneratedKeys() but I can't directly get inserted key value - result set contains only ROWID (row identifier). ROWID may be used for subsequent select but it requires extra select statements. Current implementation explicitly select next id value from sequence rather than max(id) from table. -- avhohlov2 21-Dec-2011 13:52 PST

Everything should now be merged to trunk except for the help text - I'll try to get that done tomorrow night. If there are any bug fixes or additional changes you would like to make please go ahead and commit them directly to trunk. Thanks again for the code! -- Ryan • (comments) • 21-Dec-2011 19:35 PST

Stand-alone utility for loading files in database JAMWikiFileLoader.java -- avhohlov2 12-Jan-2012 13:02 PST

Thanks! Time permitting I'll try to incorporate this tool into the Special:Maintenance page. A couple of additional notes:
  • In recent commits I've made the "database storage" option something that can be selected from the "File Upload Settings" tab of the Special:Admin page, and also something that is selectable during setup. I think that's a fairly easy way to enable/disable this, but let me know if you have any concerns.
  • I'm wondering if it might make sense to use a file name rather than "Special:Image?id=1234" when specifying images. Something like "/files/my_image_file.gif", where the "/files/*" path would be intercepted by a servlet that could then look up the image details based on the file name. This would have SEO benefits and I think can be done fairly easily with minor tweaks to the current code - again, let me know your thoughts.
  • What are your thoughts on potentially caching some of this data on the filesystem? Resizing images in particular is a slow operation, so it might make sense to store resized images on the file system. Again, this would be an easy change to make, but I'd be interested in your thoughts.
-- Ryan • (comments) • 12-Jan-2012 16:06 PST

Bug in revision 3950? In initial setup form fields for absolute and relative upload directories appears. In 3949 are not. Also when choosing persistence type fields for driver etc always visible and are not filled.

I test performance of image processing with one 4 Megabyte jpeg image (3072 x 2304) and page with seven different scaled versions of this image (100px - 700px wide) on AMD64x2/2000MHz. There are no significant differences between file system storage, Oracle and Postgres. When test page requests first time it appears after ~12 seconds (file system) or ~15 seconds (both databases). When test page requests next time it appears after less then 1 second.

About using file names. jam_file and jam_file_version tables have file_url fields that unique. If necessary it may be used to select corresponding file_version_id.

-- avhohlov2 14-Jan-2012 02:45 PST
Can you verify that your webapp isn't using a cached JSP for setup.jsp? revision 3950 changed parser code and shouldn't affect setup, and this seems to work for me locally. As to caching resized images, if there is no benefit to putting them on the file system then obviously the current code is fine. I'll look into using a more SEO-friendly image name as I think that would be a useful change. -- Ryan • (comments) • 14-Jan-2012 13:51 PST
revision 3958 changes the URL format from "Special:Image?fileId=X&fileRevisionId=Y&resized=Z" to "/uploads/X/Y/Z/example.png", which should be more SEO-friendly. I haven't tested this well, but will test it over the next couple of days. -- Ryan • (comments) • 17-Jan-2012 22:13 PST

While I think about using of fictitious parameter fileUrl in addition to fileId etc or using fileUrl to retrieve fileId/fileVersionId you implement another solution.

And about setup. This screen are correct or not:
Setup-1-2-0.png
And when I select some database jdbc-related fields are not filled with predefined values. In earlier versions this filling are performed. -- avhohlov2 18-Jan-2012 12:28 PST

If you would prefer I can modify the code to lookup via URL - let me know. The current approach required the least code change and avoids the extra lookup, but the downside is that the file_url value is mostly used only for display purposes and there is an extra sub-directory in the URL path.
As to your setup issues, one of three things could be happening: your app server is serving an old version of setup.jsp, the jamwiki.js isn't loading or is loading a cached version, or there is a Javascript error. If you clear your app server's JSP cache does it work? If not, does your browser show any Javascript errors? Does the /js/jamwiki.js file load in your app server? It's also possible that jamwiki.js may be serving a cached version, in which cases I can try to append a version-specific cache-buster parameter to the URL. -- Ryan • (comments) • 18-Jan-2012 13:59 PST

Setup problem depends on Tomcat version and not depends on OS. With 6.0.24 all ok, with 7.0.21 problem occurs and removing tomcat directory not solve it. -- avhohlov2 19-Jan-2012 12:49 PST

I was able to reproduce this tonight (finally). It appears that the jamwiki.js URL is converted by the c:url tag to jamwiki.js;jsessionid=1234 on Tomcat 7 when cookies are cleared, and the JS file then fails to download. revision 3962 fixes the problem for me, but please let me know if you're still seeing issues. -- Ryan • (comments) • 19-Jan-2012 20:42 PST

I see some difference but it work.

Current html:

<script type="text/javascript" src="../js/jamwiki.js?setup"></script>

Previous html (not work):

<script type="text/javascript" src="/jamwiki-1.2-SNAPSHOT/js/jamwiki.js?setup"></script>

-- avhohlov2 20-Jan-2012 12:20 PST

PageUp-Link[edit]

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

Favorites (or new watchlist functionality)[edit]

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

Diagram editor[edit]

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


Sequence Diagram[edit]

Is a good idea to integrate http://trace2uml.tigris.org/ into jamwiki

CamelCase / WikiWord Support[edit]

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

More public methods[edit]

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

JAMWiki extensions[edit]

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

Wiki Syntax: Page properties as variables[edit]

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

Display backlinks as navigation help[edit]

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

Inline Linking[edit]

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 for the link (and other) syntax. -- Ryan 17-Apr-2007 20:44 PDT

OpenSearch[edit]

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.

XML-RPC API[edit]

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
I see that this request is rather old. I think that JAMWiki fits nicely to business environment as a documentation part of business applications, especially Java rich web applications (all can be installed on one instance of Java application server like Tomcat). Confluence compatible API seems to be right choice, while many already existing plugins (Eclipse for example) can be reused. Through this API can be interlinked web business application(s). -- vrecion 20-IX-2012 13:18 PDT

Comments & Mailing List[edit]

Moved from the Feedback page

Comments[edit]

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

Prefer lowercase[edit]

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.

Howto: Direct database access[edit]

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

Missing tabs[edit]

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

Upload into DB[edit]

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

HTML to Wiki converter[edit]

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

Tag and category integration[edit]

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.

Authorization, permissions and other monolithic ratings[edit]

Jabber support[edit]

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.

Forgotten passwords[edit]

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

I'd really like to see this feature. It makes administering a wiki with many users much easier. -- Brian 2/8/2012
Email integration is something I'm hoping to (finally) implement for JAMWiki 1.3, but please keep reminding me since having people show interest in a feature is useful when determining how to allocate available development time. -- Ryan • (comments) • 08-Feb-2012 21:55 PST

Hardwired reputation system[edit]

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

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

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.

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

New message notification[edit]

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

Email Support[edit]

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

Mailing List Integration[edit]

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.

RSS[edit]

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

RSS Enhancement[edit]

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

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

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.

Factional reputations[edit]

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.

3RR[edit]

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.

Blog[edit]

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

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

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

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

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.

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

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 />?

User Interface[edit]

Option to Delete Original Page when Moved[edit]

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

This sounds to be a convenient feature, but there are some issues to keep in mind:
  1. It would be a deviation from the Mediawiki behaviour. But a desirable one. BUT!
  2. Deleting the old page would break all links to it. The redirect generation mechanism keeps all links alive. So the optional 'Do not redirect' functionality would have to check whether there are links and deny deleting the old page.
Kind regards, Rudi Rudi Wiesmayr (AT) 14-Mar-2010 08:24 PDT
Agreed, deviations from Mediawiki that aren't obvious improvements are unlikely to be implemented as JAMWiki defaults, and won't be development priorities unless there are a lot of users asking for them. A major advantage of using Mediawiki as a reference is that they have had time to let functionality mature, so following their lead generally helps avoid headaches such as #2 above, and provides behavior that users are used to seeing elsewhere. Eventually I'd like to make JAMWiki much more user-customizable via plugins or extensions, and once that infrastructure is in place then hopefully functionality such as what is requested above could be implemented without affecting the core JAMWiki distribution; until then, however, this isn't something that I'm planning on devoting development attention to. -- Ryan • (comments) • 14-Mar-2010 11:33 PDT

Syntax Highlighting[edit]

We would really like to have syntax highlighting for source code fragments. I know that there is an extension for this at [2], but this does not work with jamwiki. Can this functionality be added? If so we would like to see the following languages supported, java, javascript, c/c++, css. Thanks. --Wade April 1, 2010

I believe that the Bliki parser may already offer this functionality - see the User:axelclk page for some details. You can configure your wiki to use the Bliki parser from the Special:Admin page, but note that the Bliki parser has its own Google code project setup for feedback and bug reports. Parser extensions for JAMWiki are something that I'm considering for the next major release, but that is likely at least six months away. -- Ryan • (comments) • 01-Apr-2010 17:20 PDT

Hi, I needed this functionality too. I managed to introduce it using javascript based syntax highlighter from Alex Gorbatchev: http://code.google.com/p/syntaxhighlighter/. I added a post about how to do it. I don't know if it's good way, but certainly it's fast and it works: http://sinnerinc.blogspot.com/2010/07/adding-syntax-highlighter-to-jamwiki.html

Cheers, Matt • 08-July-2010

Thanks! Hopefully JAMWiki 1.0.0 will make this sort of integration easier as FCKEditor is integrated, so if you have any feedback in the coming months as that development moves along it would be much appreciated. -- Ryan • (comments) • 07-Jul-2010 18:08 PDT

Global Find and Replace[edit]

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

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

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

WYSIWYG Editor[edit]

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

FCKEditor for Java Application[edit]

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

We use the FCKEditor on an internal wiki page I'm trying to move the Enterprise Monitoring group off of. I have the files we used to get this to work on the wiki we use. I can zip and email these to someone to test. - Jarrod Munger mailto:jmunger@directv.com

Hi Jarrod - I'd be interested in the approach, and if it's a complete implementation then I'd be thrilled to get it included in a future JAMWiki release. My own experience in trying to integrate the Mediawiki + (F)CKEditor tools was that it was incomplete, and tended to lose any complex markup like templates, TOC tags, categories, etc. If those issues have been overcome, however, then it would definitely be worth re-visiting. jamwiki.org should allow uploads of up to 10MB, so if you could upload your version here I'll take a look. -- Ryan • (comments) • 12-Jul-2011 09:22 PDT

Ryan- I found this information on a simple way to add the FCKEditor to a java wiki. Have you looked at this URL before? http://jamwiki.org/wiki/en/Tech:FCKEditor_Integration#Simple_way_to_add_fckeditor_as_Jamwiki_editor - Jarrod Munger mailto:jmunger@directv.com 13-Jul-2011

I'm actually the author of most of the content on that page - it was meant to be a source for developer discussion, but as noted there isn't a way (currently) to integrate FCKEditor that doesn't involve significant trade-offs. If you use the steps outlined then templates and metadata are lost during editing. The Subversion branches/wrh2/fckeditor branch has the most up-to-date FCKEditor+JAMWiki integration that I'm aware of (this is my own branch) but the metadata issues are a showstopper for rolling that out as part of a supported product. -- Ryan • (comments) • 13-Jul-2011 09:45 PDT
First of all: Thanks to you (Ryan) and your community in doing great job. Is there any news on this thread. Or is there another stable WYSIWYG-Editor for jamwiki available? Because we think, that implementing such an editor would save a lot of time for our company in doing internal documentation. Anil from the Alps • 01-Mar-2012 09:04 CET
There are HUGE benefits to having a working WYSIWYG editor, but it's also proven to be a massive technical challenge. JAMWiki 1.2 will not include any editor updates, but I'll make sure that (at a minimum) the existing editor tools are improved for 1.3. -- Ryan • (comments) • 01-Mar-2012 16:17 PST

Special:History[edit]

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

Testing[edit]

"Fuzz Testing"[edit]

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.

Webtests[edit]

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>
 javax.el.PropertyNotFoundException: The class 'org.jamwiki.model.WikiUserInfo' does not have the property 'writeable'.
</p>

Better for webtesting would be:

<p id="system-error">Ein Systemfehler ist aufgetreten. Die Fehlermeldung lautet:</p>
<p id="system-error-0">
 javax.el.PropertyNotFoundException: The class 'org.jamwiki.model.WikiUserInfo' does not have the property 'writeable'.
</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

Installation[edit]

Fewer Options[edit]

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.

Checksums[edit]

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

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

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.

Database owner vs. database user[edit]

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.

Technical Features[edit]

OpenSocial API support[edit]

See above under social features.

JSR-168 Portlet Support[edit]

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

Java content repository[edit]

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

Store less text for topics[edit]

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.
"Delayed merge" may work, removing the intermediate edit of three edits by the same user in a sequence after the long expiration period (can be days or weeks). This can be done in a separate thread that runs periodically or can be initiated after one more edit on the topic. Intermediate topics could be preserved if they were done not in a rapid sequence (say on hour or more between edits), even by the same user. audriusa 05-Aug-2010 04:02 PDT.
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.

Architecture and design[edit]

Addon, plugin, extension[edit]

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

Wiki Engine[edit]

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.

Hibernate[edit]

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

Use of Spring Dependecy Injection[edit]

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

Add ability to parse jsp tags[edit]

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: [4] (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

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

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 in the JIRA bug tracker 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

YUI Integration with JamWiki[edit]

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}} : 21461 (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

File storage/access from Microsoft VSS[edit]

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

Document/Content Level Search[edit]

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

Searching keywords in all Virtual Wiki[edit]

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

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

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):

GAEWikis wiki engine, supports almost all features of the current version of JAMWiki. 28-May-2013

Using different language stemmers for Lucene[edit]

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

Restricted Search Feature[edit]

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

Search Results Summary Format[edit]

In Jamwiki 0.7.1 (and on this wiki) search results do not show a properly formatted summary for each result. The summary shows the wiki formatting etc.

I have not been able to find reports of this anywhere which surprised me, especially as the Jamwiki site has the same problem!

Initially this was by design, since users are often searching for a term that might not appear in the parsed text. I can take a look and see how hard it would be to add a configuration option to parse the search summary result. Thanks for the report. -- Ryan • (comments) • 17-Apr-2009 08:26 PDT

Extend Search[edit]

I assume that the Project namespace isn't index by Lucene? Can you implement an option, to extend the search for default namespaces like User, Project or Help. --cinhtau 18-Aug-2010 01:18 PDT

Some of the recent namespace changes should make this easier to implement, possibly for the 1.0.0 release. If you're willing to follow-up occasionally and provide gentle reminders I'd be grateful, as user interest tends to be a big driver for feature implementation. -- Ryan • (comments) • 18-Aug-2010 07:29 PDT

Dual LDAP & local authentication[edit]

I followed the instructions for setting up my wiki to use LDAP and got that all working. I think, however, that it might be better to think in terms of adding authentication methods, rather than supporting a single method. For example, i think that locally created accounts (like the admin account) should always work. This way, even if your LDAP connection is broken you can still provide some minimum level of access to the wiki. Also, it prevents the chicken or the egg issue of when to create user accounts vs when do you change authentication over to LDAP. Along those same lines it would be nice if you didn't have to create a local account first before the account would work with LDAP. ie, could the wiki create the skeleton database entries for users logging in for the first time? dkp • (comments)

Breadcrumbs[edit]


Add the BreadCrumbs extension, this extension shows the users path through the wiki.

BreadCrumbs extension shows the users path through the wiki. Allows for ease of use when creating and updating pages
Installation

  1. Download the latest snapshot and extract it to your extensions directory
  2. Into your wiki's LocalSettings.php, Add
    require_once("$IP/extensions/BreadCrumbs/BreadCrumbs.php")
    
  3. Installation can now be verified through Special:Version

Options

By default the following options are set by this extension:

$wgBreadCrumbsDelimiter = ' > '; // delimiter between breadcrumbs
$wgBreadCrumbsCount = 5; // number of breadcrumbs to show
$wgBreadCrumbsShowAnons = true; // showing breadcrumbs to anonymous users

You may change each one of these parameters by including it with a new value into your LocalSettings.php below the initialisation of this extension.


I have the .php files needed to load this feature. We use this on the old Enterprise wiki. I can email a zip of the .php files for testing. -- Jarrod Munger mailto:jmunger@directv.com

I'm not sure I understand - JAMWiki uses JSP (Java), not PHP. Are you sure your installation is a version of JAMWiki? -- Ryan • (comments) • 12-Jul-2011 09:24 PDT


View the change list from source version control, such as subversion[edit]

We really hope there is a feature to view a change set from from source version control. For example the check in(revision) #1231 in the subversion fix a bug. then we can use below syntax to view the file in this check

[[svn : http://my_subversion_repo/#1231]]
I'm not 100% sure I understand the request, but there is definitely no out of the box integration between JAMWiki and Subversion. However, Subversion has numerous tools for publishing a repository to the web, making it easy to create a template such as Template:Rev that allows you to link to the change file, for example revision 3656. -- Ryan • (comments) • 26-Aug-2011 11:29 PDT

ability to expire pages[edit]

I had a co-worker ask today about the ability to set an expirey date for a given page. I don't see anything like that and i was wondering if that capability is on the radar. —The preceding comment was added by DanPrekker (commentscontribs) .

I'd need more info about what specifically is meant by "setting an expirey date for a page", but it's definitely not something that is on the current Roadmap. If there is another wiki that implements whatever functionality you'd like it would be hugely helpful to have a pointer to their documentation so I could better understand what is being requested, since I'm not sure I understand the use-case. -- Ryan • (comments) • 17-Oct-2011 15:22 PDT

How does one go about creating and inserting a Category Tree into a JAMWiki site?[edit]

Below is a Tag Cloud that is currently in place on the SWiK site (http://swik.net/jamwiki). When you click on any word in this tag cloud box -- so for example, click on MediaWiki -- and you are redirected to a page that lists a bunch of links to content that has been tagged with jamwiki + MediaWiki.

(1) Does anyone know how this tag cloud was implemented on SWiK.net?

swik.net - jamwiki - tagcloud example.jpg

And the 2nd figure is a sample tag cloud which shows what I'm seeking to accomplish on a JAMWiki site. MediaWiki.org has extensions that can be downloaded and installed on a site built in php, right? (using MediaWiki). On a JAMWiki site, however, my understanding is that php extensions won't work.

(2) So my question specifically is how to create a Tag Cloud engine that can output 300 words and when the user clicks on any word (or phrase) in the word cloud, the user is redirected to:

  • a wiki Category page with that word as the title of the category page -- and/or
  • a list of wiki topic pages and category pages where that Tag word is found

I'm not a programmer, but I work with programmers so if pointed in the right direction, I'll get the needed help to implement this feature on our JAMWiki site. Thanks! Jeffrey Western jwestern 29-Sep-2011 14:44 PDT

tag cloud example.JPG

I actually worked on a number of projects in that tag cloud - there was unending confusion about why our sprint was named Bongwe :-) Responding to your two questions:
  1. I'm unfortunately not familiar with SWiK.net.
  2. JAMWiki does not offer tag cloud functionality out of the box, but a sufficiently motivated developer would be able to write custom code to generate something similar to the above.
Since JAMWiki is a Java-based system you're correct that it won't support PHP. For a developer to build this functionality they would probably start with by mining data from the jam_topic_links table, which would give the number of incoming links for every topic. In addition a custom servlet and JSP could then be built to render that data - the existing code in the org.jamwiki.servlets should provide examples to follow. This wouldn't be a simple task, but if this is a feature that you need and you have an experienced Java developer I would be happy to walk through a design if that would be helpful. -- Ryan • (comments) • 29-Sep-2011 17:56 PDT

Many thanks for your suggestions... I'll pass them along to the PM and see what they want to do... Would you know of a Java-based category tree that could be installed on the JAMWiki? MediaWiki has a category tree extension, but same problem in that it's PHP. Is there a way to convert a php-based extension to Java? Cheers 30-Sep-2011 11:11 PDT

I'm not aware of any Java-based category tree utilities, but I'm sure there are probably a few out there. I'm also not familiar with any PHP-to-Java converters and tend to be a bit skeptical of tools to convert between languages since (for example) PHP is a scripting language that wouldn't necessarily translate well to an object-oriented language like Java. -- Ryan • (comments) • 30-Sep-2011 11:31 PDT

Is it possible to create dynamic pages?[edit]

I am Newb. I want to set up a set of virtual wikis with the following properties.

  • users must log in to access the the virtual wiki pages
  • some user can edit, others can only read
  • The information on the page is customized for the particular user.

In the past I would create and host websites using Tomcat,mysql, Spring-framework security, web services, servlets, and JSP pages. This model no longer works for my current projects because we need to set up a way for the web pages to be created by non-technical people. Is there a way to implement JSP like functionality? I.E. is there a way I create some sort of package authors can put on their pages. When user view these pages, the package fetches content from my web service? maybe some way to use macros, widgets, DHTML, HTML fragments, <iframes> ???

Also is it possible to create virtual wikis or pages programmatically?

Thanks

Andy

p.s. Did I set this feedback question correctly?

JAMWiki is simply a wiki engine, so it doesn't provide any out-of-the-box way for you to run embedded JSPs, although you are free to modify the code to suit your needs. By default the software will let you control access to pages with Spring Security (see Help:Permissions), you can enable Javascript in your wiki if you want (see Configuration), and you can use Mediawiki templates (see Help:Templates) but this may not be sufficient to meet all of the requirements that you have outlined. -- Ryan • (comments) • 09-May-2011 22:09 PDT

Pluggable Namespace behavior[edit]

Some of the built-in namespaces have special features like including corresponding image at the top of the page in Image namespace or generate content of the page all together like Category pages.

It would be nice to be able to define this kind of behavior (altering page before presenting to the user and after user submit page to save/preview). I see that as Java class configured to handle a few predefined events for specific namespace.

This also could be the way to allow dynamic pages. -- CAB • 01-May-2012 16:11 EDT

Other Requests[edit]

Plugin framework[edit]

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

Suggestion - please consider using Java Plug-in Framework (JPF) Project as a means for others to develop consistent plugins. -- Magick 16:10, 01 February 2013 (PST)

I'm not familiar with this framework, but per [5] it appears to have last been updated in 2007. Is that the right code to be looking at? Is it still under active development? -- Ryan • (comments) • 22:59, 02 February 2013 (PST)

Android Package[edit]

  • I've seen that i-Jetty is available for Android. We would use JAMWiki everywhere, everytime as localhost on Android device, if JAMWiki could run on i-Jetty+ with SQLite, HSQL, ... .

Embedding the parser/engine in existing web-application[edit]

Is it possible to call the parser from regular JAVA-code? I'd like to embed some WIKI-markup in my application and would like to use the JAMWiki-parser/engine for this. Are there any code-examples for how to do this? Thanks, Andreas Joseph Krogh andreak 13. dec. 2011

It can be done but it's tricky as you will still need a valid DataHandler and to satisfy other dependencies. If you view the source the jamwiki-core/src/test/java/org/jamwiki/parser/jflex/ParserTest.java test cases provide one example of how this could be accomplished. -- Ryan • (comments) • 13-Dec-2011 07:45 PST
I'm not sure how this comment-stuff works, so I just edit this paragraph. Hope it's "the right way". Anyway, thanks for the answer. I've checked out the sources and browsing the source in IDEA. I've run the ParserTest test. I would be very grateful if you provided some info about what miminum configuration required to parse some wiki-markup as string and feed it to the which returns String(html). It would be *really* cool if you could commit a test-case showing how to take some String-argument with wiki-markup and returning the String-representation of the HTML. Thanks, Andreas Joseph Krogh andreak 15. dec. 2011
Have a look at ParserTest.parserResult() - that test case does essentially what you're asking for. I unfortunately will probably not be able to provide an example that does the necessary setup of the ParserInput, DataHandler beyond what's already there in the test cases, but if you have specific questions let me know and I can try to help out. -- Ryan • (comments) • 15-Dec-2011 14:49 PST
I have it working now using code from that test. The parser seems very coupled with the database-setup etc. I ended up using my own SearchEngine and DataHandler implementations, which are more or less empty, except from DataHandler.lookupNamespace* which I had to return something in order for the parser to be happy. Would it be possible to separate the parser more form other initernals of JAMWiki? Anyway, thanks for the help! -- andreak 17-Dec-2011 17:03 PST

Formatting Help[edit]

I created a table with and put some information on the rows and columns within that table. Now I want to add some text information to be displayed below that table. Whenever I attempt to do so , the text appears infront or above the table. Even if I type the text content after giving several line breaks , the text rolls up to the instance above the table. Any Help on getting this sorted would be appreciated.


Table and Excel Sheet[edit]

  1. Can export a wiki table as an excel sheet
  2. Can import a excel file/sheet as a wiki table


Live edit[edit]

Is there extension? see [mojomojo.org]

Social network integration[edit]

to "share with" facebook, twitter, livejournal, like in twiki

Patrolling[edit]

For easier maintenance by multiple administrators it would be good to mark new change like the "change needing patrolling" and reset this flag after somebody having "patrol" role has viewed the difference. "Autopatrol" role could also be implemented for the trustworthy users. The "needs patrol" flag could be visible in recent changes and maybe in the article history. The good place to store the flag seems some field in the recent change table in the database audriusa 05-Aug-2010 04:13 PDT.

I have a web site that I'm hoping to get up & running in the coming months that will need this functionality, so it's moving up on the TODO list. If someone else is interested in working on the implementation I can help with a design, otherwise please continue to remind me about your need for this feature so that it stays high on my personal TODO list. -- Ryan • (comments) • 05-Aug-2010 07:30 PDT

Shortcut Icon[edit]

A very simple stuff, adding these feature makes interesting browsing experiences.

<link rel="SHORTCUT ICON" href=""/jamwiki/en/myicon.ico"/>

Making it customizable for each page makes more fun. —The preceding comment was added by 115.87.170.174 (commentscontribs) .

Interwiki links - Open in new window/tab?[edit]

I've done some searching, but I haven't found anything about this. If this is answered somewhere else on the site, please forgive the duplication. With that out of the way...

Is there a way to make interwiki links open in a new tab/window? (mimicking the behavior of external links) My teammates and I are using Jamwiki to document our internal procedures. I created an interwiki tag to link to other internal knowledge-bases, but we want to keep the current page open for reference. Thanks for the help!
-- Greg (the user formerly known as Loopback) 13-May-2011 16:50 PDT

There's currently no out-of-the-box way to implement this, but it would be easy to add. If you wouldn't mind, could you add a request in JIRA and I'll do my best to get the change into an upcoming release. -- Ryan • (comments) • 15-May-2011 12:04 PDT

Way to integration with exist service with common authentication framework?[edit]

My scenario is to integrate Jamwiki into my exist web service using exist web service authentication method. detail scenarios will be

  • hide login/out, watchlist, account menu from top of Jamwiki
  • user login/out through exist web service
  • when user login or out successfully to exist web service, then exist web server send required information to Jamwiki for user activity.

Is this scenarios possible with current 1.1.0? if so, Will someone can document how to do that? if not, which part of code should I investigate to?

See Permissions#Spring Security for details on you can configure Spring Security to use a web service for login. To remove the login, watchlist and account menus you'll need to modify the JSPs found in the WEB-INF/jsp folder to remove those links, although it might be possible in a future release to allow those links to be hidden as a configurable option. -- Ryan • (comments) • 18-May-2011 07:41 PDT


Export xml format[edit]

Hi Ryan!

At exporting a page it would be nice if:

  1. the xml format can use utf-8 encoding.
  2. The usage of html encoded characters like &#xxx; is a not too nice. If the topic contains xml fragmants than the html encoding use & sign and lt; instead of > or & sign and gt; instead of < it is not too nice also. I think you need to use in the export file CDATA like this: <![CDATA[<sender>John Smith</sender>]]> A link about the subject: CDATA
  3. Nice to have also an export all topics checkbox at export page with checking this you can export all topics of a given namespace.

Csaba Tenkes

Thanks for the report:
  1. It looks like JAMWiki isn't exporting as UTF-8 when it should; that is something that will need to be fixed.
  2. The JAMWiki XML export doesn't use CDATA in order to be consistent with how Mediawiki exports XML - they also escape the text and export plain (example: http://en.wikipedia.org/wiki/Special:Export). I think JAMWiki actually did export as CDATA originally, but it was changed to be consistent with Mediawiki.
I think using CDATA could be better for Tech Wikis. Can't it be an option wether the user would like to use CDATA or not? At the export/import page? Csaba Tenkes 28-Nov-2011 07:57 PST
  1. "Export all topics" might be a good tool for administrators, but it would be problematic to offer to all users since it would have performance issues. As an example, http://jamguides.com has tens of thousands of topics in the main namespace, so an "export all" would generate gigabytes of data. I'll need to give that example some additional thought - do you have a particular use case? Maybe if I understood better how it would be used it would be easier to figure out how such a feature could be implemented.
-- Ryan • (comments) • 03-Aug-2011 17:48 PDT
I've logged a bug for the UTF-8 issue at http://jira.jamwiki.org/browse/JAMWIKI-41. It is too late to get this change into JAMWiki 1.1 since it will require updating the commons-lang package, but it will definitely be included in JAMWiki 1.2. -- Ryan • (comments) • 03-Aug-2011 19:54 PDT


Use Case for Bulk Export/Import Features[edit]

We are hoping to use JAMWiki as part of a larger software release (to support this software's Help / Knowledge Base). In this setup, JAMWiki is staged internally and loaded with content by content writers. It is then deployed to a testing environment for review. Finally, on the day of the software release, it is stood up at a production-level, and that production instance becomes the definitive source of edits from then on. However, during the staging / testing phases, it would be very useful to be able to clone wiki instances with bulk export/import (and since a content writer might do this, it should be doable via the UI, not DB export/import). In particular:

  1. It would be nice if the administrative version of the Export special page allowed an Export All (as discussed in the previous feature request above). Initially, we're probably going to hook into the getAllTopicNames() method to prepopulate the special page textarea with all of the topic titles to accomplish this.
  2. It would be nice if the Import special page had an option to "add to existing topic". Currently, if a topic is already on the target wiki, Import fails. It would be nice if the Import process merely added a new TopicVersion to an existing topic instead. I see this as generally useful, but it also addresses the specific special pages like the Stylesheet -- if you want to clone the look and feel of the staging wiki in the testing wiki, you have to delete the Stylesheet from the testing wiki and readd it, or transfer the content by cut and paste.

Ultimately, I'm hoping to create a "one-click" installation process that:

  1. Automatically deploys JAMWiki on the appserver with custom properties file
  2. Automatically sets up the database tables
  3. Automatically does an initial bulk load of content, including Special Pages, via the Export hooks
  4. Starts up ready to roll.

Today, without custom code, this installation process looks more like:

  1. Automatically deploy JAMWiki.
  2. Start it up and hit Configuration to initialize the database tables and generate the properties file
  3. Manually edit custom configuration properties (like date formats)
  4. Manually edit the starter Special Pages
  5. Manually do an import of initial bulk load, excluding Special Pages.

I'll be sure to pass on any custom code I develop that might be of more general use.

-- BU 16-Nov-2011 04:55 PST

Thanks for the heads up - I'll look into the "export all" capability, and will be interested to see what you come up with - let me know if there's anything else you need to help support this effort. You might also want to look at Tech:Upgrade Simplifications (planned for JAMWiki 1.2) which may simplify some of the automated deployment work.
One note with respect to "export all" - it will have performance implications for large sites. Do you have any suggestions for working around that other than allowing the feature to be enabled/disabled via an admin option? -- Ryan • (comments) • 16-Nov-2011 07:30 PST
I definitely think Export All should be admin-only, so maybe a warning about the performance hit on the web page would be sufficient. Advanced developers with API access could still use whatever strategy they wanted to mitigate this hit (e.g. scheduling an export for midnight when there's low activity, running from the command line, chunking the export into files of X topics at a time, etc). -- BU 28-Nov-2011 05:57 PST

Security issues / restirctions[edit]

HI Rian,

We had a attact at our site, so I need to do a lot of restriction for our site, but I can't do a lot of thinks by administrator user. So it would be nice if we can do the following:

  1. SimpleCaptcha/JCaptcha can be used instead of Google Recaptca, or it can be an option.
  2. Deleting user by admin user
  3. Hiding registaration page by admin user on demand
  4. Is it possible sendig e-mail after registration to a given e-mail address by user to finish the registration at the moment? Somehow by configuration?

Csaba Tenkes 25-Nov-2011 09:56 PST

There are a few things to consider with the above, so any additional thoughts would be appreciated:
  1. ReCAPTCHA was initially chosen because it seemed to be the most flexible. I can definitely look into making some sort of interface so that people can essentially code their own wrapper onto any CAPTCHA system out there - would that suffice? I'm not sure I would personally have time to create implementations with multiple CAPTCHA systems, but having a flexible interface would hopefully allow others to do so.
The problem is that, We can't use reCapcha beacuse our ISP can't allow to open ports to Google. We can use only captcha without other ports open.
  1. This could be problematic - if a user is deleted then all contributions that user made would also need to be deleted, which would have a cascading effect through the system. It is possible with JAMWiki 1.1 and later to block a problem user infinitely, so could you describe the use-case for additionally deleting that user?
My usecase will be the following: User who has not done any modification on the pages or have modified only his/ her own user page can be deleted by adminstrator, if admin wants it.
  1. Hiding the registration page has been requested before, and I can make this a higher priority. The suggestion made in the past was to create a "ROLE_REGISTER" that could be assigned or unassigned from the anonymous user group, essentially preventing them from accessing the registration page. Would that be sufficient for your use case?
Yes, It would be great and enought for us :)
  1. There have been requests for email integration since JAMWiki 0.0.1 and I simply haven't gotten around to it. I'll revisit this, but it's a feature I've been somewhat hesitant to implement since there are all sorts of avenues for abuse by email spammers, and I'm concerned about releasing a new JAMWiki version and then having to spend a significant amount of time fixing holes that spammers found. If you or anyone else can come up with a list of use-cases that would need to be handled (example: don't allow sending of more than three emails to a single address within a 24 hour period, don't allow sending of more than three emails initiated from a single IP address in a 24 hour period, etc) it would help out greatly.
Also, any additional details you have about the attack on your site might be interesting - I've seen a nightly bot that appears to have defeated reCAPTCHA that hits jamwiki.org, but the impact has been fairly low. From the jamwiki.org logs it appears that reCAPTCHA is thwarting a significant number of bot registration attempts, so it seems to have at least temporarily stemmed the tide of spam here. -- Ryan • (comments) • 26-Nov-2011 10:06 PST

Attack was:

  1. First it just registered 3-4 fake users / day to our site, and added fake advertisments to the user's page.
  2. Than robot have started to delete last revision of pages. 3-4 pages/ day.
Now this is not a problem: We can get back the last before revision by admin user manually and we can restrict the editing to the logged in users.

Csaba Tenkes 28-Nov-2011 06:50 PST

revision 3847 adds a new ROLE_REGISTER. This functionality will be included in JAMWiki 1.2. See also JAMWIKI-5. -- Ryan • (comments) • 28-Nov-2011 19:06 PST

Page Hit Counter[edit]

We use a wiki to provide easily accessible information to our general users. It would be really useful to know what the hit rate is on quite a few pages. Is there any way to add a hit counter to the wiki pages?

This probably wouldn't work as a default feature since it would require a database write on every page view and thus would have performance implications, but it would be easy enough for someone to add as a extension tag that could then be included in the footer (or elsewhere on the page). The core engine would probably also need to be modified to allow a configuration where certain page elements were not cached. -- Ryan • (comments) • 21-Jun-2012 07:20 PDT

Automated Uploads[edit]

What would be the best way to go about automated uploading of files? This is our scenario: we have a git repo that we want to perform some transformations and preprocessing on, zip it, and then upload to JAMWiki. Currently we are doing the uploading step manually. Is there any way to upload a file in an automated fashion? —The preceding comment was added by 50.58.217.226 (commentscontribs) .

There is no out-of-the-box support for such functionality, but when I've had to do similar things I've just written scripts that do it for me. If you look at the source of the Special:Upload page it should be possible to construct a script that populates the required fields and posts them automatically. Future support for something similar to the Mediawiki API may be possible, but given my lack of time to devote to JAMWiki development that type of feature won't be arriving anytime soon. -- Ryan • (comments) • 15:31, 29 July 2013 (PDT)


Integration with 3rd party statistics sites[edit]

It will be nice if JamWiki can be integrated with Google Analystics to be able to see the visit statistics of the wiki. It is not to hard, at the end or beginning of all page must be inserted a javascript fragment to point the Google Analytics with a registered id.

The id must be configured on the settings of Wiki.

Csaba Tenkes 06:07, 12 November 2013 (PST)

If development starts again then I would like to add the ability to include custom JS using something like mw:Manual:Interface/JavaScript, but at the moment development is mostly at a halt. If that feature was added then it would be easy to add any custom JS at all. -- Ryan • (comments) • 20:30, 12 November 2013 (PST)

Capcha[edit]

It would be nice if we can use built in captcha insted of Google Recapcha. In some server environment google recapcha port are not allowed.

It would probably not be difficult to refactor the captcha implementation to more easily allow alternate libraries, but as noted above, development is currently stalled. Patches would be welcome, and I would be happy to help out with suggestions and code reviews. -- Ryan • (comments) • 20:30, 12 November 2013 (PST)

Csaba Tenkes 06:07, 12 November 2013 (PST)

Username[edit]

Build a Magic Word to get the currentuser which is logged in to be able to create pages or includes based on the current username like a Template:Template:CURRENTUSER_Menu which could be included in the JAMWiki:Header, so each user could create templates or menus as the current user is not available through a magic word yet.