Bug Reports/Resolved/0.8.x

This page is an archive of Bug Reports resolved during the JAMWiki 0.8.x release cycle. See Bug Reports/Resolved for an index of all resolved bug reports.

[Edit]Do not allow renaming of images or categories

Per http://en.wikipedia.org/wiki/Help:Moving_a_page, Mediawiki does not allow renaming of images or categories. Renaming a category on JAMWiki works provided the category is still in the correct namespace, so there might be some wiggle room here. Note that renaming a category to an article namespace breaks badly. -- Ryan • (comments) • 06-May-2009 16:01 PDT

revision 2620 prevents moving images or categories into or out of the image/category namespace. -- Ryan • (comments) • 28-Jun-2009 16:48 PDT

[Edit]History for redirects

If a page is currently a redirect then it is not possible to view its history. See http://jamwiki.org/wiki/en/Special:History?topicVersionId=12286&topic=Test. -- Ryan • (comments) • 29-Jun-2009 08:22 PDT

revision 2623 should resolve this issue. -- Ryan • (comments) • 03-Jul-2009 23:09 PDT

[Edit]Signatures in templates not processed correctly

When a signature (~~~~) is used as content in a template ({{alert | ~~~~ }}) the signature is not parsed when the content is saved, meaning that every user who then views the page containing that template sees their own signature. -- Ryan • (comments) • 26-Aug-2009 10:31 PDT

revision 2683 fixes this issue. -- Ryan • (comments) • 29-Aug-2009 13:26 PDT

[Edit]Signatures in templates

Moved from the Feedback page:

Anybody here to tell me how to add user signatures to templates? ~~~~ expands immediately, fiddling around with <includeonly> doesn't yield a satisfying result, it doesn't became clearer after reading Mediawiki doc. Thanx! -- fmr 20-Apr-2007 03:13 PDT

Are signatures in templates something that Mediawiki supports? At present using tildes as a signature is something that is immediately converted when a topic is saved, so there would not be any way to have anything other than the content of the signature (ie "Ryan 20-Apr-2007 09:06 PDT") appear in a template. -- Ryan 20-Apr-2007 09:06 PDT
There's a lot of tech doc about substitution, telling me The code ~<includeonly>~</includeonly>~~ will be displayed as ~~~ when the template is not included, ~~~~ when the template is included, but it will only be expanded as the active user when the template is subst'd, which is to say when it has been joined within the same block once again. Well, but what's the meaning of this? -- fmr 24-Apr-2007 03:57 PDT
At the moment signatures in JAMWiki templates probably won't work due to the way the parser processes text. It may be possible to address this issue in a future release, although issues like this one make me wish that Mediawiki was a bit more consistent with their syntax and processing rules... -- Ryan 06-May-2007 21:43 PDT
This issue was resolved for 0.8.0 with revision 2683. -- Ryan • (comments) • 30-Aug-2009 18:45 PDT

[Edit]Image recognition

I use tomcat.

I had the following problem with images : when I did upload images (png, gif, etc.) it wasn't recognized as an image. So I wasn't able to emmbed pictures in my pages. I finally decided to take a look at the code.

JamWiki uses the JDK to detect if an upload is an image => the class ImageUtil has a method public static boolean isImage(File file) which indirectly uses javax.imageio.ImageIO.

When ImageIO tries to load an image it uses a temporary directory which is given by the Cache Directory (see class ImageIO$ClassInfo).

Unfortunately, tomcat declares a temporary directory that does not exist by default (CATALINA_TMPDIR):

Using CATALINA_BASE:   /opt/tomcat
Using CATALINA_HOME:   /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JRE_HOME:       /usr/lib/j2sdk1.5-sun/

One of these solutions should be interesting :

  • to add a warning in the installation documentation to make people create this temporary directory
  • to set the ImageIO's Cache Directory and map it in the system directory of the wiki to prevent people from meeting this kind of failure (which is impossible to understand without taking a look at the code).
Thanks for the detailed report! Setting the cache directory with ImageIO.setCacheDirectory() will definitely be the way to go. I'm at work currently but will try to get a patch whipped up as soon as I get a chance. As an aside, what version of Linux / UNIX are you using where the default Tomcat install uses invalid directories? -- Ryan • (comments) • 13-Jul-2009 07:48 PDT
revision 2639 should address this problem, although I'm unable to reproduce it locally so any confirmation would be much appreciated. -- Ryan • (comments) • 14-Jul-2009 19:48 PDT

[Edit]Categories STATEMENT_SELECT_CATEGORIES

Using MSSQL as Backend, sort_key in jam_category is null if no entry contains [[Category:X|sortX]]. Executing STATEMENT_SELECT_CATEGORIES bring results in form:

category_name sort_key
Category:A NULL
Category:B SortkeyB
Category:B NULL
Category:C NULL

Special:Categories displays Category:B only once, so pagination doesn't work correctly. E.g. num=50&offset=0 displays 45 entries (while the statement returns 50).

How should the resultset look like (or how does it look on other database-systems)?

Thanks for help! --hp 25-May-2009 01:15 PDT

Thanks for the bug report. Based on Mediawiki's documentation it appears that the JAMWiki implementation of "sort key" is not entirely correct... currently the sort key is displayed on the category page with a link to the page in question. For example, if this page was in "Category:Test category" and had a "sort key" of "1st Test Page" then it should still appear on that category page with a title of "Bug Reports", but it would be sorted as if the title was "1st Test Page"; at present the title is "1st Test Page". Beyond that, if there is an additional bug that is specific to MS SQL let me know and I can investigate. -- Ryan • (comments) • 25-May-2009 16:39 PDT
You're right, JAMWiki implementation of "sort key" is a little different from Mediawiki's one. Apart from these difference, I think I have an additional bug in statement STATEMENT_SELECT_CATEGORIES for MSSQL. Perhaps STATEMENT_SELECT_CATEGORIES should ignore the sort_key, so each category is listed only once... --hp 01-Jun-2009 23:32 PDT
revision 2618 makes the sort key implementation work like Mediawiki. revision 2619 fixes an additional bug where magic words in the sort key weren't getting parsed, so something like [[Category:Test|{{PAGENAME}}]] wouldn't work. -- Ryan • (comments) • 23-Jun-2009 21:26 PDT

[Edit]Database: Custom login fails on DB constraint

I am using Jamwiki 0.7.1 and I implemented a custom authenticator as Spring UserDetailsService. Jamwiki however dies with error:

javax.servlet.ServletException: java.sql.SQLException: ORA-01400: cannot insert NULL into  ("JAMWIKI.JAM_USERS"."PASSWORD")

This is a failure with either logic in JamwikiPostAuthenticationFilter or in database schema, or just issue with Oracle backend (or issue with me :)). JAM_USERS has password field declared as not null. However, in filter there are the following lines that set the authenticated password as empty:

// default the password empty so that the user cannot login directly
String encryptedPassword = "";
WikiBase.getDataHandler().writeWikiUser(user, username, encryptedPassword);

This again fails in AnsiDataHandler on line 1682 where a new user is created with a empty password. This is an issue at least with Oracle, as it seems to consider an empty string \'\' as null.

I'm not sure which is the proper way to fix this. A crude one is to remove not null constraint and insert some magic number in ENABLED column to indicate external login only.

Analyzing this one requires more thought than I'm capable of on a Sunday morning, but if I haven't responded in more detail by the end of the day please bug me to do so. Thanks for the detailed report. -- Ryan • (comments) • 10-May-2009 09:34 PDT
Can you specify how you configured the custom authenticator? Did you update /WEB-INF/applicationContext-security.xml and modify the <authentication-provider> entry? Assuming another <authentication-provider> is specified then there shouldn't need to be a jam_users entry, although it's entirely possible there's a bug somewhere that your configuration might be triggering. -- Ryan • (comments) • 10-May-2009 21:09 PDT
I just replaced authentication-provider jamWikiAuthenticationDao with my own implementation (reads different schema). Instead of returning an WikiUser object it returns User object (from Spring Security). My code actually obsoleted itself as I (finally) figured out how to use existing JAAS implementation with Spring Security. --urpi 11-May-2009 05:25 PDT
Uh. Now let's make sure that I'm getting this right. With external authentication a jamwiki_users entry may be created by JAMWikiPostAuthenticationFilter to make attributions, preferences and such work. It checks the principal type of Authentication object. If external authentication is used then a new user record should be created (as it is said in the class comments)? Post authentication filter is checking the instace of authenticated principal. With WikiUserDetails no action is needed and with UserDetails a new wiki user entry is being created. With my own ad hoc implementation an object implementing UserDetails was returned. Therefore JAMWiki tried to create new jamwiki_user record. With JAAS authentication, Spring will not return an UserDetails object, but just a String "principal" with authenticated username. Authentication succeeds but you end up with username being 'null'. Well thats just cosmetic, but if I'm right, you cannot have 1:1 external authentication with jamwiki authentication? --urpi 11-May-2009 07:44 PDT
I'm not 100% sure I understand your implementation, but if the code is currently preventing use of a custom AuthenticationDao object then it's a bug / design flaw in the JAMWiki code. I've personally only tried integrating with LDAP and JAMWiki's default authentication mechanism, so if there is another use case that's failing I'd gladly accept a patch to fix it. -- Ryan • (comments) • 12-May-2009 21:36 PDT
My code is exactly similar to Jamwiki implementation. I'm just not sure how external authentication mechanisms should behave. It may be my fault or misunderstanding, but if I'm right, there's a bug. I'll post a fix as a suggestion when its ready. --urpi 13-May-2009 00:13 PDT

[Edit]jamwiki.properties outside of war

There's already been discussion about this subject, but there still seems to be no fix available. A simple fix is to read the location of jamwiki.properties from Java system properties (as set up with "-D" parameter on server startup). For eg., in class Environment.java replace line

private static final String PROPERTY_FILE_NAME = "jamwiki.properties";

with (for example):

private static final String PROPERTY_FILE_NAME =
        System.getProperty("jamwiki.property.file", "jamwiki.properties");

Now you can set it up when server starts and point to your location. This works at least as long as jamwiki is able to read something outside the war.

The only concern I would have with this approach would be making sure that out-of-the-box installs didn't require any additional configuration... so perhaps just checking to see if "jamwiki.property.file" was defined, and if so using it, would be sufficient. I'd happily accept a patch from anyone interested in implementing this, otherwise let's leave this report open for a while and I'll hopefully put something together for a future release. Thanks for the suggestion. -- Ryan • (comments) • 10-May-2009 09:29 PDT
System.getProperty("key", "def") already does this, if no value is defined, then the default value (as in the example, current "jamwiki.properties") is used. I also prepped a patch for this. I also wrote a method for setting up any property on runtime if there's system property "jamwiki.override.file.properties=true" defined. Properties from system properties are prefixed with "jamwiki." string. I just needed that for easier deployment with multiple servers, somebody might find it useful... or not :) There's also patch available - as I figure out how to commit them. --urpi 11-May-2009 05:38 PDT
How to Help#How to contribute has details about contributing patches. Basically I just need your Sourceforge ID in order to give you Subversion access, you can then create a branch and make your changes, and then let me know when they're ready and I'll do a quick review and merge to trunk if all is well. For a simple change like this one there shouldn't be any issues, although with bigger changes I like to make sure that either the code is something that is a cleanup or a commonly used feature, or that someone will be around to maintain the code - I'm generally hesitant to merge features that I wouldn't use if the original developer won't be around as I don't have a lot of time, and addressing bug reports for features I don't use is really time consuming. -- Ryan • (comments) • 12-May-2009 21:41 PDT
Ok, will do. My username in SF is 'urpit'. --urpi 13-May-2009 00:17 PDT
You should have access to Subversion now - let me know if there are any issues. Start out by creating a branch, and I'll try to review any commits. When code is ready to merge just let me know. Thanks for helping out! -- Ryan • (comments) • 13-May-2009 07:16 PDT
Made three commits in my branch, one for file location fix, one for dynamic properties and one proposal to authentication (still not sure about it, haven't had time to test it)
Thanks! I'll try to get these reviewed this weekend and queue them for either JAMWiki 0.7.2 or 0.8.0. -- Ryan • (comments) • 28-May-2009 09:09 PDT
All of your changes looked straightforward and non-intrusive, so they've all been merged to trunk in revision 2603 (I removed one logging statement, but otherwise made no changes). Let me know what name to credit you with in the CREDITS file, and thanks for contributing! -- Ryan • (comments) • 31-May-2009 19:00 PDT

[Edit]Lockout after changing DB password

Move from FAQ:

We've been running Jam Wiki for several months now and our Oracle database password just changed. How can we update the password at this point? I tried WEB-INF/classes/jamwiki.properties, but that does not seem to help.

Since this probably isn't a frequently asked question I'll move it to Feedback shortly, but to answer - you can update the database password from Special:Admin#database. All passwords are encrypted in jamwiki.properties, so updating the properties file directly won't work. Note that after the password is updated you will probably need to restart your app server so that the connection pool can reload. -- Ryan 23-Oct-2008 10:53 PDT

Thanks, Ryan, but my Oracle account gets immediatelly locked once I go to this page.

OK, I'll log this as a bug report then and do some investigation. Sorry for the trouble... -- Ryan 29-Oct-2008 15:47 PDT
I also had a similar problem when moving to new platform. The problem is if the database password is encrypted, there is no way to change it after the password has been changed. You can't get to Special:Admin#database because you are locked out of the wiki due to the access denied to database. As far as I could see the only way to get around this was to change the database password back to the old password - so jamwiki has access again to the database and we can actually get into the wiki - then go to Special:Admin#database and change the database password to the new one, then go back to the db and change the password again to the new one.
For simply changing databases I believe that the migration tool on the Special:Maintenance page should handle changing passwords. For changing the database password, there is a feature in WebSphere that might be something JAMWiki could copy - when using WebSphere, you can enter an unencrypted password in a property file, and as soon as it is read the first time it will be re-saved as an encrypted value. That might be a possible solution to this issue. I've got a few things queued to finish first, but I may be able to get to this in the next two days. If not then I'll be gone for a week with no internet access, but after that please add (gentle) reminders to this bug report so I don't forget. Thanks for the follow-up. -- Ryan • (comments) • 12-Mar-2009 05:46 PDT
revision 2534 should resolve this issue, although it needs more testing. If JAMWiki encounters an un-encrypted value in the properties file it will read it, encrypt it, and re-save the properties file. That should allow users to manually enter password values without fear of having passwords stored in plain text in a properties file. -- Ryan • (comments) • 14-Mar-2009 07:38 PDT

[Edit]Database setup error (Beta 0.8)

* JAMWiki 0.8.0
* Postgresql 8.3.0
* JDBC postgresql-8.3-604.jdbc4.jar (also tried jdbc3 version)

I tried to install the JAMWiki beta 0.8.0 version, using a Postgresql database, which produced immediately after pressing the 'Save changes' button the following message:

 An unknown system error has occurred. The error message is: org.postgresql.util.PSQLException: Returning autogenerated keys is not supported..


Installing the JAMWiki version 0.7.2 works perfectly fine.

Hope anyone can help, I'm stuck here...

Regards.

Hi, you'll need to get the latest Postgres JDBC drivers which support JDBC 3.0 features - see JAMWiki 0.8.0#Release Notes for more details. -- Ryan • (comments) • 07-Oct-2009 08:08 PDT

[Edit]Topic names starting with "/"

It is possible to create a topic name that starts with "/" that can then never be viewed or deleted. Topics starting with "/" should be considered invalid topic names and generate errors before they are created. -- Ryan • (comments) • 27-Oct-2009 21:13 PDT

revision 2747 resolves this issue. -- Ryan • (comments) • 27-Oct-2009 21:30 PDT

[Edit]Category Preview

When editing the content of a category with the latest trunk code (0.8.0 beta 3), the "Preview" functionality shows the text below the list of categories, while the actual category view shows it above the list of categories. -- Ryan • (comments) • 30-Oct-2009 13:46 PDT

revision 2748 resolves this issue. -- Ryan • (comments) • 30-Oct-2009 17:53 PDT

[Edit]Templates not appearing in AllPages

Templates do not appear in the "All Pages" list... but I'm not sure whether MW does this, so maybe it just needs an "All Templates" special page? -- Floating World 27-Oct-2009 07:54 PDT

I'm seeing templates in the All Pages list - see http://jamwiki.org/wiki/en/Special:Allpages?num=500&offset=0, starting around 250. Are they missing from your wiki? It's entirely possible there's a bug somewhere, I just need to figure out how to reproduce it. -- Ryan • (comments) • 27-Oct-2009 21:08 PDT
Yes, they are missing. I've created several templates but even though there are only a handful of pages in my wiki, the templates aren't showing up there. In case it helps to reproduce, I chose the "Internal Database" option during setup. --Floating World 31-Oct-2009 12:42 PDT

Confirmed as still present in the GA release of 0.8.0. --Floating World 12-Dec-2009 12:48 PST

Thanks for the confirmation. You may have already provided this information, but what database are you using? This will be an easy issue to fix if I can figure out how to reproduce it, but at this point I haven't seen the problem on any of my JAMWiki installations. -- Ryan • (comments) • 13-Dec-2009 18:50 PST
I'm using the internal database. In case it makes any difference, I think that in both cases the very first page I created was a template rather than a normal topic. --Floating World 14-Dec-2009 12:52 PST
Found the problem, but I haven't had a chance to put a fix together. It will definitely get fixed for the upcoming JAMWiki 0.8.1. -- Ryan • (comments) • 21-Dec-2009 22:25 PST
revision 2804 should resolve this issue. It was a pretty obvious bug, but it looks like very old JAMWiki installs (such as jamwiki.org) may have data that doesn't trigger the problem, which is why I wasn't able to reproduce the issue. -- Ryan • (comments) • 22-Dec-2009 19:47 PST

[Edit]Links to Self

Links on a page to itself don't appear "properly" (in MW they're bolded and unlinked). -- Floating World 27-Oct-2009 07:54 PDT

revision 2766 resolves this issue. The fix will be included in the next release. -- Ryan • (comments) • 12-Nov-2009 20:07 PST

[Edit]Warnings while Upgrading v0.7.2 to v0.8.0

While performing upgrade from 0.7.2 to 0.8.0 two optional step failed.

System specifications are: apache-tomcat-6.0 and mysql-5.1 with Java5 on RHEL5.

Here is the Upgrade Successful page from JAMWiki.

 Upgrade successful: ScienceStudio
 Modified database column "group_id" in table "jam_group".
 Modified database column "id" in table "jam_group_members".
 Modified database column "topic_id" in table "jam_topic".
 Modified database column "topic_version_id" in table "jam_topic_version".
 Modified database column "virtual_wiki_id" in table "jam_virtual_wiki".
 Modified database column "file_id" in table "jam_file".
 Modified database column "file_version_id" in table "jam_file_version".
 Modified database column "wiki_user_id" in table "jam_wiki_us er".
 Added database table "jam_log".
 Added database column "wiki_user_display" to table "jam_topic_version".
 Dropped database column "wiki_user_ip_address" from table "jam_topic_version".
 Added database column "wiki_user_display" to table "jam_file_version".
 Dropped database column "wiki_user_ip_address" from table "jam_file_version".
 Added database column "version_params " to table "jam_topic_version".
 Dropped database table "jam_recent_change".
 Added database table "jam_recent_change".
 An optional step has failed while upgrading the system. The upgrade will continue and the
 system will function normally, but view the logs to determine what steps may have failed.
 Please see the /WEB-INF/UPGRADE.txt document for manual upgrade steps and report any errors in
 the logs at jamwiki.org. The error message is: You can't specify target table
 'jam_topic_version' for update in FROM clause
 Added new record(s) to table "jam_role".
 Added new record(s) to table "jam_authorities".
 An optional step has failed while upgrading the system. The upgrade will continue and the
 system will function normally, but view the logs to determine what steps may have failed.
 Please see the /WEB-INF/UPGRADE.txt document for manual upgrade steps and report any errors in
 the logs at jamwiki.org. The error message is: com.mysql.jdbc.MysqlDataTruncation: Data
 truncation: Truncated incorrect DOUBLE value: '|'
 Updated stylesheet for virtual wiki "en".


First warning from log:

 WARNING: Failure while updating edit_type value in jam_topic_version.  See UPGRADE.txt for instructions on how to manually complete this optional step.
 java.sql.SQLException: You can't specify target table 'jam_topic_version' for update in FROM clause
       at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
       at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
       at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3558)
       at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3490)
       at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
       at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2109)
       at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2648)
       at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2077)
       at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2362)
       at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2280)
       at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2265)
       at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:102)
       at org.jamwiki.db.AnsiQueryHandler.executeUpgradeUpdate(AnsiQueryHandler.java:406)
       at org.jamwiki.db.AnsiDataHandler.executeUpgradeUpdate(AnsiDataHandler.java:369)
       at org.jamwiki.db.DatabaseUpgrades.upgrade080(DatabaseUpgrades.java:340)
       at org.jamwiki.servlets.UpgradeServlet.upgradeDatabase(UpgradeServlet.java:210)
      ...etc...

Second warning from log:

 WARNING: Failure during upgrade while reloading log items.  Please use the Special:Maintenance page to complete this step.
 org.jamwiki.DataAccessException: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Truncated incorrect DOUBLE value: '|'
       at org.jamwiki.db.AnsiDataHandler.reloadLogItems(AnsiDataHandler.java:1428)
       at org.jamwiki.servlets.UpgradeServlet.upgrade(UpgradeServlet.java:115)
       at org.jamwiki.servlets.UpgradeServlet.handleJAMWikiRequest(UpgradeServlet.java:67)
       at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:242)
       at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
       at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
       at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
       at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
       at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
       at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
       at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:169)
       at org.springframework.security.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:99)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
       ...etc...
Thanks for the report - I'll try to investigate tonight to see where the SQL might be wrong. -- Ryan • (comments) • 08-Dec-2009 14:20 PST
Unfortunately I didn't get a chance to fix this tonight, but I'll make sure a fix is included in JAMWiki 0.8.1. In the mean time the problem SQL for the first error is: 
# this statement is ugly and inexact - anyone who can write an ANSI version that is cleaner
# or more accurate, please do so and submit it to jamwiki.org.
UPGRADE_080_UPDATE_TOPIC_VERSION_UPLOAD_EDIT_TYPE = \
    update jam_topic_version set edit_type = 9 \
    where jam_topic_version.topic_version_id in ( \
      select jam_topic_version.topic_version_id \
      from jam_topic_version, jam_file, jam_file_version \
      where jam_topic_version.topic_id = jam_file.topic_id \
      and jam_file.file_id = jam_file_version.file_id \
      and extract(year from jam_topic_version.edit_date) = extract(year from jam_file_version.upload_date) \
      and extract(month from jam_topic_version.edit_date) = extract(month from jam_file_version.upload_date) \
      and extract(day from jam_topic_version.edit_date) = extract(day from jam_file_version.upload_date) \
      and extract(hour from jam_topic_version.edit_date) = extract(hour from jam_file_version.upload_date) \
      and extract(minute from jam_topic_version.edit_date) = extract(minute from jam_file_version.upload_date) \
      and (abs(extract(second from jam_topic_version.edit_date) - extract(second from jam_file_version.upload_date)) < 3) \
    )
I'll need to track down exactly where it's failing in the second case. It appears that both instances are related to file uploads, so apparently I failed to include file records when I tested upgrades on MySQL - sorry about that, and thanks for the report. -- Ryan • (comments) • 08-Dec-2009 22:06 PST
revision 2786 fixes this issue for me locally - let me know your name if you would like to be credited in the CHANGELOG for JAMWiki 0.8.1. If anyone wants this fixed prior to JAMWiki 0.8.1 just update the /WEB-INF/classes/mysql.properties file using this version. -- Ryan • (comments) • 09-Dec-2009 20:41 PST

[Edit]Error Upgrading from 0.7.2 to 0.8.1 using MS-SQL

The Upgrade-Wizzard fails with the following Message:

Failure while updating edit_type value in jam_topic_version.  See UPGRADE.txt for instructions on how to manually complete this optional step.

I manually executed the following Statement on the database, which seems to work for me:

   update jam_topic_version set edit_type = 9 
   where jam_topic_version.topic_version_id in ( 
     select jam_topic_version.topic_version_id 
     from jam_topic_version, jam_file, jam_file_version 
     where jam_topic_version.topic_id = jam_file.topic_id 
     and jam_file.file_id = jam_file_version.file_id 
     and DATEDIFF(s, jam_topic_version.edit_date, jam_file_version.upload_date) < 3
   )

Have a nice day! --hp 05-Jan-2010 05:26 PST

[Edit]Errors in sql.mssql.properties 0.8.1

In sql.mssql.properties the statement STATEMENT_SELECT_TOPIC_HISTORY is missing an "+ ' " after CONVERT(VARCHAR, @TOPIC_ID). I think Line 366 should be 'WHERE jam_topic.topic_id = '+CONVERT(VARCHAR, @TOPIC_ID)+ ' ' \ instead.

Line 365    +       ') ' \
Line 366    +       'WHERE jam_topic.topic_id = '+CONVERT(VARCHAR, @TOPIC_ID) ' \
Line 367    +       'AND jam_topic.topic_id = jam_topic_version.topic_id ' \

After changeing this one, the Line 331 must be changed to a bigger varchar value, the statement exceeds the 300 (I simply turned it into varchar(3000)).

The created statement @SQL looks now like:

 select * from (
	select top 3 * from ( 
		select top 101 * from ( 
			SELECT jam_topic_version.topic_version_id, jam_topic.topic_id, jam_topic.topic_name, 
				jam_topic_version.edit_date as change_date, jam_topic_version.wiki_user_id, 
				coalesce(jam_wiki_user.login, jam_topic_version.wiki_user_display) as display_name, 
				jam_topic_version.edit_type, jam_virtual_wiki.virtual_wiki_id, 
				jam_virtual_wiki.virtual_wiki_name, jam_topic_version.edit_comment as change_comment, 
				jam_topic_version.previous_topic_version_id, jam_topic_version.characters_changed, 
				null as log_type, jam_topic_version.version_params as log_params 
			FROM jam_topic, jam_virtual_wiki, jam_topic_version 
			LEFT OUTER JOIN jam_wiki_user ON (jam_wiki_user.wiki_user_id = jam_topic_version.wiki_user_id) 
			WHERE jam_topic.topic_id = 4 AND jam_topic.topic_id = jam_topic_version.topic_id 
			AND jam_topic.virtual_wiki_id = jam_virtual_wiki.virtual_wiki_id AND jam_topic.delete_date is null 
			order by change_date desc 
		) as jam_recent_change 
	) a order by change_date) b 
 order by change_date desc

The last problem with it is the inner select, because it is ordered by change_date but doesn't selects 'TOP', so MS-SQL throws an error. Possible solutions are removing the "order by change_date desc" or changeing "SELECT jam_topic_version.topic_version_id..." to "SELECT TOP <put a number of maximum selected versions here> jam_topic_version.topic_version_id...". I removed line 370, now my history is displayed. --hp 05-Jan-2010 06:04 PST

Is "null as log_type" correct in STATEMENT_SELECT_TOPIC_HISTORY? Thank you! --hp 05-Jan-2010 06:09 PST
Thanks, I'll get these fixed ASAP. As an aside, I'm unable to install an evaluation version of MS-SQL (it requires the "professional" version of Windows) - do you happen to know if there is a lite version or anything similar that I can use for testing? I hate releasing updates with untested database code, but currently HSQL, Postgres, MySQL, and Oracle are the only databases that I'm able to test with. -- Ryan • (comments) • 05-Jan-2010 09:21 PST
As far as I know, there is no way around Windows Professional for MS-SQL, sorry... I'll try to move our Wiki-DBs to PostgreSQL (for other reasons), but I still should be able to test statements on MS-SQL in future, just send an email. --hanspeterklapf 06-Jan-2010 03:52 PST
revision 2831 adds your fixes (thanks!). The null as log_type line is there to solely for code-reuse purposes - the results get stored in a org.jamwiki.model.RecentChange object, and initialization of that object with a ResultSet expects a log_type field to be available. However, since log messages aren't displayed in topic history the field is simply initialized to null. These changes will be included in 0.8.2, although that release probably won't go out for another month or so. -- Ryan • (comments) • 06-Jan-2010 09:15 PST
Thanks a lot!! Because of the other errors I've found, I submitted a new sql.mssql.properties with my changes for Watchlist-Statement, Log_Items, Sort-Key, Topic_History and Upgrade_Edit_Type.
Two small changes not reported now: In STATEMENT_SELECT_WIKI_USER_CHANGES_ANONYMOUS and STATEMENT_SELECT_WIKI_USER_CHANGES_LOGIN there is the same bug as in STATEMENT_SELECT_WATCHLIST_CHANGES (change_date and length of @SQL). sql.mssql.properties now contains the newest version. --hp 10-Jan-2010 03:44 PST
Thanks! The MS SQL file is updated with your changes in revision 2834. -- Ryan • (comments) • 10-Jan-2010 21:20 PST

[Edit]jam_category.sort_key on MS-SQL again

Like reported for Version 0.7, there is still a small bug in STATEMENT_SELECT_CATEGORIES for mssql... The number of results breaks pagination, because the number of different categories (for display) doesn't match the number of the selected ones.

I simply changed the inner select from STATEMENT_SELECT_CATEGORIES in sql.mssql.properties to

 + 'select distinct top '+CONVERT(VARCHAR, @OFFSET + @LIMIT)+' jam_category.category_name, sort_key=null '

so pagination does work, of course sort_key doesn't.

What should the result look like? If a category 'X' has two sort keys (AX and ZX for example), should the category be listed three times in Special:Categories? (If so, viewCategories in CategoryServlet must be changed) Or should the category 'X' be displayed only once in first appearance of (AX, X, ZX)? (Then of course the statement must be changed). Any other solutions?

Thanks for help!!! --hanspeterklapf 07-Jan-2010 00:43 PST

[Edit]Log Items and Log Items by Type

For MS-SQL STATEMENT_SELECT_LOG_ITEMS_BY_TYPE and STATEMENT_SELECT_LOG_ITEMS must be changed... The where-clause in the inner select appends @VWIKI_ID respectively @LOG_TYPE from type int, so they must be converted or casted. This change works for me:

STATEMENT_SELECT_LOG_ITEMS

+ 'where virtual_wiki_id = '+CAST(@VWIKI_ID AS VARCHAR) \

STATEMENT_SELECT_LOG_ITEMS_BY_TYPE

+ 'where log_type = '+CAST(@LOG_TYPE AS VARCHAR)+' and virtual_wiki_id = '+CAST(@VWIKI_ID AS VARCHAR) \

Thanks!! --hp 07-Jan-2010 01:09 PST

[Edit]Watchlist Statement for MS-SQL

After upgrading to 0.8.1 the STATEMENT_SELECT_WATCHLIST_CHANGES is broken. in the innner select, edit_date is named change_date, so the outer selects must be ordered by change_date:

    + 'order by edit_date desc '\
  + ') a '\
  + 'order by change_date '\
+ ') b '\
+ 'order by change_date desc '\

Also the length of @SQL exceeds its varchar, varchar(5000) works for me. Nice Day (and no more bug reports from me :) ), --hp 07-Jan-2010 03:20 PST

Also must be convert @VWIKI_ID as vachar:

on line 226

                     + 'where virtual_wiki_id = '+ @VWIKI_ID \

on line 255

                     + 'where log_type = '+@LOG_TYPE+' and virtual_wiki_id = '+@VWIKI_ID \

the lost "space" and "quote": on line 366

                +       'WHERE jam_topic.topic_id = '+CONVERT(VARCHAR, @TOPIC_ID) ' \

Also error in query (STATEMENT_SELECT_TOPIC_HISTORY)

on line 370

                +       'order by change_date desc ' \

"The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table expressions, unless TOP or FOR XML is also specified."

there must either write "top" or remove sorting

Thanks for report, these bugs were not listed here but are allready fixed in latest trunk. --hp 17-Jan-2010 04:11 PST
This issue should now be fixed with the release of JAMWiki 0.8.2. -- Ryan • (comments) • 28-Jan-2010 22:20 PST

[Edit]Page Move Error

Moving Tech talk:Transactions to Tech comments:Transactions created a link to a non-existent topic and wiped out the history of the original article when accessed from the "History" tab. The history was still available by manually typing in the topic version ID, and a Special:RecentChanges entry was correctly created. There was no indication in the logs of what might have happened. Trying to reproduce the issue locally has thus far been unsuccessful, so this one will probably require some digging into the database to see what happened. -- Ryan 10-Apr-2008 02:27 PDT

I experienced a similar problem repeatedly in 0.8.1 ...
I tried to move a page and used an underscore in the "to-name". The underscore is part of the "real world entity" which the "from-page" represents. The move was the attempt to correct the name ...
The result was: the "to-page" was empty (should have the contents of the "from-page") and the "from-page" was (correctly) converted to a redirect pointing to the "to-name".
Hanspeter Klapf was able to restore the contents of the "from-page" into the empty "to-page".
I will try to reproduce the problem ... Kind regards, Rudi Wiesmayr (AT) 26-Feb-2010 00:23 PST
Yep, the underscore is the bad guy. See Test from-page and Test to-page.
Same behaviour here in 0.9.0 as at home in 0.8.1. Kind regards, Rudi Wiesmayr (AT) 26-Feb-2010 00:32 PST
Looked into the annals of jamwiki: In Tech_comments:JAMWiki_Design#How_does_AnsiData/QueryHandler_write_Topic.content? Ryan wrote: The underscore removal is a Mediawiki-compatibility thing since they automatically convert underscores to spaces.
Can it be that the "move dialog page" fails to do this stripping correctly? Just a guess ... Rudi Wiesmayr (AT) 26-Feb-2010 00:41 PST
Thanks Rudi, now that there is a reproducible test case this should be easy to fix. I think you're probably right about move not correctly converting underscores - I'll look into this tonight. -- Ryan • (comments) • 26-Feb-2010 06:45 PST
revision 2895 will fix this issue, and I'll merge this for inclusion in JAMWiki 0.8.3. I've credited you in the CHANGELOG as "Rudi Wiesmayr", but let me know if you'd prefer something different. Thanks again for the test case! -- Ryan • (comments) • 28-Feb-2010 11:41 PST
Good to hear, that another bug is dead. As it is my real name, the credit is OK. Best regards, Rudi Wiesmayr (AT) 01-Mar-2010 06:31 PST
revision 2907 resolves a similar issue when a "+" is specified in the destination topic name. -- Ryan • (comments) • 02-Mar-2010 19:04 PST

[Edit]Error Migrating Database

The Migration-Tool in the admin section fails in 7.2 while trying to migrate the DB from MS-SQL to PostgreSQL 8.4 (postgresql-8.4-701.jdbc4.jar) with the message "Large Objects may not be used in auto-commit mode". Does anyone knows a work-around for this? Thanks in advance, --hp 28-Dec-2009 02:50 PST

I think that this may be the same issue as the one fixed in revision 2801. The fix will be included in JAMWiki 0.8.1 which should be released in the coming week. Do you have any error messages in your logs? If so I'll verify that this isn't something new. Thanks! -- Ryan • (comments) • 28-Dec-2009 08:18 PST
In my logs I see only the INFO "Unable to load class org.postgresql.Driver using the thread class loader, now trying the default class loader" but since no WARNING or ERROR follows, I assume the Driver-class was found (I put it in WEB-INF/lib and restarted the application). I will try upgrading from 7.2 to 8.1 next week and then retry the database migration. Thank you Ryan! --hp 29-Dec-2009 01:30 PST

[Edit]Virtual Wiki Link fails only on StartingPoints Page

I just upgraded from 0.6.7 to 0.8.2 and the upgrade was simple and without incident. The only problem I found is that a link on my StartingPoints page to a virtual wiki shows up as bolded text instead of a link. The same link works from the left menu and from every other page I've tested. I also tested links from the virtual wiki back to the default wiki and it had the same problem. My like is of the form

* [[:Hyperion:StartingPoints | Hyperion Wiki]]

Not really a big problem for me since I keep the same link in the left menu so I have the link I need but just wanted to report the problem. --Tom Schueller 28-Jan-2010 21:41 PST

That's probably an unfortunate side-effect of a bug fix that went into JAMWiki 0.8.1. It should be relatively easy to fix for the next release, thanks for the report. -- Ryan • (comments) • 28-Jan-2010 22:18 PST
revision 2866 should resolve this issue. -- Ryan • (comments) • 31-Jan-2010 18:02 PST

[Edit]Timestamp error

I upgraded my version of jamwiki from 0.6.6 to 0.8.2. Foor safety reasons I went thru all of the versions step by step. The version I have installed works fine until we try to save a topic. When doing so we get the following error:

 
org.jamwiki.DataAccessException: java.sql.SQLException: Cannot insert an explicit value into a timestamp column. 
Use INSERT with a column list to exclude the timestamp column, or insert a DEFAULT into the timestamp column..

I have installed the wiki on the following systems: wiki database is installed on a SQL 2008 server on windows 2003 OS wiki webpages are installed on on windows 2003 OS with Tomcat 5.5 webserver JDBC version is 3.0 (used different versions to check if that was the problem

--Angel 25-Feb-2010 03:12 PST

Other users have reported success with SQL Server and JAMWiki 0.8.2, so I'm not sure what in your environment might cause issues. Can you provide part of the stack trace that generated that error so I can see where in the code it is being generated? Thanks! -- Ryan • (comments) • 25-Feb-2010 06:36 PST

I found the problem. Wile upgrading to the current version I had to manually execute the sql statement. When doing so I use the guidelines in de upgrade.txt file. In this file there where some non ms sql satements which I thought I translated correctly. Today I looked at the sql.mssql.properties file and found my mistake on the timestamp column. Maybe you can reffer to taht file in de upgrade.txt so the correct statement can be used is upgrading manually

--Angel 05-Mar-2010 02:21 PST

revision 2973 fixes the UPGRADE.txt document. -- Ryan • (comments) • 24-Mar-2010 21:55 PDT

[Edit]XSS problem on login form

The login has an xss problem:

http://jamwiki.org/wiki/en/Special:Login?message=<script>alert("xss")</script>

frafu 04-Mar-2010 00:10 PST

Thanks, I'll make sure that is fixed for the next release. I'll credit you in the CHANGELOG as "frafu" unless you'd prefer something different. -- Ryan • (comments) • 04-Mar-2010 17:44 PST
revision 2972 fixes this issue. Good catch. -- Ryan • (comments) • 24-Mar-2010 20:09 PDT

[Edit]Lists & Tables & References: Indentation problems

See Test Table indent. Reported by User:RudiWiesmayr. -- Ryan • (comments) • 10-Mar-2010 22:30 PST

Ryan has already discovered my test page... ;-) Here comes the bug report:
Test Table indent shows a rendering problem when a list is immediately followed by a table. Here the table gets indented to the level of the list entry. A single EOL is not sufficient to bring the table to the left. A <br> or a <br style="clear:both;" /> does this, but inserts a blank line.
Test List indent shows another issue with indentation. When a list entry contains a '' which is not matched by another '', everything that follows (not only the next list entry) keeps indented. This also works with ''' or '''''.
There is another issue with indentation (no test page so far): When you have text after the <references/> tag, this text also gets indented like the listed footnotes.
Kind regards, Rudi Rudi Wiesmayr (AT) 14-Mar-2010 07:58 PDT
Ooops, I forgot my entry Text after <references/> keeps indented, so there IS a test case for this issue. Rudi Wiesmayr (AT) 14-Mar-2010 08:11 PDT
The text after the <references/> tag keeps indented.
Example in this wiki: Help:Footnotes#What_is_produced_at_the_points_of_insertion. I marked it with +++ End of references +++. Same behaviour in my wiki on 0.8.1. Kind regards, Rudi Wiesmayr (AT) 02-Mar-2010 00:43 PST
Sorry, I missed this bug report initially. I'll queue it up as something to resolve for the next release. -- Ryan • (comments) • 04-Mar-2010 19:15 PST
revision 2968 fixes the original issue and will be included in JAMWiki 0.8.4. I'll investigate the remaining two issues in the coming days. Thanks for the report & test cases. -- Ryan • (comments) • 22-Mar-2010 23:52 PDT
revision 2969 should fix the Test List indent issue. -- Ryan • (comments) • 23-Mar-2010 19:53 PDT
revision 2970 should fix the <revisions /> issue - the <ol> tag wasn't being closed, and surprisingly this seems to have gone unreported for a very long time. Thanks again for the reports & test cases - all will be fixed for JAMWiki 0.8.4. -- Ryan • (comments) • 23-Mar-2010 21:46 PDT