The JSPWiki 2.2 release is at the stage where all major functionality has been added, and now we're interested in mostly tweaking the functionality for a full release. This page is meant for discussion, ideas and bug reports for the 2.1 alpha releases, so please don't suggest any new, big functionality here. Those should go to Ideas. Also, bug reports on the stable version should go to BugReports.

The focus on this release has been with the authentication system, so we expect most problems to occur in it.

Would like to see more separation of the authentication, authorization, and user account management functions. My chief concern is that these are all mixed together now, making it impossible to integrate container-managed security the way it "should" be. It's too late for 2.2 I suspect, but I'd like to put this on the roadmap for 2.3. -- Andrew Jaquith

Also, if there are any pet BugReports that you really think should be fixed in this release, please make a mention of them here (just a one-two line reminder is enough; no need to make the page very big. :-) Please also add any items from the documentation that are missing, or link to pages on this site that you think should be included with the distribution.


Why don't we standardize on some decent date format like yyyy-mm-dd (for use in WebLogs, in the calendar etc.)? It's more logical than any other scheme, better for sorting, better readable (than i.e. 121104, easily confused as 12. Nov or 11. Dec), and been adopted by many standards organizations (see W3C - Date and Time Formats or A Summary of the International Standard Date and Time Notation). -- ReinhardEngel
Things that are probably still going to happen are:
  • New setup system for PageFilters; probably XML-based, since the current system does not allow multiple filters by the same name.
  • Documentation update and cleanup (yes, we're sorry, some of the features are still on the RTFS -stage.
  • Cleanup and bug fixes on the TemplateManager (which I accidentally checked in but was too lazy to remove :-)
  • rss.jsp to work better on individual files.
  • Redesign DefaultPermissions system for the PageAuthorizer; the current system has some glitches.
  • Make deleting pages possible.
  • XHTML compliance - for some really strange reason the W3 validator thinks that we are not valid HTML - it complains about META tag being non-valid in a HEAD element, and I just simply cannot figure out why this is so, because the spec clearly says it's okay. Please help me out on this, if you're a HTML guru.
XHTML
AFAIK in XHTML all official tags and attribute names have to be in lower case. -- ReinhardEngel
XHTML/HTML compliance
You just need to decide which code you are outputting. It cannot be both XHTML and HTML compliant at once (though it may appear that way). Although most browsers handle it (IE, Mozilla, etc), mixing <...> with the same tagname <.../> for self-closing elements like meta, link, img, etc., it is not compliant with either standard. Since the doctype states ...HTML 4.01... you don't have "/>" at the end of any tag, that is an XHTML (i.e. XML) feature. BTW, the validator is really telling you that the previous tag is in error, rather than the one which it is pointing at (just like hunting through the output of any complier you may have used in the past, you find previous errors have all sorts of fun side-effects downhill :) ). The renderer thing you have introduced in 2.1.x, once used for everything, will likely help with this task. My simple advice is this: clean, clean, clean. Best strategy for fixing unsolvable bugs. You may never find the cause, but it doesn't matter, your code will be in good shape and behaving well. --MurrayG

First, let's not mix up browser behaviour with markup standards; they're two different things.

JSPWiki uses XHTML, not HTML. And yes, all XHTML element type names ("tag names"), attribute names and fixed values must be in lowercase. Whereas HTML was SGML-based, XHTML is XML-based. One of SGML's numerous features that XML doesn't have (i.e., permit) is wrapping of case. Another is called tag minimization (i.e., not requiring end tags), and then there's how empty elements are handled. In HTML, <meta>, <img> and the other elements whose declared content model is EMPTY could simply be represented as a single tag, with their end tags inferred. There is no such feature in XML. The W3C's XML Working Group managed to find a relatively elegant solution for empty XML elements that actually worked in existing Web browsers: by adding " />" (note that the space preceding the slash is required) here was something that worked and was SGML-legal, via a minor change to the SGML declaration for XML (the machine-readable declaration for the profile).

Invalid (in XHTML):#

  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">   [uppercase]
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">   [no empty tag markup]
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>  [missing space]

Valid (in XHTML):#

  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
So what this comes down to, as it always has been, is declaring the markup language you're using and then sticking to it. If you've declared you're using XHTML you should also precede an appropriate DOCTYPE declaration with the XML declaration (<?xml version="1.0" encoding="UTF-8"?>). That's not strictly necessary but is good practice and gives validation tools a clue that you're using XML.

-- MurrayAltheim, 13-Apr-2007


You can download the current alpha on JSPWikiDownload.

I'll try to keep the discussion on this page relatively tight, so I will remove things that have already been taken care of. You can do that too =).


Documentation#


Open Bug Reports#

2004/12/06 - Make JSPWiki JDK1.5-compatible#

Not necessarily make use of new JDK1.5 features, merely avoid identifier names like "enum" which are now reserved words.

-- Ramon Casha

2004/10/26 - Lucene cache is not updated if page is changed "underneath JSPWiki"#

JSPWiki version JSPWiki v2.1.115-alpha
Java version 1.4.x
Operating system Linux
Web server and servlet container Tomcat 4.3.1
Page provider FileSystem, AntCvs (modified to work)
Browser n/a

Hi all,

I hope that someone sees this one ;-)
Anyway, the problem that I have is pretty simple, when using the CVS provider, the Lucene cache is never updated when the file is imported through CVS, even though the new file is shown on the Wiki. This patch(info) fixes that problem, as well as a crashing bug when a file is deleted.

Fixed in 2.1.117

2004/08/26 - Java2Html Plugin: Neverending loop in attachemnt loading#

JSPWiki version JSPWiki v2.1.103-alpha from current download, Java2Html Plugin 4.1
Java version 1.4.x
Operating system WinXP, Linux
Web server and servlet container JBoss 3.X - Jetty 4.X
Page provider FileSystem, RCS
Browser n/a

Hi,

I'm not sure if this is the right place here to ask but will try it.

I'm using the Java2Html plugin to display an attachment. Therefore in the plugin's execute method, the attachement is loaded and parsed. But in this case, the default authenticator asks the current page, if this attachement exists and its readable by the current user. Then all plugins on this page were executed, also the Java2Html plugin and loading of the attachement starts again. And again. And again.

No I'm not sure if this is a bug of the plugin or the authentication handling. The critical problem on this loop, is that in each call a new HTTP-Request is fired to the webserver, which ends up with something like 'no more threads available'. Server reboot is the only solution on this.

Regards

-- SteffenStundzig


2004/07/27 - jspwiki.tld: HistoryIteratorTag still defines a page attribute#

JSPWiki version JSPWiki v2.1.103-alpha from Nightly Build 2004.07.15
Java version 1.4.x
Operating system Win2K
Web server and servlet container Weblogic 8.1
Page provider n/a
Browser n/a
Fixed in v2.1.118

Weblogic server is moaning that there is no setter defined for attribute page. Simply removing

    <attribute>
       <name>page</name>
    </attribute>

as suggested in JSPWikiServletCompatibility resolved the issue. -- Christian Buchegger


2004/07/15 - New lines in preformatted block not preserved when preceded by spaces#

JSPWiki version JSPWiki v2.1.103-alpha from Nightly Build 2004.07.15
Java version 1.4.x
Operating system Red Hat 9
Web server and servlet container Resin Server 3.0.6
Page provider VersioningFileProvider
Browser Internet Explorer 6.0

I'm not sure if this is a bug or a new feature.

It appears that new lines are disappearing when the preformatted block tags are preceded by spaces in v2.1.103-alpha. This tag combination behaved differently (and as I preferred for use inside numbered lists) in v2.0.52. Take a look at the following examples.

-- DirkSchreckmann

2004/05/19 - CamelCase causing exception#

Using v2.1.98-CVS Apache 2.0.49 Tomcat 5.0.19

Just moved existing Wiki pages from JSPWiki 2.0.36 to 2.1.98-CVS. With the CamelCase property set to true JSPWiki fails to start with the following exception.

2004-05-19 20:44:24,171 [TP-Processor3] ERROR com.ecyrd.jspwiki.WikiEngine - Failed to start managers.
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.StringBuffer.replace(StringBuffer.java:711)

If the CamelCase property is set to false then JSPWiki starts up perfectly. I am not sure yet if its a single page that is causing the problem. I need to investigate further. This zip contains the pages.

-- RobertMcGovern


2004/05/11 - Renaming the Start Page seems to be broken#

Using v2.1.94CVS.

I didn't know whether to post this here or in the general bug reports section. Sorry if it should have gone there. Here goes: When I change the value of the jspwiki.frontpage property in jspwiki.properties, the wiki:Include tag breaks (fails to load the page). Having checked the logs, I see that the wiki knows the name of the new page, but somehow can't load it. The exception is thrown in Include's doEndTag() handler. This happens no matter what page I choose to be the front page. It only happens when I use the application name directory as the last part of the URL - no page specified. If I then click on a link or manually put in the full URL to any page, including the one that failed to load, it loads properly. I have checked my jspwiki.properties file. Any clues?
-- RayBaco


2004/03/16 - InsertPagePlugin does not check permissions from included page#

Using v2.1.86-alpha.

The InsertPagePlugin does not check permission of included page. This is a security problem, because this way you can create a new page an include protected page. As a result, you have access to the protected page.

  • Create a page with ACL info which included no view permission (InvisiblePage).
  • Create another new page with InsertPagePlugin like this as content: [{InsertPage page='InvisiblePage'}]
  • As a result you will see the content of InvisiblePage, even if you don't have view permission.
-- Guido

2004/02/19 - Page suddenly empty#

I'm testing 2.1.86-alpha and sometimes JSPWiki displays a page as empty.
If I check the txt-file there is text in the file. Why does this happen? I am doing some bulk updates on the pages (like changing a common filedirectory in all wiki-pages linking there). Could that be the reason? If so how do I work around that? I'm running JSPWiki on JBoss on WinXp
-- MichaelWiller


2004/01/20 - Attachments arn't accessable#

Using v2.1.86-alpha.

An attachment can be added successfully, but when attempting to retrieve the attachment the browser reports that the site cannot be opened. The stdout log in Tomcat shows: Latest version=-1 But the file is in the dataset and the properties seem correct. This only occurs when using ssl (by setting the security constraint in the web deployment to confidential and protected)

i.e.

<security-constraint>
<web-resource-collection>
<web-resource-name>Protected</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>

<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>


2003/12/01 - Quotes & WikiName in Id or Name attribute causes page errors#

Using v2.1.86-alpha.

If the Id or Name attribute in embedded HTML is a WikiName enclosed in quotes there are anomalies in the page display. E.g.

Where is that <font id="Darkblue" color=DarkBlue>rascally</font> rabbit?

Where is that <font id="Dark Blue" color="DarkBlue">rascally</font> rabbit?

Where is that <font id="DarkBlue" color="DarkBlue">rascally</font> rabbit?

. . . displays as -

Where is that rascally rabbit? 

Where is that rascally rabbit? 

Where is that ?" color="DarkBlue">rascally rabbit? 

I have not done extensive testing, this may occur with other attributes as well, but does not occur with all.

-- PaulDownes


Hi, I'm testing the upgrade and I'm getting javascript errors on setting the form focus in EditTemplate.jsp. Would it be possible to put some sort of null check in the 'onload' as below?
<wiki:CheckRequestContext context="edit">
  <body class="edit" bgcolor="#D9E8FF" 
   onLoad="if( document.forms[1].text != null ) {document.forms[1].text.focus();}">
</wiki:CheckRequestContext>

<wiki:CheckRequestContext context="comment">
  <body class="comment" bgcolor="#EEEEEE" 
   onLoad="if( document.forms[1].text != null ) {document.forms[1].text.focus();}">
</wiki:CheckRequestContext>

-- ScottHurlbert

Ah, I see, the real problem is that you have probably removed the Search box... Really what we should do is to refer to the textarea via a name instead of its # on the web page.

-- JanneJalkanen


I'm testing v2.1.89 alpha, and on the UserPreferences page, i cant set the editor width and hieght. no matter what i do, it always reverts back to 80 & 25. --DaSamon

I haven't been keeping up with the 2.x releases much, but the 80x25 dimensions sound suspiciously like what I have in my contributed template. If you are using that template, make sure you are using the most recent version, which does allow you to set the width and height (assuming you have cookies enabled). -- MichaelGentry


Suggestions#

Auto-inc topic number support, like in SnipSnap: #.#.##

It's very useful to add support for topic numbering. -- Bin Sun
eg:
# topic1
#.# subtopic1
turns into:
1 topic1
1.1 subtopic1

AutoBackEditPatch#

  • Hmmm, have you tried the AutoBackEditPatch? I personally hate hating the edit forms in my browser history. We use it just fine on our wiki at work and it seems like it is harmless. --JohnV

PrintFriendly#

I would like to suggest that the PrintFriendly feature in MichaelGentry's MRG template is added to the JSPWiki core, and a PrintFriendly option is added to the default template's page footer menu.

-- PaulDownes

Actually, it's already there, but it's in the form of a special CSS stylesheet. You can either change into a print -stylesheet from the View-menu of your browser (if it is supported), but printing a page should automatically remove things like LeftMenu.

-- JanneJalkanen

To which CSS stylesheet are you referring? The only stylesheets that appear to be distributed with the 2.0.52 version of JSPWiki are the jspwiki*.css files, none of which seem to address printing per se.

In at least the Internet Explorer browser, printing a page does not automatically remove the LeftMenu.

I'd like to second the motion of adding the MRG template's PrintFriendly.jsp and an accompanying link to execute that JSP (whether on the left menu or in the list of links at the bottom of each page) to the JSPWiki core.

-- Theosophe74

No, it's in 2.1. branch - there's a print stylesheet called jspwiki_print.css. It's actually rather trivial to add to 2.0, if you want to.

I don't actually want to add PrintFriendly.jsp, because I don't want to add any new top-level JSP pages unless absolutely necessary (and with the new WikiForm -plugin, after a bit of polishing, we can probably start getting rid of a bunch of the old ones as well).

If you don't want to have a CSS-based solution, I'll probably be adding a "plain" template to the next release.

-- JanneJalkanen

I couldn't disagree with this approach more. I am very frustrated with this at the moment and the whole non configurability of the left menu thing is the only downside to jspwiki that i have. IE definitely prints the left menu. I don't know how to print with the CSS solution. Adding a plain template doesn't do any good because i want to do it within my current template. I haven't been able to get PrintFriendly or HideMenu to work with the default template.

In general i think worrying about how many top level jsps there are is a developer worry that i as a user could care less about. I would like all the goodies tossed in so i don't have to try to add things to the wiki, which usually isn't that easy because somethng wierd always happens.

-- Anonymous

Out of curiosity, how would one re-style a page to use jspwiki_print.css without having a browser that supports the "print -stylesheet" behavior that you described? I can move this to StupidQuestions if that's appropriate. :-)

Are there any plans to release a non-alpha 2.1.x version of JSPWiki in 2003? :-) Thanks.

-- Theosophe74

Javascript. It even has an added bonus that you don't have to necessarily reload the page.

2.2 will be out "when it's ready", to follow the general Linux release schedule =). It all depends on available time.

Having said that, many people are using 2.1 alpha successfully for production work...

-- JanneJalkanen


Page authorization#

It would be nice if a page's permission could apply to a scope of pages instead of just the current page.

For example instead of [{ALLOW view somegroup}] you would write [{ALLOW* view somegroup}] and all pages that start with the current page's title would be affected. Having to specify the permission for each individual page as soon as they deviate from the DefaultPermission is quite cumbersome. Alternatively the DefaultPermission handling might be modified, e.g. by using PrefixDefaultPermission to apply to all pages starting with Prefix.

I don't think that's a very good idea. It would easily lead into a "now exactly where this thing is configured" -nightmare. I'd rather go with proper SubPages. --JanneJalkanen

Questions#

Page Rename Patch#

  • By chance did a page rename feature make it into 2.1? I recall mention that the matchEnglishPlurals issues had been addressed, and that was one of the last holes in the RenamePagePatch. --JohnV
  • No, not yet. I'll see if it can be integrated. All known issues with matchEnglishPlurals have been solved. --JanneJalkanen
  • You mention that "Make deleting pages possible." is still going to happen, might I suggest that implementing the RenamePagePatch is one means to accomplish it? Hint-hint, nidge-nudge. (I really like being able to rename pages, and hate having to patch source.) --JohnV
  • Well, it kinda works in the same area, and the biggest reason that I haven't included it is that we needed a working auth before allowing something like this which is potentially NOT reversible :-). --JanneJalkanen

Chinese prompt message under UTF-8 #

  • Hi, JanneJalkanen. My name is Jin Zeng and I live in Beijing of China. Thanks for your great work, I am using your JSPWiki v2.0.52. It works well.In order to input Chinese, I set JSPWiki to use UTF-8. It also does well.Further more, I want the prompt message displayed in Chinese. So I think I need to do some change in the JSP source file.For example, I edited a file named FindContent.jsp. However, the characters I input was displayed in irregular character can not be read.How do I fix this problem then? -- Jin Zeng

Which prompt message? You will need to make a Chinese template. See WikiTemplates. Unfortunately, not all of JSPWiki is yet localizable... --JanneJalkanen


Error: 'document.forms.1.text' is null or not an object#

  • I get this error whenever I try to edit a page at www.jspwiki.org. (IE5.5)
  • I also get it if I try to run 2.1.103-alpha at my site
  • A stable version is what I would really like, but I would like to have the fix for nested numeric bullets. Any suggestions?

Thanks, --KirkWolf

IE 5.5 and 6 do not like document.forms[1].text, because they use another Document Object Model (I suppose IE6 can be made to like it by changing the DOCTYPE of the page, but I haven't tried that yet). Simple solution: edit default/EditTemplate.jsp by deleting the onload instruction on lines 14 and 18. Better solution (if you want to keep the functionality): add an ID to the main FORM of the editing page, and replace document.forms[1].text.focus() using the getElementByID() function... Wouter


Closed Bugs#

2003/11/05 - Quotes cause Preview page errors#

Using quotes in text causes anomalies in display on the preview page, and if the Save button is selected, the text following the first quote is deleted.

-- PaulDownes

Thanks, this is already fixed in 2.1.84.

-- JanneJalkanen


Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
patch
JSPWiki_lucene.patch 4.6 kB 1 27-Oct-2004 16:14 80.126.27.148
« This page (revision-116) was last changed on 20-Feb-2011 19:54 by Harry Metske