Information for: DEVELOPERS   PARTNERS

Acquia Lightning experimental modules

Important

Acquia strongly recommends that you do not enable experimental modules on production websites.

Acquia Lightning includes one or more experimental modules for testing with your non-production websites. Experimental modules are provided for testing purposes, but aren’t yet fully supported.

For more information about experimental modules and their use in Drupal 8, see Experimental modules in Drupal 8 on Drupal.org.

Installing experimental modules

Although these modules aren’t fully supported, they’re packaged with Acquia Lightning. You must specifically select them during the distribution installation process, as follows:

  1. During the Choose extensions part of the installation process, in the Experimental section, select the I understand the potential risks of experimental modules check box. The Acquia Lightning installation application displays the available experimental modules.
  2. Select the check boxes for the experimental modules you want to include for use with your Acquia Lightning website.
  3. Click Continue.

The installation process will continue, and will copy the experimental modules you selected to your website.

Enabling experimental modules

To enable one or more Acquia Lightning experimental modules on your website, complete the following steps:

  1. Sign in as an administrator, and then click Extend in the admin toolbar.
  2. Find the Lightning (Experimental) section, and then select the check boxes for the experimental modules you want to use.
  3. Click Install.

Current experimental modules

The current version of Acquia Lightning contains the following experimental module:

  • Lightning Preview

    Lightning Preview (referred to as the Workspace Preview System or WPS) was marked as experimental for the following reasons:

    • It relies on the Multiversion module, which has the following issues:
      • The module doesn’t have a stable release.
      • The module modifies data structures.
      • After uninstalling the module, it leaves permanent changes in the database.
      • The module introduces the concept of a trash bin for deleted content, but deleted content isn’t actually removed from the database. Deleted content must be purged to be wiped from the database, but the user interface to purge content (provided by the Trash module) is still under development, making it impossible to delete content using the user interface.
    • URL aliases can produce unexpected results in several scenarios, including the following:
      • Pathauto is enabled, but rules aren’t configured for all content types
      • Overriding pathauto-generated aliases
      • Aliases for all entities other than nodes
    • In certain circumstances, blocks on block listing pages aren’t filtered as expected by the Workspace module.
    • The Workspace listing page displays a PHP warning caused by the Workspace module. Although this warning doesn’t signify a real problem, it can be alarming to some users.
    • The Author user-reference relationship implicit with all node entities is lost when replicating from workspace to workspace. This means that if User A creates Node B on the Live workspace, and that node is pulled to the Stage workspace, the Stage workspace will be unaware of the author, and will set the author to Anonymous. If an edit is then made to Node B on the Stage workspace, and that edit is pushed back to Live, Node B on the Live workspace will lose its author. For more information, see Issue #2817231 on Drupal.org.
    • You can’t resolve conflicts as expected. Users can delete the conflicting entity from one of the two workspaces to remove conflicts, but there is no interface for picking the winner and then keeping both versions.