Synchronous mail resending
There's now an API to resend emails synchronously (we only had an asynchronous API before). This is useful when resending large amounts of emails which would require a lot of memory since all emails would be loaded from disk and put in the resending memory queue.
Forms styling handle HTML5 inputs
HTML5 inputs (color, date, datetime-local, email, number, search, tel and time) are now consistent with older input types (text and password) in the Flamingo Skin. They are all compatible with the Vertical Forms Guidelines.
Improved Jump to Page
The Jump to Page modal (Ctrl+G) has been updated to use the new page picker which fixes the keyboard navigation and improves the display of page suggestions (page title and location are now shown).
Mail Resender Scheduler Job
It's now possible to run a Scheduler Job to resend automatically emails that were prepared successfully but that were not sent (for example if the XWiki JVM crashed before they could be sent).
Syntax Variants
A Rendering Syntax Type can now have "variants" which represent variations of the base syntax. For example markdown+github is the GitHub-Flavored Markdown Syntax, markdown+commonmark is the CommonMark Markdown Syntax, etc. It used to be a best practice to use the + character to separate variants. It's now official and part of the API with some constructors and getters. For example:
assertThat(syntaxType.getVariants(), contains("variant1", "variant2"));
Remove User's default_language xproperty
Remove the default_language xproperty that could be set in XWikiUsers xobjects since it was not working (since a very long time ago, possibly 1.1M3) and it was not a very useful and used xproperty.
More locale-oriented APIs
We deprecated Document#getTranslationList() in favor of the new Document#getTranslationLocales() so if you have Velocity scripts using $doc.translationList you'll notice a deprecation warning in the server logs which you can avoid by using $doc.translationLocales instead.
We also added XWiki#getAvailableLocales() so you can now replace
with $xwiki.availableLocales in your Velocity scripts.
More consistent menu icons
Updated class and object edit menu icons to make them more consistent with other places like the document tree viewer. The missing Annotations menu icon was also added.
Deprecated Mail Script Services
The $services.mailsender and $services.mailstorage Script Service entry points have been deprecated in favor of $services.mail.sender and $services.mail.storage.
SuperAdmin and Guest configuration
The configuration properties for the Guest and SuperaAdmin virtual users can now be overridden. This is achieved by modifying the xwiki.properties file.
For example:
user.preferences.guest.editor = Text
user.preferences.guest.displayHiddenDocuments = 1
Configuration option to disable in-place editing
A new configuration option is available in xwiki.properties to disable the in-place editing of plain wiki pages.
#-# Indicate if the XWiki documents should be edited in-place, without leaving the view mode, whenever possible (e.g. if
#-# the default edit mode for that document and the preferred editor both support in-place editing). When enabled,
#-# clicking on the document Edit button makes the document title and content editable in-place, without leaving the view
#-# mode. When disabled, clicking on the document Edit button loads the default (stand-alone) edit mode for that
#-# document.
#-#
#-# The default is:
# edit.document.inPlaceEditing.enabled = true
Toggle Rendered Diff Context
You can now use the "Show context" toggle button to show / hide all the unmodified parts of the page rendered content when comparing two versions of a wiki page from its history. Check the user guide for more information.
SuperAdmin sees hidden pages
The Super Admin user now sees hidden pages.
User Avatar macro with user picker
When inserting the User Avatar macro from the WYSIWYG editor you can now select the target user with a user picker.
Solr multi-core
It's now possible to "reserve" a dedicated Solr core for the specific storage needs of an extension. See Solr Search Application for more details.
JMX Monitor of Apache DBCP and Hibernate
JMX Monitoring of Apache DBCP and Hibernate are now enabled by default.
Allow to inject Javascript/CSS in Notification displayers
It is now possible to use the Skin Extension Plugin in the custom Notification displayers: this might allow to use custom javascript for the notifications.
Comment form not displayed by default
The comment form is now hidden by default. This allows improving the loading performance of XWiki pages and makes the UI less cluttered.
A button allows you to display the comment form when you need to add a new comment.
Allow to unregister components in Extension Mojo
If you use some XWiki Maven Build Tools such as the Extension Plugin or the Packager Plugin, we introduced a new parameter disabledComponents in those mojos to allow to unregister some components during their execution.
A typical usage of such parameter can be to prevent the execution of a MandatoryDocumentInitializer, for example:
<disabledComponents>
<disabledComponent>
<type>com.xpn.xwiki.doc.MandatoryDocumentInitializer</type>
<role>XWiki.XWikiServerXwiki</role>
</disabledComponent>
</disabledComponents>
</configuration>
Non-minified Javascript
Non-minified versions of JavaScript files are now also bundled by default in XWiki. This makes it much simpler to debug JavaScript issues in production. Just look for the non-minified (source) code using the developer tools provided by the browser. Since the minified code indicates the source map and the source map indicates the source file, the browser ends up loading all 3 (when the developer tools are open). If you can't find the source code then you can force the browser to load it by reloading the current page with ?minify=false in the URL.
Support targeting groups in Notifications
Using a TargetableEvent in the Notification API now allows to target also Groups and not only Users anymore.
Add a Solr store for ratings
It is now possible to store Ratings information in a Solr core: this should improve the scalability of the extension. Please note that the migration of data from one store to another is not yet supported.
On MySQL, the character set utf8mb4 is now set on the main database for new instances installed via our debian packages.
Simplified Unliking
A modal was previously asking for confirmation for removing a like on a page. This has been removed to make it simpler and more consistent: liking and unliking are now both immediate actions.
VFS content type
It's now possible to explicitly indicate the Content-Type to return with the HTTP response containing the file. See VFS API for more details.
View source in viewers menu section
The View source link has been moved to the Viewers menu sub-section of Other actions menu, to be consistent.
Mail Address HTML Displayer
An HTML Displayer for email addresses (i.e. objects of type javax.mail.internet.InternetAddress) has been added (it displays the email address obfuscated if obfuscation is on). It's not used anywhere but can be called. Scripting example:
#set ($email = $services.user.properties.email)
{{html}}
$services.display.html.display('javax.mail.internet.InternetAddress', $email)
{{/html}}
{{/velocity}}
Mail Address Conversion
There's now a Converter to convert from a String to an InternetAddress and vice versa. It's especially important since we've modified the User API's get/setEmail() to use an InternetAddress. This allows using Velocity scripts that call APIs accepting an InternetAddress by passing a string. For example:
Mentions explained on the tips
The use of the mentions in WYSIWYG editor autocompletion is now explained on the tips.
New UIXP for the viewers menu section
A new UI Extension Point has been created to be able to extend the Viewers sub-menu of "other options" menu.
Ability to hide macro parameters in WYSIWYG
Thanks to the introduction of a new @ProperyDisplayHidden annotation that can be placed on Macro parameter classes, it's now possible to hide the parameter inside the WYSIWYG's Macro editor. This is useful to hide complex parameters that should only be used in wiki edit mode for example.
Example:
{
...
/**
* @param type the type of the reference
* @since 3.4M1
*/
@PropertyDescription("the type of the reference")
@PropertyGroup("stringReference")
@PropertyAdvanced
// Marking it as Display Hidden because it's complex and we don't want to confuse our users.
@PropertyDisplayHidden
public void setType(EntityType type)
{
this.type = type;
}
/**
* @param page the reference of the page to include
* @since 10.6RC1
*/
@PropertyDescription("The reference of the page to include")
@PropertyDisplayType(PageReference.class)
@PropertyFeature("reference")
// Display hidden because we don't want to confuse our users by proposing two ways to enter the reference to
// include and ATM we don't have a picker for PageReference types and we do have a picker for EntityReference string
// one so we choose to keep the other one visible and hide this one. We're keeping the property so that we don't
// break backward compatibility when using the macro in wiki edit mode.
@PropertyDisplayHidden
public void setPage(String page)
{
this.reference = page;
this.type = EntityType.PAGE;
}
}
Enable Strict Mode for JSX
XWiki can now be configured to parse and minify wiki-based JavaScript skin extensions (JSX) using strict mode. This is disabled by default but you can enable it from xwiki.properties using:
Check the skin extension documentation for more information.
Mail Obfuscation APIs
There are now 2 new APIs related to Email Address Obfuscation:
- API to get whether or not email addresses should be obfuscated. Scripting example:#if ($services.mail.general.shouldObfuscate())
... - API to obfuscate an email address. Scripting example:$services.mail.general.obfuscate('[email protected]')
Social category in Administration
A new Social category has been added in Administration to gather all configurations related to social features. Those items were previously all in the Other category.
New experimental event store
A new Solr based event store has been introduced. It's still disabled by default (will be enabled as soon as the user notification use case is fully refactored to use it) and meant to be used more and more to replace the current Hibernate based event and event status store.
View Likes in viewers menu section
The menu item for viewing Likes information has been moved to Viewers sub-section of the other options menu, for consistency.
Configuration modifications
There's now a setProperties() API to modify ConfigurationSource properties. Scripting example:
import org.xwiki.configuration.*
def cs = services.component.getInstance(ConfigurationSource.class, 'mailsend')
cs.setProperties(['host' : 'localhost'])
println cs.getProperty('host')
{{/groovy}}
New Comment button
The comments section at the bottom of pages used to have the comment editor visible. There's now a Comment button to click when wanting to add a comment. This was done for 3 reasons:
- For consistency with other actions where you have to click a button to do them (annotate, edit, create, etc).
- It makes the UI a bit less cluttered and avoids focusing the attention on comments which was very visible, especially since we moved to using the WYSIWYG editor by default in comments.
- It also improves the loading performance of XWiki pages since the editor doesn't need to be loaded when viewing pages
Changing Page Syntax from Wiki Editor
Changing the page syntax from the Wiki Editor has suffered some updates:
- the style of the syntax conversion confirmation modal has been improved to be consistent with the other modals we use in XWiki
- the syntax conversion is not saved right away anymore but when you save the Wiki Editor; canceling the Wiki Editor will also cancel any unsaved syntax change
- XWiki will warn you when the syntax conversion is not supported
Checkout the Page Editing documentation for additional information.
Configuration permissions
It's now possible to implement permission checking for ConfigurationSource properties, to decide who has the rights to view or modify them. To implement this check for your ConfigurationSource component, you need to implement the ConfigurationSourceAuthorization component role.
Changing Page Syntax from WYSIWYG Editor
Changing the page syntax from the WYSIWYG Editor has suffered some updates:
- we don't reload the entire page anymore but only the WYSIWYG editor instance (in order to take into account the new syntax); the WYSIWYG editor has to be reloaded because the page syntax affects core editor configuration that cannot be changed on the fly (see the CKEditor Integration documentation for more information);
- the WYSIWYG editor is always reloaded when changing the syntax, no matter whether you choose to convert the content or not (for the reason mentioned above)
- the editing mode (Source vs. WYSIWYG) is preserved on reload
- if the new syntax doesn't support WYSIWYG editing (e.g. because it doesn't have a renderer) then the WYSIWYG editor will force the Source mode after the reload and disable the WYSIWYG mode, warning the user about the current limitation.
Checkout the Page Editing documentation for additional information.
Changing Page Syntax from View
Changing the page syntax from the Information tab, while viewing the page, has suffered some updates:
- XWiki will now propose to convert the page content and meta data to the new syntax, if the conversion is supported, but note that the changes will be saved only after saving the syntax
- if the syntax conversion is not supported then XWiki will warn the user about the limitation
- the page title and content are reloaded in order to allow the user to preview the effect of the syntax change before saving the new syntax
- canceling the syntax change will also reload the page title and content
URLTool improvement
A new toURL(String) has been added to the Velocity $urltool to convert a String to an URL object.
The Delete section of the Content category of the global administration is now hidden when the recycle bin is not activated.
Export Target XWiki Version
The Export administration section has a new option named "Target XWiki version" that is useful if you need to generate a XAR that is compatible with an older version of XWiki. For instance, if you need to import the generated XAR in an XWiki version older than 12.0 then you should set "Target XWiki version" to "Below 12.0".
Finer configuration of the "can skip the recycle bin" feature
Allowing Advanced user to skip the recycle bin can now be configured on three locations:
- In the global administration of the current wiki
- In the global administration of the main wiki
- In xwiki.properties (see the property details below)
If the default value is found on one location, the next one is tried. If no value is found, the recycle bin skipping is not activated.
Details of the configuration on xwiki.properties:
#-# Indicates whether skipping the recycle bin when deleting pages is allowed for Advanced users.
#-# It is disabled by default.
#-# This setting is only used if the wiki has a recycle bin activated (xwiki.recyclebin=1 in xwiki.cfg).
#-# This setting can be overloaded:
#-# * By the main wiki in the Refactoring.Code.RefactoringConfigurationClass class of the
#-# Refactoring.Code.RefactoringConfiguration document of the main wiki.
#-# * By sub-wikis in the Refactoring.Code.RefactoringConfigurationClass class of the
#-# Refactoring.Code.RefactoringConfiguration document of the sub-wikis (itself overloading the main wiki's
#-# configuration).
#-#
#-# The default value is:
# refactoring.isRecycleBinSkippingActivated = false
Rendered Changes Using Image Data
A change in the source URL, or reference, of an image displayed on a wiki page, where the image itself is not modified, doesn't appear in the rendered diff anymore when comparing the revisions of that page.
Select the Wiki Home Page with the new Page Picker
The wiki descriptor administration section is now using the new page picker for the home page field.
Velocity Object Tool
Provides various methods to manipulate objects from Velocity. For example to check for null:
#if ($objecttool.isNull($result))
...
#else
...
#end
Notifications Redesign
The start of a Notifications re-architecture has been started in order to improve performances. The current implementation is computing changes for a given user on the fly, when asked. This has the advantage of being very light to save new events but the computation is cost when displaying notifications (even though there's a cache). It doesn't scale well when there are a lot of events and users. Thus we've started a redesign where we compute and store the notifications for each user, when a new event is triggered.
To enable the new feature, edit your xwiki.properties file and set the notifications.eventPreFilteringEnabled property to true.
This feature is currently EXPERIMENTAL and should not be tried in production.
#-# Enabling this option will make user notifications be filtered and stored when the event is generated
#-# instead of filtered each time they are displayed.
#-#
#-# The default is :
# notifications.eventPreFilteringEnabled = false
