|field_value removes attached libraries from $build

Created on 10 October 2023, 9 months ago
Updated 28 February 2024, 4 months ago

Problem/Motivation

If there are libraries attached on $build then |field_value removes them.

For example, with photoswipe formatter active on an image field, using
{{ content.field_image|field_value }}
removes the photoswipe library from the render array, as it's placed on the first level.


  /**
   * Twig filter callback: Only return a field's value(s).
   *
   * @param array|null $build
   *   Render array of a field.
   *
   * @return array
   *   Array of render array(s) of field value(s). If $build is not the render
   *   array of a field, NULL is returned.
   */
  public function getFieldValue($build) {

    if (!$this->isFieldRenderArray($build)) {
      return NULL;
    }

    $elements = Element::children($build);
    if (empty($elements)) {
      return NULL;
    }

    $items = [];
    foreach ($elements as $delta) {
      $items[$delta] = $build[$delta];
    }

    return $items;
  }

https://git.drupalcode.org/project/twig_field_value/-/blob/8.x-1.x/src/T...

Steps to reproduce

We ran into it here: πŸ› $this->photoswipeAssetManager->attach() conflicts with twig_field_value "|field_value" Fixed

But I think it happens whenever something like

$build['#attached'][...]

exists.

Proposed resolution

Discuss if this is expected and acceptable or a bug
Find a way to keep the attached libraries, for example by moving them to a child element?

Remaining tasks

User interface changes

API changes

Data model changes

πŸ› Bug report
Status

Active

Version

2.0

Component

Code

Created by

πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

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

Comments & Activities

  • Issue created by @Anybody
  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica
  • πŸ‡¬πŸ‡§United Kingdom AndyF

    Not sure if this belongs in a new ticket, but as far as I can tell it also doesn't propagate any attached cacheability metadata that's directly on the field element either, which surprised me given the explicit mention of cacheability on the project page. (I wonder if I'm missing something...)

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    @AndyF: Indeed that should go into a separate issue. But you may want to set this issue related and vice-versa.
    40,508 sites report using this module, so I think it's important to check that.

  • πŸ‡¬πŸ‡§United Kingdom AndyF

    Thanks @Anybody! I'm happy to make a new ticket but thought I'd just gently push back once (: the cacheability metadata might explicitly be for the contents of #attached, so fixing only #attached might not give you correctly working attachments. Maybe it makes sense to deal with them both in one go?

Production build 0.69.0 2024