[beta6] ⚠️ Merge footer_top into footer component

Created on 27 January 2024, 10 months ago
Updated 6 April 2024, 7 months ago

Problem/Motivation

footer_menu & footer_top components were split from footer component on year ago, many months before the addition of links setting type: 🐛 [beta1]⚠️ Avoid manually injected HTML in footer component Fixed

Those 2 components have:

  • a single links prop (setting)
  • no slots (fields)
  • no variant for footer_top, 1 variants for footer_bottom

So, having them a separate components seems to be... useless.

Proposed resolution

So, in footer component, why not replacing:

  • the top slot by a links prop
  • the content slot by a links prop (and a select prop for the variants?)

Remaining tasks

Before doing the change, let's consider why we may wan to keep those components separated: page.html.twig
When we hardcode the call to a component from this template, we make its slots "configurable", because these are the regions where we put the blocks, but not its props. So menus will not be available anymore.

API changes

Breaking, that's why we target beta 6 (which is embedding all the breaking changes about links type)

📌 Task
Status

Fixed

Version

1.0

Component

Code

Created by

🇫🇷France pdureau Paris

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @pdureau
  • 🇫🇷France pdureau Paris

    Before doing the change, let's consider why we may wan to keep those components separated: page.html.twig
    When we hardcode the call to a component from this template, we make its slots "configurable", because these are the regions where we put the blocks, but not its props. So menus will not be available anymore.

    there is a solution cooking on UI SUite USWDS theme:

    On theme settings:

      protected function menuSettingsForm($title, $value) {
        $all_menus = $this->entityTypeManager->getStorage('menu')->loadMultiple();
        $menus = [
          "" => "(None)",
        ];
        foreach ($all_menus as $id => $menu) {
          $menus[$id] = $menu->label();
        }
        asort($menus);
        return [
          '#type' => 'select',
          '#title' => $title,
          '#options' => $menus,
          '#default_value' => $value,
        ];
      }

    it looks like the links settings type, but simpler.

    On page preprocess:

    protected function addRawMenu(array $variables, string $variable, string $menu_id): array {
    $parameters = new MenuTreeParameters();
    // Empty parameters because not configurable.
    $tree = $this->menuLinkTree->load($menu_id, $parameters);
    $manipulators = [
    ['callable' => 'menu.default_tree_manipulators:checkAccess'],
    ['callable' => 'menu.default_tree_manipulators:generateIndexAndSort'],
    ];
    $tree = $this->menuLinkTree->transform($tree, $manipulators);
    $tree = $this->menuLinkTree->build($tree);
    if (!isset($tree["#items"])) {
    return $variables;
    }
    if (isset($tree["#cache"])) {
    $variables["#cache"] = array_merge($variables["#cache"] ?? [], $tree["#cache"]);
    }
    $variables[$variable] = LinksSettingType::normalize($tree["#items"]);
    return $variables;
    }

    once again, ike the links settings type, but simple.

  • Assigned to pdureau
  • Status changed to Postponed 10 months ago
  • 🇫🇷France pdureau Paris

    Let's wait the work is merged on USWDS before borrowing.

  • Status changed to Needs work 8 months ago
  • 🇫🇷France pdureau Paris

    "Footer top" done.

    Do we do "Footer Menu" ?

  • Status changed to Needs review 8 months ago
  • 🇫🇷France pdureau Paris

    finally, we don't do footer_menu

  • Issue was unassigned.
  • Status changed to RTBC 8 months ago
    • pdureau committed 2a755643 on 1.0.x
      Issue #3417519 by pdureau: Merge footer_top into footer component
      
  • Status changed to Fixed 8 months ago
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024