Changes Report
Easily edit the app title
The title of an application created with App Within Minutes can now be edited from the last step of the application wizard. The application title is displayed on the application home page, on the applications panel and live table, on the breadcrumb, etc. See the App Within Minutes documentation for more information.
Macro Parameter Groups
The WYSIWYG editor is now able to group macro parameters as indicated in the macro descriptor. Currently only the Include Macro has grouped parameters. There can be two types of macro parameter groups:
- groups of related parameters (e.g. reference and type in the case of the Include Macro)
- groups of alternative parameters (only one parameter in the group should be set); this type of groups are displayed using tabs (e.g. "Resource" and "Page" in the case of the Include Macro)
See the CKEditor Integration documentation for more information.
Macro Parameter Pickers
The WYSIWYG editor is now able to load pickers for macro parameters based on their type. The binding between macro parameter types and the associated pickers is done on the server side (check the templates/html_displayer folder inside the XWiki WAR). For instance, if you have a wiki-based rendering macro, you can set the type of a macro parameter to "org.xwiki.model.reference.DocumentReference" in order to get a document picker when inserting or editing your macro from the WYSIWYG editor. Check the CKEditor Integration documentation for more information.
Inline editing of title for Box Macro
The title of the Box macro is now editable directly in the WYSIWYG editor, as it already was for its content.
Page Count for Data Types
The Data Types live table now shows the number of pages that use each data type.
Default Class Sheet Shows Object Count
The default class sheet now shows the number of objects (of the current type) found on each page.
Simplified Page Rename
The Rename Page dialog has been simplified:
- the "Preserve Children" option is visible only if the page to rename has child pages.
- the "Update Links" option is now visible only to advanced users. For simple users the back-links are always updated.
Inline editing of macro parameters
It is now possible to allow inline editing of macro parameters when using the WYSIWYG editor. In order to do that, we reuse the same principle as for allowing inline editing of content in macro: you have to specify the type of the macro parameter by using @PropertyDisplayType on the parameter, and then you have to specify the metadata to put where the macro parameter is used in the UI, by using the AbstractMacro#getNonGeneratedContentMetaData("parameterName") method.
Allow to disable authentication security mechanism
In order to avoid any problem in the future with the Authentication Security that we recently introduced, we created a dedicated UI to easily disable/enable this mechanism. Note that disabling the authentication security will also clear the information about login failures, which might unlock users in case of problems.
Notifications Performances
The performance of the Notifications feature has been improved by implementing some in-memory caching of events for the users and more importantly its impact on the rest of the XWiki instance has been drastically reduced by limiting the resource allocated to it. This is a stopgap solution while waiting for a future redesign of the Notifications feature for better scalability for large volumes.
Backlink support improvements
The following areas containing backlinks are now refactored when renaming a page:
- Images and attachments in wiki content
- Wiki content in TextArea XObjects when the content is marked as containing markup
Improved Date Filter
The look & feel of the live table date filter has been improved. You can check it on the Page Index.
Warning when Deleting Users with Script Right
Wiki administrators are now warned when they are about to delete users that have Script or Programming Rights, if there are pages that were last modified by these users. Check out the Administration Application documentation for more information.
Allow to force save in case of editing conflict
Starting with XWiki 11.2RC1 we introduced a mechanism for detecting edit conflict during the edition of a page.
We introduced in this release a new window in case of editing conflict. You now have two main choices:
- force save the page: in that case you will override saved while you were editing the page; they are not really lost though since they might be retrieved in the previous version of the page.
- reload the editor: in that case your changes will be lost and the editor will be reloaded with the last version saved.
We display the diff between the version you're trying to save and the last version that has been saved, so you can copy some changes made and reapply them if you like. Note that you can also simply cancel the save and go back to the editor to make changes before trying again to save. You can click on the arrow of each action to have a quick description of what it actually means.
Inline editing of wikimacro parameters
It is now possible to use a dedicated macro to output a wikimacro parameter so that it can be edited inline from the WYSIWYG editor.
You can use for instance the following macro code:
{{wikimacroparameter name="foo" /}}
The value of the macro parameter will be displayed and will be editable inline from the WYSIWYG editor.
Wikimacro Content Type
It is now possible to specify the content type of a wikimacro when creating it. A new field Macro Content Type is available for this purpose.
The Macro content type field will be used in the future to propose the right editor depending on the content type. It currently proposes two values: WIKI to specify that the content should be edited with an editor for wiki content, or UNKNOWN to specify it should be edited with a plain text editor.
Note that it also accepts any kind of custom Java values, such as java.util.List<java.lang.String>.
If left blank, the default value would be UNKWOWN. This is also the value for macro created before 11.5RC1.
New Async macro
A new Async macro was introduce to make easy to execute asynchronous and/or cached wiki content. See Async Macro for more details.
HTML Diff Script Service
A new script service is available to compute the visual changes between two HTML fragments:
#set ($htmlDiff = $services.diff.html.unified($previousHTML, $nextHTML))
#if ($htmlDiff == '')
No changes.
#elseif ("$!htmlDiff" == '')
Failed to compute the changes.
#else
$htmlDiff
#end
</div>
Checkout the Diff Module's documentation for more information.
Add a new binding for wikimacro
A new binding has been introduced for Wikimacro, the different information of the wikimacro are then available through wikimacro. The old binding xcontext.macro remains but is considered as deprecated and shouldn't be used anymore.
One important change in this binding concerns the parameters: those are now available through wikimacro.parameters.xxx (instead of xcontext.macro.params.xxx), and their values are now automatically converted to the type given in the WikiMacroParameterClass.
Live Table Actions use the Icon Theme
The default Actions column from the Live Table is now using the configured Icon Theme for the action icons. See the Live Table macro documentation for more information.
Templates improvements
- It's now possible to indicate that a template should be executed only once in the same request.
- It's now possible to enabled asynchronous rendering and caching for a template.
See Template Module for more details.
User Directory Configuration Live Preview
The User Directory configuration has a new setting to show/hide disabled users. Disabled users are hidden by default. The users live table is now updated automatically when the configuration is modified.
Live storage of job log
JobStatus#getLog() is now deprecated and replaced by JobStatus#getLogTail() which provide more streamed APIs to navigate in the log.
Live storage of job log
The log of the job is now stored on the filesystem next to the statux.xml in live:
- very low memory footprint
- it's possible to see the log even of the status is not yet serialized
Propertly support long paths in filesystem store
The way the filesystem store organizes the data has been completely modified to fix a bug with some languages. There should not be any issue with the size of the path anymore.