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

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:

#-# [Since 12.9RC1]
#-# 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

More details

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.

#-# [Since 12.5RC1]
#-# 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

This option default value changed between 12.5RC1 and 12.5. The default value was WIKI in 12.5RC1 and is now FARM since 12.5

Name Strategies for XWiki 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.

Liked pages are displayed in a LiveTable

Liked pages are now displayed in a live table in the user profile.

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.

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.

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.

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)

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

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.

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.

Maven exclusions support

Support for Maven dependency <exclusions> has (finally) been added.

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.

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.

Tags:
   

Get Connected