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.

Comments:JAMWiki 0.5.1

Contents

JAMWiki 0.5.1[edit]

Archived from the Feedback page:

JAMWiki 0.5.1 beta 1[edit]

I've been putting it off for a while, but here's the first beta for JAMWiki 0.5.1:

I was planning on introducing some changes to the data model with this release, but work is keeping me busy enough that I think they'll have to wait for 0.5.2. As a result the final 0.5.1 release should be able to go out sooner - I'm thinking 1-2 more weeks - but it won't contain many new features. Notable changes since 0.5.0:

  • Updated Chinese & Danish translations.
  • Fix for the bug that prevented logos from appearing on sub-pages (such as Feedback/Archives).
  • Simplified the page loading architecture. This should make it easier to add custom Special: pages.
  • Fixed image resizing bug.
  • Fixed the webAppRootKey bug for multiple installations on the same app server (from User:Swift).
  • RSS updates (from User:Swift).
  • Upgrade to Spring 2.0.2.
  • Basic spam filter (more work to do - see /WEB-INF/classes/spam-blacklist.txt).
  • Fix BEA install issue.

The latest code is now on jamwiki.org. Please let me know if you have any comments or feedback. -- Ryan 18-Jan-2007 23:11 PST

JAMWiki 0.5.1 beta 2[edit]

Here's the second and possibly final beta for JAMWiki 0.5.1:

There are still a lot of unfixed bugs and to-do items, but there are some good fixes in the new code, and also the new spam filter, so doing a release soon seems like a good idea. Barring surprises it will probably go out this weekend, so if anyone has translations or simple fixes/cleanups please submit them soon.

Changes since the last beta include:

  • Updated Chinese translations from User:hfl.
  • Spam filter updates.
  • Several cleanups (unused code deleted, better use of utility methods).
  • Fix for the ANT javadoc task.

As always, please let me know if any problems are encountered. -- Ryan 25-Jan-2007 21:59 PST

Filtering[edit]

Archived from the Feedback page:

I'd like to add a profanity filter. Is the JAMWikiFilter class suitable for extending for this purpose? I think it may be in the wrong place in the chain. I would want my filter to run on the viewing of a page, after the parser has completed. -- scroco 24-Aug-2006 12:20 PDT

A spam filter is on the long-term roadmap, and I imagine the functionality for a profanity filter would be very similar. The longer term plan is that such things would be implemented as plugins, but I'm fairly ignorant about the best way to implement plugins, so for now we could implement such things ad-hoc and then update them later on. For the spam filter I thought that it would be best implemented in JAMWikiParser.parsePreSave(), passing a flag to the ParserOutput that could then be acted on by the EditServlet. I'm not sure if your profanity filter could be handled similarly - if you have a need to run it at view time, the JAMWikiServlet.viewTopic() method might be the best place for it. JAMWikiFilter primarily just filters incoming requests, so while that would be a good place to see if an IP address is blocked, it might not be the easiest place to examine topic content.
As a side note, EditServlet and the parser classes are getting fairly complex, so I was hoping to clean them up a bit during the next few releases. Apologies for making anyone look at that code! -- Ryan 24-Aug-2006 12:39 PDT
Update: JAMWiki got its first spam today (I deleted it at the database level, for lack of a better way to handle it), so rather than wait until multiple spambots show up I'd like to start work on a spam blacklist for JAMWiki 0.5.1. I'm envisioning something similar to Wikitravel:Wikitravel:Local spam blacklist, where there is a user-editable blacklist of regular expressions that are matched against whenever someone attempts to save an article. I'll start a "Tech:" topic for this shortly, but wanted to at least give an update that this feature has moved up the to-do list. -- Ryan 10-Jan-2007 22:59 PST
Spams #2 and #3 arrived today. See Tech:Spam Filter for a discussion of blocking. -- Ryan 13-Jan-2007 00:38 PST

How to create a new Special: page?[edit]

Archived from the Feedback page:

How can I create a basic new Special: page?

For example if I have existing content in a static HTML page, what steps are required to convert it into a Special:StaticHTML page:

  • setup of XML files?
  • creating a corresponding JSP page? --Axel Kramer 14-Dec-2006 05:39 PST
The process will hopefully be simplified in the future, but for now:
  1. Modify the /WEB-INF/jamwiki-servlet.xml file to add a mapping and a servlet handler. The mapping is the URL pattern (such as <prop key="/**/Special:MyPage">MyHandler</prop>) and the handler links the mapping with a servlet (such as <bean id="MyHandler" class="org.jamwiki.servlets.MyServlet" />).
  2. Make sure JAMWiki recognizes your page as an existing special page by adding the URL pattern to /WEB-INF/classes/pseudotopics.properties (for JAMWiki versions prior to 0.5.0) or by adding a pseudotopic entry to /WEB-INF/classes/jamwiki-configuration.xml (for JAMWiki 0.5.0 or later).
  3. Create the servlet that you specified in the jamwiki-servlet.xml file ("org.jamwiki.servlets.MyServlet"). The servlet should extend JAMWikiServlet.
  4. Add an action for the servlet to org.jamwiki.servlets.WikiPageInfo. (I'd like to eventually get rid of this step). No longer necessary for JAMWiki 0.5.1.
  5. Create a JSP for your page display. New for JAMWiki 0.5.1: make sure that the servlet you created in step #3 calls the WikiPageInfo.setContentJsp() method to set this new JSP as the JSP for use in displaying the Special: page output.
  6. Process the action for your servlet and display the page by modifying wiki.jsp appropriately. (Hopefully this step could eventually go away as well). No longer necessary for JAMWiki 0.5.1.
Long and convoluted, but in the future it may be possible for the servlets to define their JSP page, which would get rid of the need for actions or for modifications to wiki.jsp. Let me know if anything isn't clear, if you have suggestions, questions, etc. -- Ryan 14-Dec-2006 08:10 PST
Thanks for your help. I will start a new document Tech:Integrate a GWT module in a Special page. --Axel Kramer 15-Dec-2006 12:30 PST
I've just checked in code that simplifies this process a little bit, and also makes it possible to add a new "Special:" page without modifying or re-compiling any JAMWiki code. My hope is that the new process will make it easier for people to create "plugin" special pages since they can now do so by writing their own servlet & JSP and then modifying two configuration files. Let me know if you (or anyone else) have any comments. -- Ryan 07-Jan-2007 00:58 PST

webAppRootKey[edit]

Archived from the Feedback page:

I recently upgraded from v0.4.0 to v0.5.0 and redeployed 2 different (context root) JAMWiki applications and all seemed to work good until I decided to restart the webcontainer (Geronimo 1.1.1) and noticed that one of the JAMWiki applications did not start up.
Checking the log I found:

18:37:55,902 ERROR [[/xdtwiki]] Exception sending context initialized event to listener
instance of class org.springframework.web.util.WebAppRootListener
java.lang.IllegalStateException: Web app root system property already set to different value:
'jamwiki.root' =
/usr/local/geronimo/repository/default/pmbwiki/1168023492490/pmbwiki-1168023492490.war/] instead of
[/usr/local/geronimo/repository/default/xdtwiki/1168083871958/xdtwiki-1168083871958.war/] -
Choose unique values for the 'webAppRootKey' context-param in your web.xml files!

I havent seen this issue before so I guess its something introduced in version 0.5.0?

I "resolved" this issue by editing the web.xml file in one of my apps (haven't needed edit it in prev. upgrades). and after some additional mess up on restart (I weren't thinking) due to the fact that I forgot to manually edit the version setting in jamwiki.properties to avoid a new upgrade process (as it already was done) ending up in a unsuccessful upgrade with one of the mysql datababase table being wiped out (jam_watchlist), a bit surprisingly.
I found out my mistake, scripted and added the missing table and got back up online again.
Is this a Geronimo specific issue or is clashing webAppRootKey reproducible on other platforms?

I also ran into the webAppRootKey issue shortly after releasing 0.5.0 - I suspect that the problem is related to the new Acegi Security code, and I'll investigate to see if there's a workaround (other than editing web.xml). If anyone has suggestions I'd be glad to hear 'em. -- Ryan 07-Jan-2007 11:48 PST
I introduced webAppRootKey, but it seems not to be needed by for Acegi Security. I think it's only needed for Log4j integration which is not supported anymore. I'll remove it from SNV.
Just being curious: why do you deploy 2 different JAMWiki applications? Isn't that what virtual wikis are meant for? -- Rainer 09-Jan-2007 05:45 PST
In most cases virtual wikis should suffice, but my reason for running two instances is that I use one for local development, and the other is used for keeping track of notes and other items. Since the development version can break often, may corrupt the database, etc, I prefer to keep two instances running. Thanks for fixing this! -- Ryan 09-Jan-2007 08:15 PST
The wikis Im running are on different domains (virtual hosts) and I like to have there databases separate as one wiki is my private and the other one is a community wiki for witch I upload a database dump into the community forum now and then.
You raced a good question though and I would like to know If it would have been possible to set it up as virtual wikis although they would be on different domains .....hmmm well thinking of it I guess it actually would be posible as the container doesn't care about the domain (virtual hosts). -- Peter 11-Jan-2007 09:04 PST

Code tag[edit]

Archived from the Feedback page:

Another rendering question: Text marked as code with <code> is displayed very small (at least in Firefox). I could not find a way to change this in css, is it possible? -- Rainer 10-Jan-2007 01:44 PST

Of course it works with css, e.g.
code { font-size: 1.4em; }

What do you think about including this in the standard css? -- Rainer 10-Jan-2007 01:53 PST

The size of text within <code> tags has bugged me for a while, but I wasn't sure what in the CSS was triggering it. Provided your fix doesn't have any adverse effects on IE then please feel free to check in a change, but hopefully in the long-term someone can figure out why exactly the extra CSS is needed! Thanks for pointing this out! -- Ryan 10-Jan-2007 22:43 PST
I've added a definition similiar to that for <pre>. It is slightly bigger to better match the surrounding text, but keeps the gray background (as in MediaWiki). -- Rainer 11-Jan-2007 02:44 PST

To-Do Lists[edit]

Copied from Current Development Status:

User:Wrh2[edit]

This list just captures stuff that I may work on during the next few release cycles. There is no guarantee that any of these items will actually get completed. Please note that anyone who wants to work on these items is welcome to do so, but as always please leave a note indicating what you're working on so that we don't duplicate effort.

  • Use Acegi LDAP support.
  • User blocking as described on Roadmap#User blocking.
  • Spam filter as described on Tech:Spam Filter. Update - implemented, but could use some refining.
  • Clean up & better utilize caching.
  • User and group permissions as described on Roadmap#User/Group permissions. This includes the ability to assign roles to users such as translator, admin, sysadmin.
  • Talk pages for anonymous users as described on Roadmap#Anonymous user talk pages.
  • Allow XML import with Mediawiki history (see Roadmap#XML Import/Export). Also consider import from other formats (configurable?).
  • Allow XML import with & without history in Mediawiki (or other) format.
  • Add support for the Mediawiki <gallery> tag.
  • Display warning when uploading an image and an image of the same name already exists.
  • Provide a way to delete image files.
  • Alphabetical index for pagination as described in #Allpages pagination.
  • Pagination will link to a page with no elements when total % offset = 0.
  • Create a page to view and edit a user's current watchlist, as is done with Mediawiki. Please take a look @ this feedback.
  • Add support for substitution such as {{subst:template}}.
  • Fix parameter substitution for named / unnamed per the spec. Update: from the code I suspect this may work, but I've not tested.
  • Potentially add support for the msgnw option (does anyone use this?).
  • Support for Mediawiki magic words. Update: as of JAMWiki 0.4.0 beta 8 a large number of the magic words are supported. Most likely full magic word support will come in a later release.
  • Template inclusion breaks section edit links (numbering off). Update: for now I've disabled section editing on pages that use template inclusion. This isn't a long-term solution, but thus far I haven't come up with a good way to handle this issue.
  • Provide translations for default topics as described in Roadmap#Translations_for_Default_Topics.
  • DB2 database support. Update: code added, just need someone to verify that it's solid.
  • When two headings have the same name the TOC always links to the first one.
  • Bug Reports#Character problem
  • "Link to" for redirects does not show final link destination. Update: this functionality isn't hard to add but has performance implications.
  • Add a "User contributions" link from user pages.
  • Address case sensitivity issues for topic names and user names. Update: constraint added to the database to ensure user logins are unique in a case-insensitive way.
  • Allow the parser to be used independently per Roadmap#Non-embedded parser.
  • Fix issue with Non-English file names and Tomcat 4.1.
  • Translated category namespace may cause failure when adding/removing categories - see #Categories.
  • Fix login in UpgradeServlet to work with LDAP/Acegi.
  • See issues in Tech:Acegi integration.
  • Unabalanced HTML tags (such as </div> or </td>) can wreak havoc on page layout - JAMWiki needs to do some accounting to make sure tags are properly balanced.
  • Image resizing seems to be broken - large images are simply resized using width and height tags in the HTML. Fixed in Subversion, will be included in the first beta for 0.5.1.
  • Logo image does not display with subpages such as Feedback/Archives. Fixed, will be included in the first 0.5.1 beta.
  • Parser does not close HTML tags, which can break page layout.
  • Create Special:Alltemplates page.
  • Allow wiki syntax in edit comments.
  • Wiki links ending in "?" not parsed as links - Sandbox
  • Simplify the process for adding a new "Special" page - it should be possible to do so by updating jamwiki-servlet.xml, jamwiki-configuration.xml, and adding a new class that extends JAMWikiServlet. Code committed so that adding a new Special: page can be done without updating core JAMWiki code. Will be included in the first 0.5.1 beta.
  • Look for ways to move some configuration files into PROP_BASE_FILE_DIR including to make upgrades less problematic since no files in /WEB-INF/classes would be overwritten.
  • ; Definition 1: colon is on ''same'' line should render as a definition list.
  • Investigate Tech:Parser integration.
  • Oracle 9 issue - see Feedback#Setting up pages
  • Bug Reports#Includeonly in templates
  • Bug Reports#noinclude in other pages
  • Audit f:param usage to avoid possible XSS. Spam filter message on edit.jsp is currently vulnerable. WikiMessage used instead.
  • Bug Reports#Deleted pages in search results.
  • TopicsAdminServlet and topics-admin.jsp can be handled with ItemsServlet and items.jsp.