[Deprecate] Remove Lightning Layout [#3298505]

Problem/Motivation

To facilitate keeping the distribution lightweight and because soon the Lightning Contrib modules will be EOL we need to remove Lightning Layout in a way that doesn't break an upgrade path and documents the modules removed in case site builders will want to manually add them to their composer.json file

On a default WxT installation the following components are enabled.

Lightning Layout (lightning_layout)        Enabled    8.x-2.11
-> Landing page (lightning_landing_page)   Enabled    8.x-2.11
-> Banner block (lightning_banner_block)   Disabled   8.x-2.11
-> Map block (lightning_map_block)           Disabled   8.x-2.11

Lighting Workflow module itself has the following module dependencies.

- drupal:block
- drupal:layout_builder
- drupal:options
- layout_library:layout_library
- layout_builder_restrictions:layout_builder_restrictions
- layout_builder_styles:layout_builder_styles
- lightning_core:lightning_core

Lightning Layout composer.json has the following module dependencies.

Importantly Panelizer directs most of its code to Layout Builder now although we do still need the bulk of the Layout modules.

"drupal/bg_image_formatter": "^1.10",
"drupal/ctools": "^3.6",
"drupal/entity_block": "^1.0",
"drupal/entity_browser_block": "^1.0",
"drupal/layout_builder_restrictions": "^2.7",
"drupal/layout_builder_st": "^1.0-alpha2",
"drupal/layout_builder_styles": "^1.0",
"drupal/layout_library": "^1.0-beta1",
"drupal/lightning_core": "4.* || 5.*",
"drupal/panelizer": "^4.1 || ^5.0",
"drupal/panels": "4.6 || 4.x-dev",
"drupal/simple_gmap": "^3.0"

Therefore the following entries are the ones that are removed from the distribution now.

"drupal/bg_image_formatter": "^1.10",
"drupal/panelizer": "^4.1 || ^5.0",
"drupal/simple_gmap": "^3.0"

Steps to reproduce

N/A

Proposed resolution

Uninstall the Lightning Layout module while maintaining an upgrade path.

Remaining tasks

N/A

User interface changes

Lightning Layout will no longer be presented in the admin menu.

API changes

N/A

Data model changes

Largely wxt_ext_layout and wxt_ext_landing_page which already exist now take over the configuration objects provided by lightning_layout and lightning_landing_page. The existing config_rewrites for the configuration objects have been updated and moved over to the base configuration under config/install.

Comments

Comment #1

20 July 2022 at 00:53

sylus created an issue. See original summary.

Comment #2

sylus CreditAttribution: sylus commented 20 July 2022 at 01:00

Issue summary:

View changes

Comment #3

20 July 2022 at 13:05

sylus committed b8f8458 on 4.3.x

Issue #3298505: [Deprecate] Remove Lightning Layout

Comment #4

sylus CreditAttribution: sylus commented 20 July 2022 at 13:08

Status:

Active

» Needs review

Comment #5

smulvih2

Canada 🍁

CreditAttribution: smulvih2 at OpenPlus, Cinder Systems Corp. commented 20 July 2022 at 23:29

I tested upgrading a site on the 4.3.0 branch to 4.3.x-dev. I can confirm the update hook ran as intended.

The following modules were uninstalled:

lightning_layout
lightning_banner_block
lightning_landing_page
lightning_map_block
lightning_workflow
lightning_scheduler

The following module was installed properly:

wxt_ext_workflow

On a fresh install of WxT 4.3.x-dev, the following config is confirmed working:

WxT Extend Workflow option is now available on install screen
Editorial workflow is installed and working as expected

Issues/Improvements:

Editorial workflow by default is only enabled for Landing page content type. Previously it was enabled on basic page by default. I think it would be good to enable for basic page by default.
Moderation history views config is provided in wxt_ext_workflow/config/dynamic. Not sure what the dynamic folder signifies, but it is not installing the view on fresh install of WxT. Maybe this config should be moved to /optional folder.

Great work @sylus, this really trims down the distro!

Comment #6

sylus CreditAttribution: sylus commented 20 July 2022 at 23:50

Thanks @smulvih!!!

So for the config/dynamic it was logic from lightning_workflow that I didn't want to just delete in case some people relied on it.

The logic that kicks it off and installs it is on a content type update:

function _wxt_ext_workflow_moderate_content_type(NodeTypeInterface $node_type, $workflow_id) {
  $workflow = Workflow::load($workflow_id);
  if (empty($workflow)) {
    return;
  }

  $plugin = $workflow->getTypePlugin();
  if ($plugin instanceof ContentModerationInterface) {
    $plugin->addEntityTypeAndBundle('node', $node_type->id());
    $workflow->save();

    // The moderation_history view depends on the existence of the
    // moderation_state base field, which is only defined once a content type
    // has been opted into moderation. Now that's done, so create the
    // moderation_history view if it doesn't already exist.
    if (Drupal::moduleHandler()->moduleExists('views')) {
      $view = View::load('moderation_history');

      if (empty($view)) {
        $values = file_get_contents(__DIR__ . '/config/dynamic/views.view.moderation_history.yml');
        $values = Yaml::decode($values);
        View::create($values)->save();
      }
    }
    // We need to rebuild all routes because Content Moderation needs to ensure
    // that edit forms load the latest revision, and that the moderation_history
    // view's routes are registered if needed.
    Drupal::service('router.builder')->rebuild();
  }
}