🇺🇸United States @rpearl

rpearl → created an issue.

I am playing with this module to see if it would fit my needs and I came across this bug. Once thing I noticed is the options for syncing are very similar so I started doing some debugging. As long as I checked "Synchronize Webform submission with the created content in edition?", this would run through the process of syncing webform and node with the node field of "field_submission_id". Within the fields for managing the conversion, you just need to make sure you are mapping that field with the forms sid value. This allowed me to save new field data based on the saving of the previous form submission.

In the yml file for the Webform Content Creator I also made sure the config was saving correctly. So in the config there is a line for:

...
sync_content: true
...

As long as this was true it was working just fine for me.

I also came across this issue with Gin 4.0.4 and Field Group 4.0.0-alpha1. The "Mark group as required if it contains required fields." checkbox option did not make any difference. I created this patch which gets around the issue and forces the required mark regardless of this option. There should be a better way to do this, but at least this patch would allow me to ensure that the horizontal tabs were always marked correctly (aka, I always want to mark the group required if there are required fields).

I'm not sure if it has something to do with the custom block "FootnotesGroupBlock.php" within this code:

    ...
    if ($entity = $this->getContextValue('entity')) {
      assert($entity instanceof EntityInterface);
      // Using placeholder rendering requires providing the cache keys.
      $build['#cache']['keys'] = array_merge(['footnotes_group'], $entity->getCacheTagsToInvalidate());
      $metadata = $metadata->merge(CacheableMetadata::createFromObject($entity));
    }

    $metadata->applyTo($build);
   ...

Looks like it is taking the metadata from the entity and this is what the block ends up using versus the setting within the footnotes_group block. This block is also utilizing `#lazy_builder` so that could have something to do with it as well? I got around this temporarily by forcing the max age of this block to be set to "0":

    $metadata->applyTo($build);
    $build['#cache']['max-age'] = 0; // Forcing the max-age after the entity metadata is applied.

    if ($this->configuration['group_via_js']) {
      $build['#attached']['library'][] = 'footnotes/footnotes.group_block_via_js';
    }

Once I did this the footnotes_group block is loading every time, but it is basically ignoring the settings within the block. Currently the users settings on the footnote block isn't changing the cache setting for the block. The OP's possible solution might actually work as a better fix, or maybe also check the timing of when the users settings for caching actually get applied versus the entity settings?

rpearl → created an issue.

Re-roll of the patch for Drupal 10.4.x.

Here is an example of how I was able to get this done using the theme_preprocess_views_view_field hook:

1. In the view fields, add a "Custom Text" block where you need the breadcrumb trail to be rendered.
2. Within this field I added some custom text advising that this field is overridden within the theme file, and also updated the Administrative title to "Custom Breadcrumb". This helps with troubleshooting or finding where this was overridden long after you forgot you did this.
3. Add similar code below (replacing values of your own):

/**
 * Overriding the views fields.
 *
 * @param $variables
 *   An array of variables to pass to the theme template.
 *
 * @return void
 *   Nothing returned.
 */
function YOUR_THEME_NAME_preprocess_views_view_field(&$variables): void {
  if ($variables['view']->getDisplay()->display['id'] === 'YOUR_VIEW_DISPLAY_ID'
    && $variables['field']->options['id'] === 'nothing'
  ) {
    // Overriding the 'Custom Text' value to render the breadcrumb.
    $entity = $variables['row']->_entity;
    $routeName = $entity->toUrl()->getRouteName();
    $routeParameters = $entity->toUrl()->getRouteParameters();
    $route = Drupal::service('router.route_provider')->getRouteByName($routeName);
    $routeMatch = new Drupal\Core\Routing\RouteMatch($routeName, $route, $routeParameters, $routeParameters);
    $renderable = Drupal::service('breadcrumb')->build($routeMatch)->toRenderable();

    $variables['output'] = $renderable;
  }
}

I created a temporary patch that trims the font_path values for local file references: trim_EOLs.patch. This allowed me to not mess with any other code and just get it working for the time being, but this module will need some refactoring on how it handles the config values and there will need to be removal of the php80 references to make this fully working and compatible with D10.

Also finding issues when trying to use the Field Group module along with this. You can't group items in an accordion or tabs, they just won't work. Probably should be another ticket, but because of things like this, the resolution/patch for this current issue may need to be thought about.

Has anyone used Field Group with this module to use the admin styles for grouping? I think this latest update to RC removed all of the admin styles so Field Grouping no longer works. If this needs to be considered a separate issue then we can open a new bug ticket.

I agree. The only reason this issue has ever popped up on me is when Drupal could not load the CSS/JS asset file correctly. Whether it be added versioning, incorrect filenames, or file access issues. Check your logs before doing anything further.

rpearl → created an issue. See original summary → .