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.

Tech:Virtual Wiki Enhancements

ktip.png This page (and all pages in the Tech: namespace) is a developer discussion about a feature that is either proposed for inclusion in JAMWiki or one that has already been implemented. This page is NOT documentation of JAMWiki functionality - for a list of documentation, see Category:JAMWiki.
Status of this feature: PARTIALLY IMPLEMENTED. Many of the features requested below were included in JAMWiki 1.0.
Contents

Description[edit]

This is a discussion for the scope and features of virtual wikis.

Current Features[edit]

  • add wiki
  • change wiki start page

Requested Features[edit]

  • remove a wiki
  • not modifying the web.xml file when adding a wiki
  • See Tech:JAMWiki 1.0.0 - different website titles per virtual wiki
  • rename an existing wiki without having to remove and create
  • rename the default en wiki revision 2981
  • user permissions per wiki or groups of pages

In addition, favico.ico support would be nice to have. This can be done via <link rel="shortcut icon" href="/somepath/myicon.ico" />. -- Ryan • (comments) • 28-Jul-2010 22:01 PDT

Simply add this line <link rel="shortcut icon" href="/images/favicon.ico" /> to '\WEB-INF\jsp\top.jsp' file. 27-Jun-2011 07:00 GMT (S.L.)

Possible solutions[edit]

  • remove virtual wikis - install a separate JAMWiki instance for each one
    • wastes resources
    • requires multiple logins
  • namespace separation only (current) - pages are available at separate URLs but they are not treated as separate sites (titles, stylesheets, language, etc)
    • can't restrict user access per wiki
    • not truly different wikis
  • full separation - each wiki has it's own ACL and site like properties
    • may require significant recoding
    • most users only need one or two wikis

Status[edit]

Application[edit]

Note: this section is to elaborate the usefulness of the virtual wiki feature. Any discuss can be deleted easily or free free to move them to the comments section.

The first time when I see the virtual wiki concept, I said wow, what a nice feature, at least I can use it for different language. But with time, I feel that it is unnecessary, and I found that it does not do any good. Can someone elaborate this feature a little bit on the reason why it is a good and useful feature? I mean I hope to see a real example why it is needed. User:jackiszhp

A virtual wiki provides a way of sharing user accounts, administration, etc for logically separate wiki instances, and also provides for shared configuration, installation, database, etc. I've seen them used for different language versions of a site, within a business for different departments/teams, and on private sites for different site sections (example: documentation & development). I didn't realize that there wasn't a page about virtual wikis already on jamwiki.org, so I'll try to put one together in the coming days. -- Ryan • (comments) • 16-Aug-2010 15:36 PDT
My question is why do we need many wiki instances? I feel that we don't really need many wiki instances. It might be "fun" for techholic, but in a real application, I don't see the need. For a big org, I don't know since I don't have one. but for a cross language application, I really know what I need. At first, I thought it is a really needy idea, but with time, I found that virtual wiki doesn't satisfy my need. For example, I have a page named apple in English, I would like have a corresponding page for apple in Chinese mandarin, and I hope when English speaking user accesses the page, it will be English, and when Chinese speaking user accesses the page, it will be Chinese mandarin. It seems that I will have to work on this pretty much to connect the gap.
For big org, I would say if we have a mechanism of access control for every single page like xwiki, then all issues are resolved, there is really no need to virtual wiki for real people except techholic.
As for the documentation & development, I would say that there is no need to have 2 wiki instances either, the Category tag solve the problem easily. User:jackiszhp
For your use-case a single wiki instance may be fine. At my last job the company wanted one wiki instance for the web team and another for the team that worked on internal applications. They wanted to manage the two instances together, but they didn't want the content to overlap. Using a single instance would have meant that searches would return results for both teams, each team would share the main page, etc. Having two separate virtual wikis worked nicely for them. It might have been possible to achieve some of what they wanted solely through access control, but the virtual wiki concept makes it very simple to keep content distinct without the need to do much site management.
In your example of the two apple pages, it sounds like a single wiki instance is the best option - something like this page, with translations available via links at the top of the page, would be sufficient. However, if wikitravel.org was using JAMWiki then the different language versions of the Wikitravel site would be a great use-case for multiple virtual wiki instances - the Chinese version would get its own home page, its own search, its own Special:RecentChanges, etc, while English, Spanish, French, etc would each have their own distinct implementations as well. -- Ryan • (comments) • 18-Aug-2010 21:20 PDT
The virtual wiki is very different from internalization (i18n). Each virtual wiki may have multiple localized versions and different pages could have different set of localized versions. I implemented in one of my project the JSP which included licalizing links depend on run-time existing localized version of each page. I18n of the wiki is a separate feature from vitual wiki. -- CAB • 29-Nov-2011

Comments[edit]

To add some background: virtual wikis are a feature carried over from the original Very Quick Wiki fork. While many of the features of Very Quick Wiki were stripped out, virtual wikis seemed quite useful (although I don't personally use them, they have proven to be very popular). The idea behind a virtual wiki is that often a user wants two separate wikis (for example, for two separate languages) but wants to share the infrastructure (logins, etc) for those wikis. As a result virtual wikis share logins, permissions, etc, but otherwise behave as two distinct installs. There is a great deal of room for discussion about how much granularity there should be for virtual wikis (which this page handles well), but I'm not sure that there would be an advantage (for example) to having virtual wikis that don't share user logins since a site admin could simply create two separate wiki instances to achieve the same result. Thus any discussion of enhancements to virtual wiki functionality should probably focus on slightly modifications to the existing implementation by allowing renaming, removal, etc, of virtual wikis (the second option above) rather than trying to create an implementation that could be more easily achieved with two separate wiki instances.

I think that's the goal of this proposal, but I just wanted to clarify since there is some language about making radical changes that might simply offer functionality that could be achieved using separate wiki instances. -- Ryan 02-Jan-2009 15:43 PST

Having had a bit more time to look at the proposals here, I like the following:

  • remove a wiki
  • not modifying the web.xml file when adding a wiki
  • different website titles per virtual wiki
  • rename an existing wiki without having to remove and create
  • rename the default en wiki

However, this suggestion might be problematic and would be more difficult to implement:

  • user permissions per wiki or groups of pages

Enhancements to virtual wikis haven't been a high priority for me in the past, but if there is enough interest then it would probably not be terribly difficult to implement the suggestions you've outlined. In particular, I've always thought it was kludgy to have to modify web.xml after creating a virtual wiki, so that's something that would be high on my list of cleanups. -- Ryan 03-Jan-2009 11:55 PST

I think the current system with modifications to allow for virtual wikis to have their own features listed below would be ideal for the administrators looking for this. I personally will likely not use virtual wikis if there was another way to segment pages between users. Currently virtual wikis are the only way I can do this. I believe there would be a great benefit to what is discussed here Tech:User_Permissions. My personal preference would be access permissions based on URL and a Virtual Wiki is automatically taken care because it's a special case of that.

  • meta tags
    • title
    • keywords
    • description
    • langauge
  • style sheet
  • configuration options
    • general settings (includes Starting Page)
    • parser settings
    • file upload settings (so that directory can be secured by permissions)
    • possibly rss settings

For simplicity with meta tags you could let an administrator type in raw html in a text area which overrides the default tag block in the page head.

I want to place my vote for this(these) feature(s). I'm especially interested in <title>, css, and logo features per virtual wiki. The "punch list" above covers most of this "vote." --Tim • (comments) 19-Jul-2010 18:17 PDT
CSS should already be handled on a per-virtualwiki basis using each virtual wiki's StyleSheet topic, but providing per-virtual wiki logos is definitely something that needs implementing. If you're interested in writing code I could step you through what would need to be done, otherwise please check in every couple of weeks to remind me to implement this - I won't get to it today, but it's easy to do and if I know someone is interested then I'll definitely get it done for JAMWiki 1.0.0. I assume that the other fields that are being requested are the "Site Name" and "HTML Meta Description" from Special:Admin? I think that providing capability for customization for all of those would make sense. -- Ryan • (comments) • 19-Jul-2010 19:25 PDT
I could be talked into looking at and contributing code, though my free time is sometimes spoken for another OSS project, blojsom. --Tim • (comments) 26-Jul-2010 11:55 PDT
If you find yourself with loads of time and feel an undeniable urge to jump into some JAMWiki programming please let me know :). Until then, I'll keep this on my todo list, and if time is available when I get to it I may write it up as a step-by-step tutorial for developers since this site is sadly thin on detailed programming documentation. -- Ryan • (comments) • 27-Jul-2010 08:53 PDT

Update 28-March-2010[edit]

JAMWiki 0.9.0 will include a new Special:VirtualWiki admin page that will allow some additional flexibility for virtual wikis including the following:

  • The default virtual wiki can now be changed from "en" (revision 2981).
  • Namespaces can be translated on a per-virtual wiki basis.

Deletion and renaming of virtual wikis is still not allowed, and adding a new virtual wiki still requires an update to web.xml, but hopefully this will help out individuals who are making use of this feature. -- Ryan • (comments) • 28-Mar-2010 20:53 PDT

Patch for adding a virtual wiki without web.xml modification[edit]

Swaroop Reddy provided a patch for adding virtual wikis without the need to modify web.xml. This approach requires that all virtual wikis be located under a "/wikis" directory in the web app and is thus (unfortunately) not backwards compatible with existing JAMWiki installations. As a result it probably cannot be implemented by default on the JAMWiki trunk, but for anyone interested the code is available as a diff at Image:virtual-wiki-diff.out. -- Ryan • (comments) • 01-Jun-2009 07:58 PDT

Update 07-September-2010[edit]

Code has been committed in revision 3199, revision 3200 and revision 3201 to support virtual wiki-specific logos, site name and meta description. -- Ryan • (comments) • 07-Sep-2010 13:11 PDT