Lightning experimental modules

Lightning includes one or more experimental modules for testing with your non-production websites. Experimental modules are provided for testing purposes, but are not 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 not-fully-supported modules are included with Lightning, you must specifically select them during the distribution installation process, as follows:

  1. During the Choose extensions portion of the installation process, in the Experimental section, select the I understand the potential risks of experimental modules check box.
    The Lightning installation application displays the available experimental modules.
  2. Select the check boxes for the experimental modules that you want to include for use with your 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 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 that you want to use.
  3. Click Install.

Current experimental modules

The current version of Lightning contains the following experimental module:

  • Lightning Preview

    Lightning Preview (also 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 does not have a stable release.
      • The module modifies data structures.
      • After being uninstalled, the module leaves permanent changes in the database.
      • The module introduces the concept of a trash bin for deleted content, but deleted content is not actually removed from the database.
        Deleted content must also be purged to be completely wiped from the database, but the user interface to purge content (provided by the Trash module) is still under development, making it impossible to completely delete content using the user interface.
    • There are several scenarios where URL aliases can produce unexpected results, including the following:
      • Pathauto is enabled, but rules are not configured for all content types
      • Overriding pathauto generated aliases
      • Aliases for all entities other than nodes
    • In certain circumstances, blocks on block listing pages are not properly filtered by the Workspace module.
    • The Workspace listing page displays a PHP warning caused by the Workspace module. Although this warning does not signify a real problem, it can be alarming to some users.
    • The Author user-reference relationship that is 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. Furthermore, 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 also lose its author. For more information, see Issue #2817231 on Drupal.org.
    • There is no way to properly resolve conflicts. 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.

Add new comment

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.

Contact supportStill need assistance? Contact Acquia Support