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: #3392968: $this->photoswipeAssetManager->attach() conflicts with twig_field_value "|field_value"

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

Comments

Anybody created an issue. See original summary.

anybody’s picture

Issue summary: View changes
andyf’s picture

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...)

anybody’s picture

@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.

andyf’s picture

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?