Last modified by Thomas Mortagne on 2017/03/24

Show last authors
1 #startfloatingbox()
2 *Contents*
3 #toc ("2" "4" "")
4 #endfloatingbox()
5
6 1 Release Notes for XWiki Enterprise 1.9 Milestone 2
7
8 Second milestone of the XWiki Enterprise 1.9 version ([Roadmap>enterprise:Main.Roadmap]).
9
10 1.1 New and Noteworthy
11
12 At a glance (see below for details):
13 * Lots of improvements and new features in the new WYSIWYG editor
14 * Lots of UI improvements
15 * Lots of improvements and bugfixes in the rendering engine and the syntax converter
16 * A new LiveTable widget
17 * Improvements for the PDF export
18 * Started cleanup and refactoring of the JavaScript APIs
19 * Switched to UTF-8 as the default encoding
20 * Upgraded to Velocity 1.6.2
21 * New Dutch translation, improved French, German, Spanish, Romanian, Russian translation.
22 * Mailsender improvements
23
24 1.1.1 1 UI improvements
25
26 1.9.M2 contains several improvements enhancing the usability and productivity on the wiki. These features are under development, so they might still have buggy or limited behaviors. These quirks will be fixed in the next releases.
27
28 Many thanks to Marta Gîrdea, who supervised the development of most of these improvements.
29
30 1.1.1.1 Quick ~~Jump to any Page~~ navigation
31 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 <tt>Ctrl+G</tt> or <tt>Meta+G</tt> (the meta key is the one between <tt>Alt</tt> and <tt>Ctrl</tt>, usually with a Windows logo on it, or the one with the Apple logo on Macs), or click on the text from the ~~Quick Links~~ panel.
32
33 {image:jmp1.png}
34
35 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.
36
37 {image:jmp2.png}
38
39 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.
40
41 {image:jmp3.png}
42
43 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 <tt>Ctrl+V</tt> or <tt>Meta+V</tt> to view, and <tt>Ctrl+E</tt> or <tt>Meta+E</tt> to edit the target document. ~~Esc~~ simply closes the dialog without changing the current page.
44
45 {image:jmp4.png}
46
47 {image:jmp5.png}
48
49 Known issues:
50 - 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 <tt>Ctrl+G</tt> on Firefox normally searches for the next occurrence of the searched term, but <tt>F3</tt> does the same thing).
51 - The suggest box searches only on the document name. The next release will bring support for quick search by the document's title.
52 - 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.
53 - 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.
54 - 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.
55 - 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.
56
57 1.1.1.1 Faster ~~Save and Continue~~ using AJAX
58 Save and Continue doesn't refresh the page anymore, but makes an AJAX request to save the document. When pressing the ~~Save &amp; Continue~~ button, or the <tt>Alt+Shift+S</tt> shortcut, a message appears at the bottom of the screen, indicating that the document is being saved.
59
60 {image:sac1.png}
61
62 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.
63
64 {image:sac2.png}
65
66 {image:sac4.png}
67
68 If an error occurs, you will be notified of the problem by a similar notification message:
69
70 {image:sac3.png}
71
72 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.
73
74 1.1.1.1 Improved ~~Full Screen~~ editing
75
76 XWiki had a full screen editing mode since 2007, when it was implemented thanks to a [Google Summer of Code>dev:GoogleSummerOfCode.WebHome] student. But it had several limitations that made it less useful than it should have been:
77 - It had a particular look that didn't integrate well with the current skin
78 - It didn't have the action buttons allowing to save or preview the document
79 - It only worked with the main content editor, and only for wiki editing and the old WYSIWYG editor
80 - It had several minor bugs on different browsers
81
82 {image:fs0.png|The old FullScreen editor}
83
84 This feature was completely rewritten, addressing all of these issues. To start editing in full screen, press the button available in the toolbars of the wiki editor and the WYSIWYG editors:
85
86 {image:fs1.png}
87
88 {image:fs2.png}
89
90 {image:fs3.png}
91
92 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).
93
94 {image:fs4.png}
95
96 You can also edit in full screen any textarea in inline mode and in the object editor:
97
98 {image:fs5.png}
99
100 Other notable enhancements:
101 - Improved support for browsers (tested in IE 6, 7 and 8, Chrome, Safari, Opera, and of course Firefox).
102 - Returning from Preview restores the maximized editor (and in most browsers except IE also when hitting the browser's Back button).
103 - Reuses the skin styles and integrates nicely with both Albatross and Toucan
104
105 Current limitations:
106 - Because of some IE bugs, the button will appear after a short delay.
107 - Because of other IE bugs, when exiting full screen the edited field will be displayed a bit larger for about half a second.
108 - 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).
109
110 1.1.1.1 New ~~Live Table~~ UI
111
112 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).
113
114 {image:livetable1.png}
115
116 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>platform:DevGuide.LiveTable], that includes a video introducing the table capabilities.
117
118 1.1.1.1 Improved ~~comments~~ UI and functionality
119
120 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.
121
122 {image:comm1.png}
123
124 The comment form will appear under the replied comment.
125
126 {image:comm2.png}
127
128 The data will be sent via AJAX, to improve the continuity and speed.
129
130 {image:comm3.png}
131
132 Comment deletion is also done using AJAX requests:
133
134 {image:comm4.png}
135
136 {image:comm5.png}
137
138 1.1.1.1 Multiple ~~attachment~~ upload in one request
139 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.
140
141 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.
142
143 {image:att2.png}
144 {image:att3.png}
145
146 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.
147
148 {image:att1.png}
149
150 1.1.1.1 New UI for the ~~Class and Object editors~~
151
152 The Class and Object editors have been revamped to improve the usability.
153
154 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).
155
156 {image:obj1.png}
157
158 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.
159
160 {image:obj2.png}
161
162 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.
163
164 {image:obj3.png}
165
166 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.
167
168 {image:class1.png}
169
170 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.
171
172 {image:class2.png}
173
174 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.
175
176 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.
177
178 {image:class4.png}
179
180 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.
181
182 {image:class3.png}
183
184 1.1.1.1 Improved ~~toolbar in the wiki editor~~
185 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.
186
187 {image:wt1.png}
188
189 {image:wt2.png}
190
191 Current limitations:
192 - 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.
193
194 1.1.1.1 Preliminary support for ~~Autosave~~
195
196 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.
197
198 When editing in the wiki mode, you will notice a checkbox allowing to enable the Autosave feature:
199
200 {image:as1.png}
201
202 {image:as2.png}
203
204 By default, a document version will be saved every 5 minutes, but this can be changed by editing the number:
205
206 {image:as3.png}
207
208 Current limitations:
209 - The autosave only works with the wiki editor; support for the new WYSIWYG will be added shortly.
210 - Autosave actually saves the document, creating real versions, so anybody can see the created drafts.
211 - Each autosave creates a distinct version, so a long editing session with a short autosave interval will create lots of minor versions.
212 - A new version will be saved even if no changes occurred since the last autosave.
213
214 1.1.1 2 PDF export improvements
215
216 1.9M2 adds a few important features and addresses several issues related to the PDF export feature:
217 - PDFs now contain a ~~cover page~~ and a ~~table of contents~~ page.
218 {image:pdf1.png}
219 {image:pdf2.png}
220 - Changed the default font to FreeSerif, as it looks better on paper.
221 {image:pdf3.png}
222 - 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:
223 - Images are prevented from overflowing the paper, by being automatically scaled down to the maximum available space.
224 - 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.
225 - A few style changes.
226
227 1.1.1 3 JavaScript improvements
228
229 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.
230
231 1.1.1.1 New ~~notifications~~
232
233 XWiki now sends custom events when certain actions occur:
234 - <tt>xwiki:dom:loading</tt> and <tt>xwiki:dom:loaded</tt> when the document is loaded. The former is fired right after the DOM is loaded, and is supposed to be the signal that marks the start of the page's lifecycle. This is the event that should start all scripts making important DOM changes that other scripts should see. The latter is sent right after it, and is supposed to be the signal that triggers most of the scripts loaded at startup. *It is recommended to bind startup scripts to this event* instead of <tt>window.load</tt> or <tt>document.dom:loaded</tt>.
235 - <tt>xwiki:docextra:activated</tt> and <tt>xwiki:docextra:loaded</tt> when loading tabs for the document extra data (attachments, comments, history, etc.). The former is called each time one of the tabs is selected. The latter is called only for the first activation, when the corresponding data has arrived.
236 - <tt>xwiki:actions:cancel</tt>, <tt>xwiki:actions:preview</tt> and <tt>xwiki:actions:save</tt> are sent when pushing one of the form action buttons. As extra information the second parameter sent to event listeners contains the original click event (if any, and which can be stopped to prevent the action from completing), the form being submitted, and a boolean <tt>continue</tt> parameter for the <tt>xwiki:actions:save</tt> event, to distinguish between ~~Save and View~~ and ~~Save and Continue~~.
237 Other events will be added in the future as needed.
238
239 A complete documentation for those events and their memo data is available on [the JavaScript API page on XWiki's platform development guide>platform:DevGuide.JavaScriptAPI].
240
241 1.1.1.1.1 Usage example
242
243 [Prototype.js>http://www.prototypejs.org/] is the framework recommended for XWiki development. It eases listening for and sending event using the [Event>http://www.prototypejs.org/api/event] "class" and three new methods for the [document>http://www.prototypejs.org/api/document] object.
244
245 To listen for a custom event, do:
246 {code}
247 document.observe("xwiki:dom:loaded", function() {
248 alert("The document has loaded");
249 });
250 {code}
251
252 Prototype allows more complicated tricks, like binding to a custom object and registering additional parameters using [bindAsEventListener>http://www.prototypejs.org/api/function/bindAsEventListener].
253
254 To send an event, do:
255 {code}
256 document.fire("xwiki:mymodule:myaction", {"someParam": true, "anotherOne": myObject});
257 {code}
258
259 1.1.1.1 New reusable ~~components~~
260
261 To support the new UI features, the following new components have been added:
262 - <tt>XWiki.widgets.ModalPopup</tt>: a simple modal dialog with no default content, which is supposed to be used as the base class for notifications. See [the source code>http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/widgets/modalPopup.js] for details.
263 - <tt>XWiki.actionButtons.AjaxSaveAndContinue</tt>: as the name says, this is responsible for the improved save and continue functionality. It responds to the <tt>xwiki:actions:save</tt> event with the <tt>continue</tt> flag set to true. See [the source code>http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/actionButtons.js] for details.
264 - <tt>XWiki.widgets.Suggest</tt>: this is the old suggest, for which thorough cleanup work has started. See [the source code>http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/suggest/ajaxSuggest.js] for details.
265 - <tt>XWiki.widgets.JumpToPage</tt>: the first subclass of the <tt>ModalPopup</tt>, it is responsible for the new ~~Jump to Page~~ feature. See [the source code>http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/widgets/jumpToPage.js] for details.
266 - <tt>XWiki.widgets.LiveTable</tt>: the JavaScript class supporting the AJAX Live Table front-end mechanisms, used currently by the Document Index UIs and administration Users, Groups and Rights UIs. You can browse [the source code>http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js] for details, or [read the livetable velocity macro documentation>platform:DevGuide.LiveTable] for a out-of-the-box macro that can map a live table to an XWiki class of objects.
267
268 1.1.1.1 Cleanup
269 We started cleaning up the old JavaScript code, replacing custom code with methods provided by [Prototype.js>http://www.prototypejs.org/], 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.
270
271 1.1.1.1 ~~Deprecation~~ strategy
272 We added a <tt>compatibility.js</tt> script file that contains deprecated code and aliases from old methods/classes to the corresponding new ones.
273
274 1.1.1 4 Switched to UTF-8 as the default encoding
275 Starting with 1.9M2, 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 <tt>WEB-INF/xwiki.cfg</tt> and <tt>WEB-INF/web.xml</tt> and change the encoding parameters.
276
277 #warning("If you were using a database with character encodings in ISO-8859-1, you will have to either switch XWiki back to ISO-8859-1, or convert your databases to UTF8.")
278
279 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.
280
281 1.1.1 5 Mailsender improvements
282 In 1.9M2 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 -&gt; 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.
283
284 {image:smtp.png}
285
286 Thanks to Guralivu Paul and Lilanne Blaze for providing patches.
287
288
289
290 1.1 Known issues
291
292 * [Bugs we know about>https://jira.xwiki.org/secure/IssueNavigator.jspa?reset=true&&type=1&pid=10010&resolution=-1&sorter/field=updated&sorter/order=DESC]
293
294 1.1 Common Migration notes
295
296 #warning("The default encoding was changed from ISO-8859-1 to UTF-8. If you were using the old default encoding and a database using character encodings, you must convert the database data, too, or switch XWiki back to the old encoding")
297 #warning("If you're running in a multiwiki setup you'll also need to define the property <tt>xwiki.store.migration.databases=all</tt> to your <tt>xwiki.cfg</tt> file or explicitly name all databases to be migrated as in <tt>xwiki.store.migration.databases=db1,db2,...</tt>.")
298
299 You may also want to [import the default wiki XAR>Main.Download] in order to benefit from improvements listed above.
300
301 #warning("Always make sure you compare your <tt>xwiki.cfg</tt> file with the newest version since some configuration parameters were added. Of note, you should add <tt>xwiki.store.migration=1</tt> so that XWiki will attempt to automatically migrate your current database to the new schema. Make sure you backup your Database before doing anything.")

Get Connected