Changes Report

Last modified by Vincent Massol on 2017/05/31

Simplified WYSIWYG Editor Toolbar

The WYSIWYG Editor toolbar has been simplified by grouping and reorganizing the buttons, removing those that were used very rarely. Here's a summary of the changes we did:

  • the Format drop down is now the first item on the left side
  • Strike, Underline, Subscript, Superscript and Remove Format have been grouped in a drop down menu
  • the list buttons have been grouped in a dedicated drop down menu
  • the Unlink button was moved from the main toolbar to the floating toolbar that is shown when you click on a link
  • we enabled the image floating toolbar, visible when an image is selected
  • Horizontal Line, Special Character and Import from Office have been grouped in a new Insert drop down menu
  • we moved the Insert/Edit Macro button to the Insert drop down menu, where we also added shortcuts for common macros
  • we removed the Copy, Cut and Paste buttons from the toolbar. They are available in the context menu
  • we removed the Copy Formatting button, as we don't encourage the usage of in-line styles
  • we removed the Language drop down because it was causing confusion with the wiki page language

As a result the toolbar now takes a single line by default.

Rich editor integration on comments and annotations

Comments and annotations are now edited using the preferred content editor specified in the user profile. They were previously edited using only a plain text editor. The WYSIWYG editor is now supported and it allows for easy insertion of mentions in comments and annotations.

In-place edit for plain wiki pages

You can now edit plain wiki pages in-place, if the WYSIWYG editor is the preferred content editor.

Extensible User Profile Menu

The user profile menu is now extensible. You can add new entries to the user menu using the org.xwiki.plaftorm.user.profile.menu User Interface Extension Point (UIXP).

Maven exclusions support

Support for Maven dependency <exclusions> has (finally) been added. It means that, like in Maven, an excluded transitive dependency won't be downloaded when you install an extension. XWiki used to totally skip the whole concept of exclusion.

Support of Mentions

XWiki Standard now support by default User Mentions. You can mention a user by two ways: either by typing "@" in the WYSIWYG editor as displayed in the screenshot, or by inserting a Mention macro. Mentioning a user will have for effect to send a notification to that user, with the link to the page or place (can be a comment or an object) mentioning her/him.

New local extensions index

A new Solr based index of all the extensions available on the configured searchable repositories has been introduced. It's updated regularly (every hours in that version) and it also recommends compatible versions to install so that the default list you get in the Extension Manager UI only contains extensions which are not already installed and for which the install/upgrade should work in your instance.

New event store and prefiltering by default

12.6 introduces the use of the new event store and pre-filtering of events by default.

Events are now stored in a Solr core (they are also still stored in the old database store for now as a retro compatibility measure).

User notifications are now associated to each user when they are generated and not when they are requested. This means that gathering is always fast and that the filtering of events is using the preference of the user at the moment the event was generated so modifying your preference will only affect new events. The pre-filtering processing is also asynchronous and done in a low priority thread to not impact the farm so there might be a delay between the action and the appearance of the related notification in the notification list in a very active wiki with a lot of users.

Even if it was implemented along the course of 12.x it's still the first time that this is enabled for most users so don't hesitate to report any notification related issue to https://jira.xwiki.org/projects/XWIKI. If you hit a blocker bug you can go back to:

  • post filtering of event using the property notifications.eventPrefilteringEnabled in xwiki.properties
  • use only the database store by disabling the new one using the property eventstream.store.enabled in xwiki.properties

Extension Manager improvements

  • Extension without any associated file are now supported (Extension#getType() return null or empty string in this case)
  • Maven modules of type pom or dependencies of type pom produce Extension with empty type
  • In general Extension Manager now have a better support for Maven dependencies of type different from the default type (this produce extensions with different ids on Extension Manager side)

In-place edit for application entries

The entries of a newly-created AppWithinMinutes application are now editable in-place. For existing applications you will need to edit the application and go through the application wizard so that the application sheet is re-generated, but be aware that you might loose you customizations in the process.

New experimental event store

The storage of the events is now asynchronous, they used to slow down every stored event before (document modification, blog post, etc.) since each of them was producing a blocking database insert query.

This version introduce the complete support of the new event store in the UI notifications (mail notification support is planned for 12.6). Pre filtering is not new and was introduced in 12.1 but it's part of a new architecture to manage user notifications.

The main differences with the current default behavior are:

  • events are associated with users right when they happen and the association is stored, this means changing your notification configuration won't have any impact on already stored user notifications
  • gathering of notifications associated with users is very fast because it's a simple request to get the list of already calculated associations
  • it will be possible to introduce much more advanced event filters since they won't be required to be translated into database queries anymore

The new event store and the pre filtering are disabled by default. You can enable both of these options in xwiki.properties configuration file using the following:

notifications.eventPreFilteringEnabled = true
eventstream.store.enabled=true

This won't disable the old event store which will be used as a fallback when something is not supported yet by the new store especially regarding the support of notification post filters which is not yet fully complete.

Page Likes

The Page Like feature allows users to Like pages. By default, this application adds a small button at the bottom of the pages, allowing users to like them. It also displays the total number of likes for the page. Notifications are sent when pages are Liked and it's possible to see your own liked pages or who liked a page.

Name Strategies for Wiki Pages

A new Name Strategy Module has been introduced to allow administrators to have more control on the wiki page names.
The name strategies allow to validate and transform page names before they are created to comply with a defined policy.
The transformation of page name is performed before page creations through XWiki UI, while page name validation is performed at the API level.

Two strategies have been implemented as a start for this new feature:
  - the Character Replacement Strategy: allows to define forbidden characters in page names, and replacement characters for each. If no replacement characters are defined, the forbidden characters are simply removed from page names.
  - the Slug Name Strategy: allows to normalize page names to remove any special characters and accents.

By default, the Character Replacement Strategy is used with "/" (slash) and "\" (backslash) as forbidden characters, without defined characters. Only the page name transformation is enabled, page name validation is still experimental and should be used with caution. 

This new feature can be setup in the Administration in Editing > Name Strategies.

New User API

We now have a new User API (see the History section to understand the various ways to get properties for a User and which APIs to use and which ones shouldn't be used).

Example from Java:

@Inject
private UserResolver<UserReference> userResolver;
...
User currentUser = userResolver.resolve(UserReference.CURRENT_USER_REFERENCE);
boolean isActive = currentUser.isActive()

Example from Velocity:

$services.user.resolveUser('').isActive()

Extended Page Information

The information tab displayed at the bottom of each page has been extended with more information such as the original page locale, the current page locale, the available page translations, the page syntax and whether the page is hidden or not. Moreover, some of the page information is now editable in-place, from view mode.

Velocity upgrade to 2.2

After 9 years Velocity finally got a update. You can see a detailed changelog on https://velocity.apache.org/engine/2.2/changes.html but here are the important new things from XWiki script authors:

  • Allow expressions inside []: $foo[$bar + 1]
  • New strategy for reference boolean evaluation:
    • return false for a null object
    • return its value for a Boolean object, or the result of the getAsBoolean() method if it exists.
    • if directive.if.emptycheck is false (true by default), stop here and return true.
    • check for emptiness:
      • return whether an array is empty.
      • return whether isEmpty() is false (covers String and all Collection classes).
      • return whether length() is zero (covers CharSequence classes other than String).
      • returns whether size() is zero.
      • return whether a Number strictly equals zero.
    • check for emptiness after explicit conversion methods:
      • return whether the result of getAsString() is empty (and false for a null result) if it exists.
      • return whether the result of getAsNumber() strictly equals zero (and false for a null result) if it exists.
  • Support $array.empty, as for $list.empty
  • Fix parsing of $obj._method()
  • Have #foreach honnor the Closeable interface on the iterator
  • Fix regression: #set<tab>left-paren no longer valid grammar
  • Fix parser for '$map{key}' text rendering
  • #foreach should work over any Iterable class
  • Method arguments can now be expressions
  • Fixed quotes escaping so that doubling single quotes only works when enclosing quotes are single quotes (and same behaviour for double quotes)
  • Add ability to specify default values for macro parameters, e.g.; #macro(foo bar=1)
  • Add ability to place line comments next to macro parameter definitions
  • Block directives no longer require parenthesis so #@foo #end is now allowed. Also, brackets now work with Block Macros so #{@foo}bar#end works
  • Default block for empty loops: #foreach($i in []) loop block #else empty #end
  • Rendering of arrays should display their content, as for lists
  • New generic $collectiontool which replaces and enhances the former SortTool
  • New generic $logtool

Get Connected