March 2010 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Add 6 new methods to com.xpn.xwiki.api for loading and saving documents as the content author of the script calling the method.
by Caleb James DeLisle 01 Apr '10

01 Apr '10

Hello all, I'd like to make this change: Add to xwiki.api.Document saveAsAuthor() saveAsAuthor(String comment) saveAsAuthor(String connent, String isMinorEdit) deleteAsAuthor() Add to xwiki.api.XWiki getDocumentAsAuthor(DocumentReference reference) getDocumentAsAuthor(String fullName) They save, load or delete the document if the script's contentAuthor has the necessary permission, the user in context is switched so the contentAuthor is listed as having done the operation. Though they say *AsAuthor the action will take place in the name of the contentAuthor of the document this is mainly because *AsContentAuthor is long and confusing. This is already partially available if the script has programming access but I think it is an important enough feature that it should not be limited to scripts with programming access. Use case: allowing users to submit information without letting them see or modify what other users had submitted. This is my +1 Caleb

5 9

[xwiki-devs] [Proposal] Rationalize our projects and SVN structure
by Vincent Massol 01 Apr '10

01 Apr '10

Hi devs, Jean-Vincent, Thomas and I (hope I didn't forget anyone) would like to propose the reorganization described below: = Projects = In 2007 we decided to start multiple projects based on the XWiki platform, namely: manager, workspaces and watch. The objective was to provide multiple products based on the XWiki platform with the same expectations in terms of quality; all those projects were top level projects to reflect that. A year later we decided to put all our development effort in XWiki Enterprise, since then all the projects except Enterprise and Office have been left aside. == XWiki Watch == * Last significant jira issue fixed on 12/Jun/2009 * Last release 1.1M1 (based on XE 1.5.1) - 11/Sep/08 While watch code is compatible with recent XE versions its distribution is not maintained. The proposal is to move watch code somewhere else in the SVN (see below) and to drop the distribution modules (database, distribution, installers). Watch documentation (including installation guides) would be placed on code.xwiki.org and watch.xwiki.org pages would redirect to this new location. Watch JIRA would be made read only and move to the retired category. All new issues should use the existing Watch application JIRA. == XWiki Workspaces == * Last significant jira issue fixed on 19/Oct/2008 * Last release 1.2M1 (based on XE 1.5.2) - 19/Sep/08 Workspaces is no longer maintened and it doesn't work with XE > 1.5.2. The proposal is to move it to contrib/retired and to display a banner on workspaces.xwiki.org saying that this product is retired (see http://beehive.apache.org/ for an example). Workspaces JIRA would be made read-only. == XWiki Eclipse == * Last significant jira issue fixed on 06/Jan/09 * Last release 2.2 - 11/Jan/09 XEclipse is no longer maintained and it doesn't handle the xwiki/2.0 syntax. The proposal is to move it to contrib/retired and to display a banner on xeclipse.xwiki.org saying that this product is retired. XEclipse JIRA would be made read-only. Note that we hope the project will be brought back from the dead in the future. == XWiki Manager == * Last significant jira issue fixed on 11/Apr/09 (XEM jira project) * Last release 2.2 (based on XE 2.2) - 16/Feb/10 The Manager case is different, it's released often and isn't lagging behind XE. The problem is that we only release it labeled as stable, based on XE stable versions, which is bad since it's not properly tested before that. Manager is not a product per-se, all the code that allows to run a wiki farm is located in the xwiki platform, which means that having a different life-cycle for its distribution doesn't make sense and doesn't serve the product (less testing). Manager is a set of 2 plugins making easier to run a wiki farm. We should emphasize on this, make people understand that the virtual feature is a core feature and that they can take advantage of it on any XE release by using the correct plugins and apps. This way we could get feedback from people doing staged deployment. We wouldn't mislead people by releasing a distribution directly in a stable version. = SVN Organization = If we agree on the proposal above we need to refactor the SVN according to it. Possible implementation: {{code language="none"}} /svnroot/xwiki/ |_ contrib/ |_ people/ |_ projects/ |_ retired/ |_ photoalbum/ |_ s5/ |_ workspaces/ |_ xeclipse |_ enterprise/ |_ extensions/ |_ administration |_ application-manager/ |_ plugin/ |_ application/ |_ blog |_ calendar |_ ircbot |_ officeimporter |_ panels |_ scheduler/ |_ plugin/ |_ application/ |_ selenium/ |_ skins/ |_ colibri/ |_ statistics/ |_ plugin/ |_ application/ |_ tag/ |_ plugin/ |_ application/ |_ watchlist/ |_ plugin/ |_ application/ |_ webdav/ |_ wiki-macro-bridge/ |_ wiki-manager/ |_ watch |_ application/ |_ component/ |_ gwt/ |_ gwt-client/ |_ gwt-server/ |_ workstream/ |_ platform/ |_ components/ |_ components-all/ |_ xwiki-component/ |_ xwiki-rendering/ |_ ... |_ gwt |_ xwiki-gwt-api/ |_ xwiki-gwt-dom/ |_ xwiki-gwt-user/ |_ xwiki-gwt-wysiwyg-client/ |_ xwiki-gwt-wysiwyg-server/ |_ web |_ tools/ |_ xoffice {{/code}} Modifications summary: * 4 projects moved to retired: photoalbum, s5, workspaces, xeclipse * platform/web/standard content (templates and resources) moved to platform/core/web (packaging: zip) * platform/web/ gwt modules moved to platform/core/gwt (packaging: zip) * new plaform/distribution module (packaging: war) it replaces the previous platform/web-standard minimal webapp * new extensions top level project gathering plugins and applications, rationale: ** applications made of a plugin and an application will now be released in one place ** with the future extension-manager all the extensions (plugins, document sets, skins) should be released as a XAR ** coherent with extensions.xwiki.org = XWiki.org Website Organization = {{code language="none"}} |_ www.xwiki.org |_ dev.xwiki.org |_ enterprise.xwiki.org |_ extensions.xwiki.org (was: code.xwiki.org) |_ l10n.xwiki.org |_ platform.xwiki.org |_ xoffice.xwiki.org {{/code}} wdyt? Thanks -Vincent

4 4

[xwiki-devs] [VOTE] Escaping for document references in xwiki syntax links
by Vincent Massol 01 Apr '10

01 Apr '10

Hi, I'm working on fixing http://jira.xwiki.org/jira/browse/XWIKI-4957 I'm proposing to use \ as the escape char since we're already using it for escaping chars in references. for ex: [[My\.Page\@\#\?]] here's my +1 Thanks -Vincent PS: for xwiki syntax 2.1, i'd like to propose that we use [[reference||anchor="..." queryString="..."]] but that'll be another vote

5 5

[xwiki-devs] XWiki Logo Challenge
by Jean-Vincent Drean 31 Mar '10

31 Mar '10

Hi XWikiers! It's time to inject new blood in XWiki.org. While discussing about improving its look & feel we thought it would be a good time to create a new logo for XWiki.org as it's an important part of a website design. We borrowed the current logo from XWiki.com some time ago and, in order to keep the distinction between the company and the Open-Source project clear, we think XWiki.org websites and projects need their own logo. As you may know, we love proposals, that's why we'd like to make the logo design an open challenge, anyone interested can join and a vote amongst the community will determine the winner. Even if the main purpose of the challenge is to have fun, the person whose design gets selected will receive XWiki goodies, including his logo printed on a t-shirt obviously :) The designer of the selected logo will enter the Hall Of Fame, and last but not least reward : the design will be spread wide (XWiki Enterprise is more than 10000 downloads/month and XWiki.org web site more than 50000 visits a month). The challenge takes place there: http://dev.xwiki.org/xwiki/bin/view/Community/LogoChallenge Thanks, JV.

19 30

[xwiki-devs] [Proposal] Handling document references in UIs?
by Vincent Massol 31 Mar '10

31 Mar '10

Hi, We need a consistent way to handle document references in UIs. For example, on the rename template, the title is "Renaming <string serialization of a reference here>". Thus if the page is named "?." in the space "Main" for example we get: "Renaming Main.?\." Same for the wysiwyg editor's insert link dialog box (under the title we have the technical reference printed). Proposal ======= Since references are technical I don't think we should print them in the UI. Instead we should print its constituents: wiki, space, page (or just space, page when not in multiwiki or when handling a ref not from the current wiki). This is what Caty has done in the Search UI BTW. Thus I propose to reuse her idea and print this: wiki >> space >> page where >> is the HTML Å symbol. You can check visually what I mean here: http://playground.myxwiki.org/xwiki/bin/view/Main/WebSearch?text=test&x=0&y… Thus applying this to the example above, we would have: "Renaming Main >> ?." And thus this removes the technical aspects: * no ":" or "." to separate wiki and space *no character escaping WDYT? Any other idea to achieve the same result ? Thanks -Vincent

3 5

Re: [xwiki-devs] [Proposal] Handling document references in UIs?
by Thomas Mortagne 31 Mar '10

31 Mar '10

On Wed, Mar 31, 2010 at 13:29, Vincent Massol <vincent(a)massol.net> wrote: > > On Mar 31, 2010, at 12:50 PM, Sergiu Dumitriu wrote: > >> On 03/31/2010 11:30 AM, Vincent Massol wrote: >>> >>> On Mar 31, 2010, at 10:30 AM, Vincent Massol wrote: >>> >>>> Hi, >>>> >>>> We need a consistent way to handle document references in UIs. >>>> >>>> For example, on the rename template, the title is "Renaming<string serialization of a reference here>". >>>> Thus if the page is named "?." in the space "Main" for example we get: "Renaming Main.?\." >>>> Same for the wysiwyg editor's insert link dialog box (under the title we have the technical reference printed). >>>> >>>> Proposal >>>> ======= >>>> >>>> Since references are technical I don't think we should print them in the UI. >>>> >>>> Instead we should print its constituents: wiki, space, page (or just space, page when not in multiwiki or when handling a ref not from the current wiki). >>>> >>>> This is what Caty has done in the Search UI BTW. Thus I propose to reuse her idea and print this: >>>> >>>> wiki>> space>> page >>>> >>>> where>> is the HTMLÅ symbol. >>>> >>>> You can check visually what I mean here: >>>> http://playground.myxwiki.org/xwiki/bin/view/Main/WebSearch?text=test&x=0&y… >>>> >>>> Thus applying this to the example above, we would have: >>>> >>>> "Renaming Main>> ?." >>>> >>>> And thus this removes the technical aspects: >>>> * no ":" or "." to separate wiki and space >>>> *no character escaping >>>> >>>> WDYT? Any other idea to achieve the same result ? >> >> +1. >> >> Maybe / would be good as a separator. It's respecting the directory/file >> separator, it's also used in the URLs. it's familiar. > > "/" would be ok too but provided it's displayed in a different color and appropriate spacing between reference parts and "/". I have the feeling Å provides less ambiguity since it cannot appear easily in a document name while "/" is common. I think i would also prefer an arrow or any other shape more UI oriented than "/". > > Thanks > -Vincent > >>> Another idea: >>> have a rectangle box drawn with 3 internal boxes, each for a reference part (wiki, space, page). >> >> I don't like this. Boxes are visual only, and borders aren't really good >> at being suggestive. >> >> -- >> Sergiu Dumitriu > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

2 1

Re: [xwiki-devs] [Proposal] Handling document references in UIs?
by Thomas Mortagne 31 Mar '10

31 Mar '10

On Wed, Mar 31, 2010 at 10:30, Vincent Massol <vincent(a)massol.net> wrote: > Hi, > > We need a consistent way to handle document references in UIs. > > For example, on the rename template, the title is "Renaming <string serialization of a reference here>". > Thus if the page is named "?." in the space "Main" for example we get: "Renaming Main.?\." > Same for the wysiwyg editor's insert link dialog box (under the title we have the technical reference printed). > > Proposal > ======= > > Since references are technical I don't think we should print them in the UI. > > Instead we should print its constituents: wiki, space, page (or just space, page when not in multiwiki or when handling a ref not from the current wiki). > > This is what Caty has done in the Search UI BTW. Thus I propose to reuse her idea and print this: > > wiki >> space >> page > > where >> is the HTML Å symbol. > > You can check visually what I mean here: > http://playground.myxwiki.org/xwiki/bin/view/Main/WebSearch?text=test&x=0&y… > > Thus applying this to the example above, we would have: > > "Renaming Main >> ?." > > And thus this removes the technical aspects: > * no ":" or "." to separate wiki and space > *no character escaping > > WDYT? Any other idea to achieve the same result ? +1 for no reference syntax in the UI Now how to show it in the UI is another subject and i don't have precise idea, search UI looks nice enough to me. What is sure is that we need a common tool to show a reference in the UI and to use everywhere as much as possible. > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

1 0

[xwiki-devs] About integrating office-preview module in platform
by Asiri Rathnayake 31 Mar '10

31 Mar '10

Hello Devs, I committed an office-preview module in sandbox ( http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-officepreview/) about a month or two ago. The purpose of this module is to enable previewing of office attachments (word, spreadsheets, presentations) using the office-importer module. This module was developed for a demonstration purpose and needless to say it was cooked up as fast as possible without much attention to technical aspects. We've planned to integrate this module into platform and therefore need to clear out those technical issues. Our initial plan was to make this module available in 2.3 final release, but I doubt if I would have enough time to spend on purifying the code before it can be integrated. In any case I will list the technical issues we have with current code and propose some solutions so that we can come to an agreement about the design: 1. Each office-preview consists of an XDOM and a bunch of temporary files corresponding to images embedded inside the original office document. Currently these temporary files are stored inside the "charts" directory used by the charting plugin. I'm not sure if using "charts" directory and the "charting" action is a good idea, may be we should introduce the "tempresource" action before integrating this code. 2. An office-preview needs to be aware of attachment version (if a new version of an attachment is uploaded, preview must change). Also, when building the office preview, urls to temporary files (images) must be generated. 2.1 Currently DocumentAccessBridge does not provide an API to query the attachment version. 2.2 Generating urls to temporary files inside "charts" directory cannot be done via any component api. Because of above two reasons, office-preview module currently depends on xwiki-core module which is a bad practice for newer modules. We can deal with this issue by adding new methods to DAB (not good) or by having a component interface inside xwiki-officepreview module and it's implementation in xwiki-core module. I'm not sure if any of these solutions is perfect. 3. Each generated office-preview is cached. When a cache entry is disposed, all the temporary files associated with that preview is deleted (DisposableCacheValue). However, I noticed that DisposableCacheValue::dispose() is not invoked when XE shuts down. We could fix this by adding an event listener to listen for XE shutdown events and calling DisposableCacheValue::dispose() manually. 4. A requested feature (by ludovic) is to cache the whole office-preview (i.e. XDOM + tempfiles) on the disk, this way previews will even survive XE restarts. This is something we need to agree on. 5. Previewing office presentations (ppt) poses a lot of problems. A presentation import (as in officeimporter) consists of a .zip archive with image slides and html slides (text version) and the XDOM simply hosts a piece of html that reads slides from this .zip attachment. This idea does not jump into office-preview module very well and therefore we dumped html slides and kept image slides only for previewing. There are few hacks I did to implement previewing presentations but I'll talk about them in a separate email. I would be very glad if you can comment on first 4 points I've mentioned. Once we have reached an agreement on these points, I'll make necessary changes and integrate the code in our main source tree. Thanks. - Asiri

2 2

Re: [xwiki-devs] [xwiki-notifications] r28004 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api
by Sergiu Dumitriu 30 Mar '10

30 Mar '10

On 03/29/2010 06:57 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-03-29 18:57:58 +0200 (Mon, 29 Mar 2010) > New Revision: 28004 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Document.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java > Log: > XWIKI-5041: Allow script authors to load and save documents in their own security context, not the user's Quick review: 1. Although this is not always the case in the current API, methods should not throw exceptions, since there is no way to catch them in Velocity, and it's not nice at all to display exceptions and stacktraces to the user. It would be better to catch all and return a boolean if the save/delete fails. 2. I don't quite like the comments; with an empty mind, I wouldn't understand what "the author of the code calling this function takes responsibility" actually means. Maybe something like this would be better: Save the document under the privileges of the script's author. More specifically, before saving, access rights are checked for the {@link #getContentAuthor content author} of the context document on the target document, which also is set as the new author of the document. The comment for XWiki.getDocumentAsAuthor is quite good. Read below for more comments. > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Document.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Document.java 2010-03-29 16:57:48 UTC (rev 28003) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Document.java 2010-03-29 16:57:58 UTC (rev 28004) > @@ -1823,6 +1823,64 @@ > } > } > > + /** > + * Save the document, the author (contentAuthor) of the code calling this function takes responsibility. > + * Saves with minorEdit set to false and no edit comment. > + * > + * @throws XWikiException if script author is not allowed to save the document or if save operation fails. > + * @see #saveAsAuthor(String, boolean) 2.3M2 already. > + * @since 2.3M1 > + */ public boolean saveAsAuthor() > + public void saveAsAuthor() throws XWikiException > + { > + saveAsAuthor("", false); > + } > + > + /** > + * Save the document, the author (contentAuthor) of the code calling this function takes responsibility. > + * Saves with minorEdit set to false. > + * > + * @param comment The comment to display in document history (what did you change in the document) > + * @throws XWikiException if script author is not allowed to save the document or if save operation fails. > + * @see #saveAsAuthor(String, boolean) > + * @since 2.3M1 > + */ > + public void saveAsAuthor(String comment) throws XWikiException > + { > + saveAsAuthor(comment, false); > + } > + > + /** > + * Save the document, the author (contentAuthor) of the code calling this function takes responsibility. > + * This document will be saved if the author of the document containing the code which calls this function has > + * edit access to it. The contentAuthor of this document will be set to the author of the calling script, not the > + * viewer. This line doesn't make sense: > + * It is unwise to allow this function to be called by the viewer of the script. > + * > + * @param comment The comment to display in document history (what did you change in the document) > + * @param minorEdit Set true to advance the document version number by 0.1 or false to advance version to the next > + * integer + 0.1 eg: 25.1 > + * @throws XWikiException if script author is not allowed to save the document or if save operation fails. > + * @since 2.3M1 > + */ > + public void saveAsAuthor(String comment, boolean minorEdit) throws XWikiException > + { I wonder if this is the best way to get the content author. What happens with all the different include methods? Specifically, DocumentA includes DocumentB (sheet or topic), the call is in DocumentB; what is the context document? > + String author = getXWikiContext().getDoc().getContentAuthor(); > + if (hasAccessLevel("edit", author)) { > + String viewer = getXWikiContext().getUser(); > + try { > + getXWikiContext().setUser(author); > + saveDocument(comment, minorEdit); > + } finally { > + getXWikiContext().setUser(viewer); > + } > + } else { > + java.lang.Object[] args = { author, getXWikiContext().getDoc(), this.doc.getFullName() }; > + throw new XWikiException(XWikiException.MODULE_XWIKI_ACCESS, XWikiException.ERROR_XWIKI_ACCESS_DENIED, > + "Access denied; user {0}, acting through script in document {1} cannot save document {2}", null, args); > + } > + } > + > protected void saveDocument(String comment, boolean minorEdit) throws XWikiException > { > XWikiDocument doc = getDoc(); > @@ -1952,6 +2010,31 @@ > } > } > > + /** > + * Delete the document, the author (contentAuthor) of the code calling this function takes responsibility. > + * It is unwise to allow this function to be called by the viewer of the script. > + * > + * @throws XWikiException if script author is not allowed to delete the document or if save operation fails. > + * @since 2.3M1 > + */ > + public void deleteAsAuthor() throws XWikiException > + { > + String author = getXWikiContext().getDoc().getContentAuthor(); > + if (hasAccessLevel("delete", author)) { > + String viewer = getXWikiContext().getUser(); > + try { > + getXWikiContext().setUser(author); > + deleteDocument(); > + } finally { > + getXWikiContext().setUser(viewer); > + } > + } else { > + java.lang.Object[] args = { author, getXWikiContext().getDoc(), this.doc.getFullName() }; > + throw new XWikiException(XWikiException.MODULE_XWIKI_ACCESS, XWikiException.ERROR_XWIKI_ACCESS_DENIED, > + "Access denied; user {0}, acting through script in document {1} cannot delete document {2}", null, args); > + } > + } > + > public void deleteWithProgrammingRights() throws XWikiException > { > if (hasProgrammingRights()) { > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java 2010-03-29 16:57:48 UTC (rev 28003) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java 2010-03-29 16:57:58 UTC (rev 28004) > @@ -172,6 +172,53 @@ > } > > /** > + * Loads an Document from the database. Rights are checked on the author (contentAuthor) of the document > + * containing the currently executing script before sending back the loaded document. > + * > + * @param fullName the full name of the XWiki document to be loaded > + * @return a Document object or null if it is not accessible > + * @throws XWikiException > + * @since 2.3M1 > + */ > + public Document getDocumentAsAuthor(String fullName) throws XWikiException > + { > + DocumentReference reference; > + This branching could be replaced by ....resolve(StringUtils.defaultString(fullName); > + // We ignore the passed full name if it's null to match behavior of getDocument > + if (fullName != null) { > + // Note: We use the CurrentMixed Resolver since we want to use the default page name if the page isn't > + // specified in the passed string, rather than use the current document's page name. > + reference = this.currentMixedDocumentReferenceResolver.resolve(fullName); > + } else { > + reference = this.defaultDocumentReferenceResolver.resolve(""); > + } Perhaps you mean: return getDocumentAsAuthor(reference); > + return getDocument(reference); > + } > + > + /** > + * Loads an Document from the database. Rights are checked on the author (contentAuthor) of the document > + * containing the currently executing script before sending back the loaded document. > + * > + * @param reference the reference of the XWiki document to be loaded > + * @return a Document object or null if it is not accessible > + * @throws XWikiException > + * @since 2.3M1 > + */ > + public Document getDocumentAsAuthor(DocumentReference reference) throws XWikiException > + { > + String author = getXWikiContext().getDoc().getContentAuthor(); > + XWikiDocument doc = this.xwiki.getDocument(reference, getXWikiContext()); > + if (this.xwiki.getRightService().hasAccessLevel("view", author, doc.getFullName(), == false should be replaced by a ! > + getXWikiContext()) == false) { > + return null; > + } > + > + Document newdoc = doc.newDocument(getXWikiContext()); > + return newdoc; > + } > + > + /** > * @param fullname the {@link XWikiDocument#getFullName() name} of the document to search for. > * @param lang an optional {@link XWikiDocument#getLanguage() language} to filter results. > * @return A list with all the deleted versions of a document in the recycle bin. -- Sergiu Dumitriu http://purl.org/net/sergiu/

3 4

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.2.4 Released
by Thomas Mortagne 30 Mar '10

30 Mar '10

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.2.4. This is a bug fix release for the 2.2 branches. It fixes mainly two important regressions on rights manager UI and statistics module. Important Bugs fixed: * XASCH-52 - Job script shouldn't be edited with wysiwyg * XABLOG-99 - Blog Category Name with Apostrophe crashes Blog Category function * XWIKI-5057 - Rights aren't saved if the groups/users radio button is not manually selected * XWIKI-5039 - When starting a wiki on a sub wiki page, main wiki main page is broken by statistics module * XWIKI-4957 - Allow entering @, ? and # characters in link references * XWIKI-5053 - Cannot upload attachments to pages with # in their name * XWIKI-5063 - Don't fail the rendering when the document's title fails to be rendered * XWIKI-4984 - Header ids are always the same ("H") with Chinese or any other language without any ASCII character * XWIKI-5035 - LazyXWikiDocument is not synchronized anymore with XWikiDocument * XWIKI-5036 - WYSIWYG editor doesn't display when creating a document named #"&§-_\ * XWIKI-5021 - "Save and Continue" doesn't work in Preview mode only with IE7 * XWIKI-4723 - Could not restart only one cluster instance in cluster mode because of stuck JVM Translations: * Newly supported language: Vietnamese For more information see the Releases notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise224 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM224 Thanks -The XWiki dev team

1 0