Release Notes for XWiki Enterprise 1.9
Last modified by Thomas Mortagne on 2017/03/24
ContentsThe [toc] macro is a standalone macro and it cannot be used inline. Click on this message for details.
Release Notes for XWiki Enterprise 1.9
Final version of XWiki Enterprise 1.9 (Roadmap).Summary of changes since XWiki Enterprise 1.8.4
1 UI improvements
This version contains several improvements enhancing the usability and productivity on the wiki. Many thanks to Marta Gîrdea, who supervised the development of most of these improvements.Quick Jump to any Page navigation
It is now possible to jump from any page to any other page, using a modal dialog aided by a suggest-powered search. To start, just press
The modal dialog appears in the upper part of the page, and provides an input where the users must introduce the full name of the document they wish to view.
Start typing, and a suggest box will offer documents matching your search criterion (at most 10 documents are displayed for the moment). You can use this suggest as any other suggest box in XWiki: Up and Down move the selection, while Enter puts the currently selected value in the input.
To go to the selected page, just press Enter once more (this will open the document in view mode), or use one of the two buttons on the dialog, or press
Known issues:- Some of the shortcuts are not available on all systems and browsers (for example Chrome), and they inhibit some of the browser's native shortcuts (for example * The suggest box searches only on the document name. The next release will bring support for quick search by the document's title.
- The suggest box displays at most 10 documents. It should be possible to fetch more results when pressing the Down arrow after the last item.
- The edit button does not open form-based documents in the inline editing mode, but in the configured editor (wiki or WYSIWYG). This will probably be fixed in the next release.
- Typing just the name of a document, without the space, does not open a document in the current space, but in the view space. This will be fixed in the next release.
- It is not possible to enter more than one search term, separated by spaces, since the suggest searches for an exact match of the input string. This will be fixed once the overall REST-based search will be improved.
Faster Save and Continue using AJAX
Save and Continue doesn't refresh the page anymore, but makes an AJAX request to save the document. When pressing the Save & Continue button, or the
Since this action is performed using AJAX, much less processing is required on the server, and much less data is transfered between the server and the client. Before you even notice it, the message quickly transforms into a Saved notification, then fades away.
If an error occurs, you will be notified of the problem by a similar notification message:
As a related minor improvement, the Cancel button also behaves faster. Until now, it used to submit the entire form back to the server, although the data was discarded. Now, a simple request without any data is made, thus reducing the network traffic and the total response time.Improved Full Screen editing
XWiki had a full screen editing mode since 2007, when it was implemented thanks to a Google Summer of Code student. But it had several limitations that made it less useful than it should have been:- It had a particular look that didn't integrate well with the current skin
- It didn't have the action buttons allowing to save or preview the document
- It only worked with the main content editor, and only for wiki editing and the old WYSIWYG editor
- It had several minor bugs on different browsers
The editor will then take the entire available space, preserving only the toolbar and the action buttons. You can now save the document right from the full screen interface, and even take advantage of the new AJAX Save and Continue to quickly save and remain in full screen. To return to the normal view mode, push one of the two available buttons (one in the toolbar, and one next to the action buttons).
You can also edit in full screen any textarea in inline mode and in the object editor:
Other notable enhancements:- Improved support for browsers (tested in IE 6, 7 and 8, Chrome, Safari, Opera, and of course Firefox).
- Returning from Preview restores the maximized editor (and in most browsers except IE also when hitting the browser's Back button).
- Reuses the skin styles and integrates nicely with both Albatross and Toucan Current limitations:
- Because of some IE bugs, the button will appear after a short delay.
- Because of other IE bugs, when exiting full screen the edited field will be displayed a bit larger for about half a second.
- Because of some other IE bugs, when exiting full screen the window will be scrolled to the top of the document (this should be fixed in the next release).
New Live Table UI
The Live Table displaying all documents and all attachments in the Document Index page, as well as Users, Groups and Rights entries in the administration has been extended functionally and revamped from a design and user experience point of view. We have dropped the pseudo scroll bar in favor of a pagination mechanism. Columns are now sortable, which allows for example to sort the document or attachment index by date (ascending or descending).
This Live Table as been made a reusable component, available for applications developers to bind to their application business data in a breathe (just one velocity macro call is enough to create such a table). Read more in the JavaScript improvement section of the release notes, or checking out the live table developer documentation page, that includes a video introducing the table capabilities.Improved comments UI and functionality
The XWiki comments have also been improved, now allowing users to reply to existing comments, and have threaded discussions. Just click the "Reply" button to respond to any comment.
The comment form will appear under the replied comment.
The data will be sent via AJAX, to improve the continuity and speed.
Comment deletion is also done using AJAX requests:
Multiple attachment upload in one request
Uploading more than one file at once is difficult in web interfaces, since it is impossible to select more than one file in the dialog provided by the browser. It was even more difficult in XWiki, since the user had to scroll down to the attachment area, expand the upload form, browse for a file, submit, wait a lot for the file to be uploaded, and then go back and do all the steps again, several times. We made things a bit easier, by allowing to insert all the wanted files in the form (as distinct file input field), then submit only once. A first improvement is that the upload form is now expanded by default. You will notice the Add another file and the red X buttons. You can add as many fields as you like (keeping in mind that the wiki has a limit on the total size of the upload data), and you can later remove any field wrongly selected. Pressing the Cancel button will restore the form to its initial state, with only one empty file field.
Another minor improvement related to attachments is that the icons indicating the type of an attachment have been updated to use the Silk set, and more file types visually indicated by specific icons are covered.
New UI for the Class and Object editors
The Class and Object editors have been revamped to improve the usability. For the object editor, the accordion has been replaced with expandable tree-like structures, with quick buttons for editing only one object at a time, and for deleting an object (which is performed using AJAX, thus much faster, without loosing the context).
To start editing properties, click on the object's name to expand it, click again to collapse it. The same principle be used to expand/collapse classes and object properties (note that for collapsing properties you will have to click on the (-) sign next to the property name, since clicking on the property name itself gives focus to the corresponding input field). Using this tree, several objects can be opened at a time, so when you have to edit two objects at the same time, you don't have to continuously move from one object to the other.
A feature that was implemented a long time ago, but remained hidden in the UI until now, is the ability to edit just one object. With the new UI, this feature, which greatly improves the speed when dealing with documents with many objects, is exposed as an intuitive button next to the Delete Object button. Combined with the FullScreen editing support for textarea properties, and with the AJAX Save and Continue, editing large properties inside the wiki is much more productive.
The class editor also underwent major changes. The first thing to notice is that when editing a document that doesn't define a class yet, a list of existing classes is displayed instead of the blank screen from previous versions.
Notice the way classes are grouped by the space they belong to. The same grouping was also applied for the Add Object panel in the object editor, and the Class Switcher panel in the class editor. This separation makes it easier to find the desired class in a wiki with many classes.
Like with the object editor, the class editor also changed the accordion with a tree-like structure. It is now possible to keep more than one property opened at a time, and to collapse and expand only the needed metaproperties.
A major inconvenience with the old class editor was that it was hard to determine the type of a property, without looking carefully at its meta-properties. Now, this is fixed both by listing the type next to the name, and by using a suggestive icon.
Another improvement is that non-functional and rarely used metaproperties have been removed to reduce the perceived complexity of configuring a class, at least until their support will be improved (tooltip, customDisplay, unmodifiable, contenttype). The number property is also hidden when JavaScript is enabled, since the property reordering can now be performed using simple Drag and Drop.
Improved toolbar in the wiki editor
The toolbar for the wiki editing mode has been improved, adding support for the xwiki/2.0 syntax, adding more buttons, and replacing the icons with images from the Silk icon set.
Current limitations:- When switching the syntax from 1.0 to 2.0, before reloading the document the toolbar for the old syntax is used. This should be fixed in a future release.
Preliminary support for Autosave
A feature frequently asked for is the ability to autosave documents, so that when a problem occurs after a long editing session, at least all but the most recent changes should be recovered. While more changes in the underlying structure of XWiki are needed in order to implement it properly, for the moment we have a preliminary implementation for this feature. When editing in the wiki mode, you will notice a checkbox allowing to enable the Autosave feature:
By default, a document version will be saved every 5 minutes, but this can be changed by editing the number:
Current limitations:- The autosave only works with the wiki editor; support for the new WYSIWYG will be added shortly.
- Autosave actually saves the document, creating real versions, so anybody can see the created drafts.
- Each autosave creates a distinct version, so a long editing session with a short autosave interval will create lots of minor versions.
- A new version will be saved even if no changes occurred since the last autosave.
2 PDF export improvements
Some important features were added and several issues addressed related to the PDF export feature:- PDFs now contain a cover page and a table of contents page.
- Changed the default font to FreeSerif, as it looks better on paper.
- Scaled images preserve the custom dimensions in PDFs also, with the exception that the aspect ratio is always preserved to be the same as the original image, and:
- Images are prevented from overflowing the paper, by being automatically scaled down to the maximum available space.
- The export works when running the container as a user with no home directory, since now the cache is correctly created in the temporary directory.
- A few style changes.
3 JavaScript improvements
We started to cleanup and improve our JavaScript widgets and APIs, to make the code smaller, more modular, more easy to understand, to have a common architecture.New notifications
XWiki now sends custom events when certain actions occur:- * * Other events will be added in the future as needed. A complete documentation for those events and their memo data is available on the JavaScript API page on XWiki's platform development guide.
Usage example
Prototype.js is the framework recommended for XWiki development. It eases listening for and sending event using the Event "class" and three new methods for the document object. To listen for a custom event, do:document.observe("xwiki:dom:loaded", function() {
alert("The document has loaded");
});
alert("The document has loaded");
});
document.fire("xwiki:mymodule:myaction", {"someParam": true, "anotherOne": myObject});
New reusable components
To support the new UI features, the following new components have been added:- * * * *
Cleanup
We started cleaning up the old JavaScript code, replacing custom code with methods provided by Prototype.js, removing unused code, applying a common codestyle, introducing a standard naming convention, introducing a standard directory policy, etc. The first components affected are the Suggest, the behavior for the form action buttons, and the XWiki object itself.Deprecation strategy
We added a4 Switched to UTF-8 as the default encoding
The default encoding of XWiki has changed to UTF-8 to better integrate in the multi-national web. If you want to go back to the old encoding, you must edit The default HSQLDB database bundled with the standalone XWiki distributions are not affected by the encoding, so they should work after an upgrade without any changes.5 Mailsender improvements
The SMTP setting (username, password, server port, and extra Javamail properties which allow to enable SSL) are easier to configure (now accessible in the Administration -> General tab), and are by default visible in the wiki. Previously, they had to be manually added to the XWiki.XWikiPreferences class. These settings are also used with the registration confirmation email.
Thanks to Paul Guralivu and Lilianne Blaze for providing patches.6 New Office Importer feature: document splitting
The Office Importer application now allows to split documents into multiple wiki pages during import.
7 XWiki 2.0 Syntax is enabled by default
This means that new pages are created using the XWiki 2.0 Syntax and thus benefit from the new WYSIWYG editor too. See Migration notes for more details.8 Other improvements
- Document syntax can be changed from the WYSIWYG editor.
- Upgraded to Groovy 1.6.3.
- Group Sheets are now using the Livetable widget.
- Upgrade to Jython 2.5rc3 (used in the Code macro since we're using Pygments for pretty-displaying).
- Simple Users don't see technical spaces anymore.
- New behavior for Velocity Macro for New Lines and White space (see Migration notes for more details).
- WYSIWYG improvement: Indenting multiple items at once in a list
Known issues
Backward Compatibility and Migration Notes
You can return to no cleaning by setting core.velocity.filter=none in xwiki.properties file.
