XAR export improvement
A new version of the XAR format has been introduced to improve the way attachment history is exported:
- it's streamable (exporting an attachment history used to require a lot of memory)
- version with identical content are de-duplicated (for example the history contain the current version so with the old format it's stored in both the current version and the history)
This new format is used by default to store deleted documents but not yet in the XAR export administration, should be enabled in 12.0 final.
Disable deprecation warnings
A new property property logging.deprecated.enabled xwiki.properties allow controlling if warning related to use of deprecated APIs should be logged or not. See Logging Module for more details.
Emoji Support Enabled in WYSIWYG Editor
You can now insert emoji from the WYSIWYG editor using the dedicated toolbar button. This is done using the Emoji CKEditor Plugin. See the CKEditor Integration for more information.
UIXP for Content Footer
A new UI Extension Point has been introduced to allow to inject content in the footer of a page content. This UIXP is already used to display tags and authors at the bottom of the page, but any extension can now use it for other kind of contents.
Solr Debian package
A new xwiki-solr-core Debian package is now provided, which automatically registers an xwiki core in a standalone Solr instance (provided it uses the standard setup).
MariaDB Debian package
A new MariaDB-oriented Debian package has been introduced.
Mention summary on the notification
A summary of the text surrounding a mention can now be displayed in the notification UI for mentions.
The generation and display of the mention summary can be disabled in the mentions section of the administration.
Use LibreOffice with a pool of process
The Office Importer Application configuration has changed to allow using a pool of process in case of internally managed office server.
The property openoffice.serverPort is deprecated in favor of openoffice.serverPorts which takes a list of ports: each port will be use to start a dedicated office process. This will allow to use the process in parallel and avoid blocking users when several operations involving office are performed at the same time (imports and exports).
Replace Jobs with threads to handle mentions asynchronously
The user mention analysis, to detect new mentions and send notifications to target users, is now done by a pool of threads.
Configuration
A configuration option to define the size of the thread pool is available in xwiki.properties.
#-# The detection and notification for the user mentions in created or edited content is done asynchronously
#-# by a pool of consumers.
#-# This properties controls the size of this pool.
#-#
#-# The default is :
# mentions.poolSize = 1
JMX Monitoring
An object named org.xwiki:name=mentions is provided and provides two attributes and one operation:
- QueueSize: Displays the number of elements (created or updated pages) to be analysed.
- ThreadNumber: The number the threads in the thread pool.
- clearQueue(): Removes all the elements in the queue. Warning: By doing so some pages will not be analysed and some mentions will be missed. To be used carefully.
Solr dedicated core improvements
- The base schema now provide a type "text_general" and associated helpers which follow the Solr standard "text_general" type, "a general text field that has reasonable, generic cross-language defaults: it tokenizes with StandardTokenizer, removes stop words from case-insensitive 'stopwords.txt' (empty by default), and down cases. At query time only, it also applies synonyms". This is the easiest way to insert full text search friendly fields in your schema.
- A Solr core initializer can now decide if the data should be stored as cached data or not
Allow to define a default XAR entry type when building XARs
Added the option <defaultEntryType>myEntryType</defaultEntryType> in the configuration of the XAR plugin when building XAR artifacts.
When defined, the default enty type will be applied to every entry not being overridden through the <entries>...</entries> list in the plugin configuration.
See the Maven XAR Plugin documentation for more information about this feature.
Allow to force-download attachments based on their mimetype
It is now possible to decide which attachments should be always downloaded based on their mimetypes: until now two properties (attachments.download.whitelist and attachments.download.blacklist) were allowing to control the display of some attachments for security reasons, but those properties are not able to control the behaviour of attachments added by a user with programming rights.
A new property has been added to allow force-download any attachment, whoever added it:
#-# Define the kind of attachment that you always want to be downloaded and never displayed inline.
#-# By default this list is empty, but you can specify a list of mime-types (coma separated list of values) which
#-# should be always downloaded no matter who attached them or what is the whitelist/blacklist configuration.
#-#
#-# The distinction with the blacklist configuration above is that the blacklist won't affect file attached by a user
#-# with programming rights, while this configuration affect any attachment.
# attachment.download.forceDownload=
Targetable Events disregard Inclusive filters
We changed slightly the behaviour of Notification Filters for Targetable Events. These type of events are not concerned anymore by inclusive filters. It means that these events will be received by users even if the location where the event has been sent to is not watched by the user. This is useful for example for Mentions to allow receiving Mentions notifications from any location without needing to watch it.
Note that the exclusive filters are still honored by targetable events: this allows users to keep not receiving notifications on the chosen locations.
Async Rendering improvements
- Saving/restoring the context action is now supported.
- When saving the context document but not the wiki, the context wiki should be restored from the document.
Option to skip the recycle bin
There's now an administration option to allow advanced users to choose whether deleted pages are sent to the recycle bin or not.
To do so, search for the "Delete" section in the Administration and set "can skip the recycle bin" to Yes. The default value is No to avoid unwanted loss of data.
User Mentions API upgraded
The User Mentions API has been upgraded to support new use-cases, such as sending notification to different kind of actors. This new API is a first step toward the mention of users from remote wikis, or to the mention of groups. A new event has also been introduced, making it easier to listen and react to mentions from new modules.
Increased timeout for Office
The default timeout to import office documents has been increased for 30 seconds to 1 minute, in order to avoid errors when importing large documents taking more than 30 seconds.
HTTPS extensions repositories
The extensions repositories are now accessed through HTTPS instead of HTTP.
Like information are displayed in a live table
People liking a page are now displayed in a live table.
Ignore extension dependencies
It's now possible to force Extension Manager to ignore a set of dependencies that might cause problem or simply be useless. See Dependencies for more details.
Async Rendering improvements
When the context document is selected in an asynchronous rendering execution it's also added to "used" entities. That means that if that document is modified the cache result will be invalidated automatically.
In-place edit for object properties
You can enable in-place editing for an existing XWiki application, if you're using the Vertical Form layout, by editing the application sheet (the page used to display the application entries) and operating 2 changes:
- Load the JavaScript code required for in-place editing and define some variables:#set ($discard = $xwiki.jsfx.use('uicomponents/edit/editableProperty.js', {
'forceSkinAction': true,
'language': $xcontext.locale
}))
#set ($object = $doc.getObject('Path.To.YourClass'))
#set ($editing = $xcontext.action == 'edit') - Add some meta data to the definition term (dt) elements that wrap the field names:<dt #if (!$editing && $hasEdit)
class="editableProperty"
data-property="$escapetool.xml($services.model.serialize($object.getProperty('yourProperty').reference))"
data-property-type="object"#end>
The result should look like this:
Liked pages are displayed in a LiveTable
Liked pages are now displayed in a live table in the user profile.
Translate page while editing in-place
If multilingual is on and the current page is not translated in the current user interface language then editing in-place will load the original page. If you wish to translate the page then you just need to click on the Translate button. Whatever changes you do next will be saved to the translated page.
Provide a new API for Ratings
The Ratings API has been rewritten in order to support new use-cases, such as performing rates on different kinds of elements (not only pages) but also using different scales for ratings. This works leads to breaking the existing Ratings API: the Rating Application is automatically supported (you just have to update the extension) but if you used directly the Ratings API for some custom extensions you might be interested about this small guide for migrating it.
UIXP to publish RequireJS modules
We added a new UIXP to support extending the global RequireJS configuration. This allows you to publish a RequireJS module that others can use without knowing its path.
In-place section editing
You can now edit in-place the sections of a plain wiki page, if the WYSIWYG editor is the preferred content editor. Unlike the old section editing, this allows you to edit the entire page, so that you don't loose the context, but it places the focus in the right section so that you don't have to scroll the page.
Live macro rendering when editing in-place
The new in-place edit mode runs the JavaScript code required by rendering macros, producing a true WYSIWYG editing experience.
Locale (Language) Picker
The locale (language) picker that is used in the Localization administration section has been converted to a generic picker that you can reuse.
Solr multi-core improvements
Solr core are now created at runtime (for embedded Solr setup) so it's not needed to restart after installing an extension which require a custom Solr core.
This version introduces org.xwiki.search.solrAbstractSolrCoreInitializer which provide a lot of helpers for creating/migrating Solr cores. See more details on Solr Search Application.
Selection preserved when switching between WYSIWYG and Source
We upgraded the CKEditor Integration extension and the new version comes with a long-awaited feature: the selection / caret is preserved when switching between WYSIWYG and Source area. This makes it really easy to:
- check the wiki syntax that corresponds to the current WYSIWYG selection
- check how the selected text from the Source area is rendered when switching back to WYSIWYG
Simplify usage of Include macro
It's now simpler to use the Include and Display macros. Some complex and never-used parameters have been removed from the WYISWYG editor's macro dialog UI. Specifically, the page parameter is now hidden and for the Include macro the context parameter is now deprecated (and thus hidden). This also allows to display a single way to choose the reference of the included/displayed page and to ensure that users use the provided page picker.
Object editor does not save automatically on object creation/deletion anymore
The behaviour of the Object editor changed to be more consistent: the changes performed like object addition or deletion are now only saved when clicking on the save button.
Note that for developers we introduced new saving parameters to allow adding and deleting objects on a single save.
User Properties
There's now an API to modify user properties. Scripting example:
#set ($props = $services.user.getProperties("testuser"))
#set ($discard = $props.setEmail('[email protected]'))
#set ($discard = $props.setFirstName('John'))
#set ($discard = $props.save())
{{/velocity}}
Default object sheet supports in-place editing
If you create a new application on top of XWiki following the manual FAQ tutorial you'll notice that starting with this version the application entries are editable in-place, from view mode. You can achieve the same thing for an existing application by copying and adjusting the code of the XWiki.ObjectSheet page over your existing sheet. Just make sure you update the name of the class used in the copied code.
Reliable page renames
A new low-level API have been introduced in the XWikiStoreInterface that allows performing an atomic rename of documents: this should improve efficiency of refactoring operations and allows better rollback in case of problems. However since it's a new unstable API concerning a sensitive feature we provided a switch-off configuration for it in xwiki.properties in case of trouble:
#-# Indicate to use the old implementation based on copy and delete, or the new implementation
#-# using an atomic operation on database (which allows efficient rollback).
#-# This property aims at being removed in the future once the atomic rename has been validated
#-# to work 100% fine. Only use it if you are facing an issue with the move/rename features.
#-#
#-# The default value is:
# refactoring.rename.useAtomicRename = true
Allow IndexerJob to be triggered wiki per wiki on farms
Until now when the configuration solr.synchronizeAtStartup was set to true, the indexer job was trigger for the whole farm of wiki, which could have been resource consuming for the machine. We added a new configuration for the Solr Search API that allows to trigger the index job only when sub-wikis are starting (default behaviour now) or for the whole farm as it was done before. You can find the following configuration in xwiki.properties.
#-# Indicates which wiki synchronization to perform when the "solr.synchronizeAtStartup" property is set to true.
#-# Two modes are available:
#-# - WIKI: indicate that the synchronization is performed when each wiki is accessed for the first time.
#-# - FARM: indicate that the synchronization is performed once for the full farm when XWiki is started.
#-# For large farms and in order to spread the machine's indexing load, the WIKI value is recommended, especially if
#-# some wikis are not used.
#-# The default is:
# solr.synchronizeAtStartupMode=FARM
Allow to define the pool size of a GroupedJob
It is now possible to configure the pool of threads to be used for grouped jobs. To provide that configuration you need to declare a new component that implements org.xwiki.job.GroupedJobInitializer and whose method getId matches the JobGroupPath of the GroupedJob. You will be able to define the size of the pool of threads to be used for those jobs and the default priority of the threads.
Note that the hierarchy of the JobGroupPath can be used to define the same configuration for a whole hierarchy of GroupedJobs.
New global configurations have been also added in xwiki.properties related to this feature:
#-# [Since 12.5RC1]
#-# The maximum number of entries to put in cache for the GroupedJobInitializer components.
#-# The default is 100.
# job.groupedJobInitializerCacheSize=100
#-# [Since 12.5RC1]
#-# The thread keep-alive time in milliseconds for the single job executor.
#-# This value defines how long a thread can be idle before being terminated by the executor.
#-# The default value is 60000 for 60 000ms.
# job.singleJobThreadKeepAliveTime=60000
#-# [Since 12.5RC1]
#-# The thread keep-alive time in milliseconds for the grouped job executors.
#-# This value defines how long a thread can be idle before being terminated by an executor.
#-# The default value is 60000 for 60 000ms.
# job.groupedJobThreadKeepAliveTime=60000
Switch to source while editing in-place
You can now switch to source while editing in-place the content of a page.
Prefixed Remote Solr core name
Solr cores are now prefixed by default with xwiki_ (except for the main core that is used for search, which is named xwiki).
