🇺🇸United States @FrankieD3

I've stumbled upon this issue and figured I'd toss in the solution I used for core cases. The issue stems from core, but Gin Layout Builder → makes it a bit easier to notice.

Simply put, the method for determining if the preview is empty sees it as nonempty. The contextual editing link is still present, but in your case, Gin Layout Builder has not reserved space for it.

See #3239899 🐛 Blocks do not have placeholders in Layout Builder Needs work for an explanation as to what's going on, and follow #953034 🌱 [meta] Themes improperly check renderable arrays when determining visibility Needs work for the main issue.

My solution was to add a library to my front-end theme that I would only enqueue on Layout Builder pages with Gin Layout Builder overrides. See below.

The CSS included in the library:

.layout-builder-block {
  min-height: 48px;
}

Including the library:

/**
 * Implements hook_page_attachments_alter().
 */
function your_theme_page_attachments_alter(array &$attachments) {
  $is_layout_builder_active = \Drupal::routeMatch()->getRouteObject()->getOption('_layout_builder');
  $is_gin_lb_enabled = \Drupal::moduleHandler()->moduleExists('gin_lb');
  if ($is_layout_builder_active && $is_gin_lb_enabled) {
    $attachments['#attached']['library'][] = 'your_theme/gin-layout-builder-overrides';
  }
}

@pierrepaul, Twig officially recommends the include function over the include tag. See the first note on the Twig's include tag documentation page, also quoted below.

It is recommended to use the include function instead as it provides the same features with a bit more flexibility

I've reverted to my last revision from comment #15730343 → .

This is perhaps also an issue of the project page's representation of the module no longer representing its current state. Both the region and content preview buttons are now nested beneath display options, which is not the case in the screenshot nor the video.

frankied3 → created an issue.

I'm still experiencing this issue on 10.3.6. My use case involve using Views Reference Field → within custom custom block types.

Has there been any movement on this issue? This is a fairly big UX concern for page builders. With Experience Builder → on the way, hopefully these sorts of issues will soon be irrelevant.

That'd be it. I created the patch for my production site, hence the non-dev branch patch. Hopefully this one does it.

Please excuse my lack of knowledge, as I'm not the most well versed when it comes to Git and the like. Of the available branches listed when running git branch -r (8.x-1.x and 2.x), I pulled down 2.x this time.

If I've managed to goof up, please correct me, and I'd be happy to create another patch!

frankied3 → created an issue.

I believe I have been misinformed as to how this functionality works. Apologies!

frankied3 → created an issue.

frankied3 → created an issue.

frankied3 → created an issue.

Updated notice to be in line with " Using your new single-directory component → ."

Updated notice to be in line with " Using your new single-directory component → ."

Updated notice to be in line with " Using your new single-directory component → ."

I've also experienced the same mentioned in #13. As a temporary solution I've downgraded to 6.x. Given that this is a critical issue that breaks the intended functionality, should 6.x perhaps be set as the current recommended build until this is resolved?

I can confirm the above. With the Smart Date and Diff modules enabled:

1. Add a Smart Date field to any given content type
2. Create a node of the content type with the Smart Date field
3. Update the node to create a revision - note that you don't have to fill out the Smart Date field
4. Compare the new revision using the Diff module through the node's revision page

Fixed a grammatical mistake, added a link for more context, and added a section on disallowing context from being passed with an include.

I've committed the change to my issue fork. I'm not too familiar with Git, so if anything else is needed from my end, please let me know.

For those in need of a quick fix, I'm including the patch here as well.

FrankieD3 → created an issue.

It looks to me that the pager does not benefit from any of the class's properties and can safely be removed from the element. All it inherits from the layout--content-medium class is a width of 100%, as well as statically set grid-column values per breakpoint.
It's very possible that I've missed something, though. If I have, please let me know!

FrankieD3 → created an issue.

Rewrote the majority of the copy for sake of clarity. The previous copy contained many formatting inconsistencies, as well as some broken English that could lead to possible confusion.

The current Twig spec recommends the include function over the include tag. See the first note on the include tag page. As thus, Drupal should reflect this standard. The Twig embed link in the final paragraph was also linked to 1.x, and I updated it to 3.x.

I can confirm that this is reproducible in 10.2.x, as well as the additional pager render mentioned in #2.

This does appear to be a core issue. It just so happens that Views Reference Field is what exposed it. Continuing in #3461890 🐛 AJAX views pager not working when rendered through layout builder Active Thanks!

FrankieD3 → created an issue.

I was able to reliably reproduce the issue through a fresh ddev install. Hopefully this will be a bit clearer than my first attempt.

Leaving out the standard steps to create a new ddev Drupal install, I spun it up with the following config:

ddev config --project-type=drupal --php-version=8.3 --docroot=web
ddev composer create drupal/recommended-project:^10
ddev composer require drush/drush drupal/viewsreference:^2.0@beta

Most of what I had mentioned in the IS was pre-installed, so that cuts down on installs.

1. Install Layout Builder and Views Reference Field
2. Create four Article nodes, only populating the title fields
3. Create a content view with no filters, enable a full pager with two items per page, and enable AJAX
4. Create a block type and add a Views Reference Field, leaving the default settings
5. Navigate to /admin/content/block and add a content block, referencing the previously created AJAX view
6. Create a new vocabulary and enabled Layout Builder for the default display
7. Manage the layout of the vocabulary, adding a new section containing the previously created block
8. Add a term to the vocabulary, only populating the title
9. Navigate to the new term and use the rendered view's pager

The view uses the standard non-AJAX pager, loading a new page with the page query parameter appended to the URL.

Following these steps I was able to reliably reproduce the issue multiple times.

My next step will be digging through the hooks you mentioned in viewsreference.module.

Thank you for your patience!

Revisiting my issue this week, I believe it goes deeper than this module.
I'm a bit befuddled, especially given you can't reproduce it. It seems that any view I attempt to render through a content block placed with Layout Builder does not attach the associated data needed within #attached.
Since you can't reproduce the issue, where do you suggest I go from here?

No, none! It's a strange case. I can render the same block containing the view on a page multiple times through multiple methods, and the only one NOT to receive the AJAX behavior is the one rendered through Layout Builder.
I'm not sure what else I can provide, but I will gladly give any information I can. Perhaps this is a core issue, or an issue elsewhere?
All I can glean from this is that the Once call for ajax-pager isn't running on that specific view. Apologies for not having much else to go on!

I am on the suggested 8.x-2.0-beta8 branch. I've given the patch a try, but as expected, it didI am on the suggested 8.x-2.0-beta8 branch. I've given the patch a try, but as expected, it did not apply. not apply.

FrankieD3 → created an issue.

FrankieD3 → created an issue.

Applying the patch from #3384600 🐛 Don't hide permissions local tasks on bundles when no permissions are defined Needs work on my 10.3.0 install has resolved the issue for me as well.

FrankieD3 → created an issue.

Where do we stand on this? This is a fairly critical change in my eyes. Six months of inactivity and I would love to see some movement here.

FrankieD3 → created an issue.

Same problem here. I can confirm that this resolves the issue. Should I revert back for the time being, or can we expect this to be rolled out soon?

FrankieD3 → created an issue.

I feel as though the updated text "Provide a default value. It isn't used in Twig template." does not include enough context. If I were looking at this with fresh eyes, I would be thinking to myself, "then where is it being used?"

An example of a Twig template containing the use of the default() filter would be useful somewhere within the documentation. Something to that effect of {% set text = text|default('Placeholder'|t) %}.

Any updates on this functionality? If this has still yet to be implemented, the documentation should be altered to reflect the current state of the module so not to mislead developers.

FrankieD3 → created an issue.

What else do we need to get this moving down the pipeline towards a PR?

I've finally stumbled across a solution. It seems to have been caused by the http.response.debug_cacheability_headers parameter in development.services.yml being set to true.

Setting http.response.debug_cacheability_headers: false fixed things right up.

Thanks!

I've finally stumbled across a solution. It seems to have been caused by the http.response.debug_cacheability_headers parameter in development.services.yml being set to true.

Setting http.response.debug_cacheability_headers: false fixed things right up.

Strange that the issue cropped up specifically when I upgrade Office Hours. Either way, I've solved it.

Thanks!

It seems to have taken a full module reinstallation to clear this up. No amount of cache invalidation seemed to allow for Drupal to recognize the new @image.factory argument for the twig_tweak.image_view_builder service.

I have run into this issue in the past with my own module development, and I've yet to find a solution that doesn't take a reinstallation. Adding new keys to existing services in the YAML shouldn't introduce issues like this, yet I've run into this again and time again.

I'll go ahead and mark this as fixed, although I'm curious to see if any others run into this. Thanks for your time.

I hadn't thought about it at the time, but #5 raises a good point.

Is the discrepancy between the view mode available at $variables['view_mode'] and the real currently-active view mode worth raising Pan issue in core?

Or is this perhaps by design, and I am misunderstanding the variable's intention?

I am unable to restart the server as it's a production environment, though I could potentially clear the opcache.

Would you per chance know how to go about doing this in a WHM environment utilizing EasyApache?

Yes, I've cleared cache multiple times, both through Drush and the web UI. To note, this has happened on all three installs on this box using Twig Tweak.

FrankieD3 → created an issue.

Apologies for the late reply.

This was the solution! Thanks so much for your help.

Below is my refactored snippet.

function hook_preprocess_node(array &$variables) {
  /** @var \Drupal\node\NodeInterface $node */
  $node = $variables['node'];

  /** @var \Drupal\Core\Entity\EntityDisplayRepository entity_display_repository */
  $entity_display_repository = \Drupal::service('entity_display.repository');

  $view_display = $entity_display_repository
    ->getViewDisplay($node->getEntityTypeId(), $node->bundle());

  $variables['layout_builder_enabled'] = $view_display
    ->getThirdPartySetting('layout_builder', 'enabled');
}

FrankieD3 → created an issue.

Please disregard. It appears that this has already been taken care of in the dev branch.

FrankieD3 → created an issue.

Oops, intended to create this issue in the main Gin admin theme project. My apologies.

FrankieD3 → created an issue.

It very well could be, though I mistakenly left out a vital bit of information in my original post. This isn't so much a CSS issue as it is a template issue.

I have the following preprocess in my front-end theme's .theme file, and it is effecting the rendering of elements within CKEditor 5 with the admin theme. To note, I am using the Gin admin theme.

function theme_preprocess_image(array &$variables) {
  // Remove the "title" attribute from the image element.
  unset($variables['attributes']['title']);

  // Check if the "loading" attribute is set to "lazy".
  if (isset($variables['attributes']['loading']) && $variables['attributes']['loading'] === 'lazy') {
    $variables['attributes']['class'][] = 'lazy';
    unset($variables['attributes']['loading']);

    // If the "src" attribute is set, move it to "data-src".
    if (isset($variables['attributes']['src'])) {
      $variables['attributes']['data-src'] = $variables['attributes']['src'];
      unset($variables['attributes']['src']);
    }

    // If the "srcset" attribute is set, unset it in favor of sibling source elements.
    if (isset($variables['attributes']['srcset'])) {
      unset($variables['attributes']['srcset']);
    }

    // If the "sizes" attribute is set, unset it in favor of sibling source elements.
    if (isset($variables['attributes']['sizes'])) {
      unset($variables['attributes']['sizes']);
    }
  }
}

FrankieD3 → created an issue.

Updating Core from 10.1.x to 10.2.x, as well as Drush from 11.x to 12.x, resulted in the same error as OP. My hosting provider suggests using a symlink to the webroot, and this has been my standard for years. I swapped all the paths to the actual directory name, and Drush was once again usable. Thanks!

FrankieD3 → created an issue.

I wholly agree with all requests for a D10 release. This is update blocking for many of us.

FrankieD3 → created an issue.

I've finally been able to produce an error through the Apache error logs, though it may not be too useful. This is the only trace of an error whatsoever, and only appears when in relation to Office Hours being present on the form. I assume this out of the scope of the project, and a deep rooted configuration issue?

[Tue Nov 21 15:36:28.727122 2023] [proxy_fcgi:error] [pid 1376:tid 47477690558208] [client {local ip}] Premature end of script headers: index.php
[Tue Nov 21 15:36:28.727182 2023] [proxy_fcgi:error] [pid 1376:tid 47477690558208] [client {local ip}] AH01070: Error parsing script headers
[Tue Nov 21 15:36:28.727188 2023] [proxy_fcgi:error] [pid 1376:tid 47477690558208] (22)Invalid argument: [client {local ip}] AH01075: Error dispatching request to :

Still working as of current. Marking RTBC.

I suppose so, as this install has thousands of nodes with existing hours that my content team needs access to.

For now I will stay on a static version of 1.9.0 on production.

If I manage to produce an error I will bump the issue with any new information.

Thanks much for attempting to help me diagnose the issue.

Dev also fails. Given this seems to be an isolated issue, should we table it for now and revisit it in the future? There doesn't seem to be too much to go off of, and I'm not sure what other information I could supply at this point.

Downgrading to 1.9 yields the same results, as does toggling and resaving the field settings.

I do recall that I had a similar issue on a D9 install a while back, though the error wasn't silent. I've checked the composer.json on this other domain, and it has a static version of 1.9.0.

If I call correctly, that issue had to do with seasons, though they weren't being used.

I'm not sure if this is relevant, but given that the same base composer.json was used initially for both of these installs, it could be connected.

I've gone ahead and reverted to 1.10, and strangely, the issue persists.

Perhaps it could be related to a core update? I only go about updating the development domain when new features need to be implemented, so there are a handful of updates that were run at the same time.

I am wracking my brain for any other variables, and I'm coming up empty handed.

I'll go ahead and test the intermediary versions. My apologies for the late response.

Correct on both accounts.

I can also confirm this is present on PHP 8.1.25.

The only variable between my production and dev site that I am aware of is the module version.

It appears that the second warning is a core issue. #3368250 🐛 Deprecated creation of dynamic property in TypedData Needs work

FrankieD3 → created an issue.

FrankieD3 → created an issue.

#2 fixed the deprecation warning, though another deprecation warning has arisen. Relevant lines below.

Deprecated function: Creation of dynamic property Drupal\tablefield\TableValue::$value is deprecated in Drupal\Core\TypedData\TypedData->setValue() (line 102 of {homedir}/{webroot}/core/lib/Drupal/Core/TypedData/TypedData.php)

#0 {homedir}/{webroot}/core/includes/bootstrap.inc(164): _drupal_error_handler_real(8192, 'Creation of dyn...', '{homedir}/{webroot}...', 102)
#1 {homedir}/{webroot}/core/lib/Drupal/Core/TypedData/TypedData.php(102): _drupal_error_handler(8192, 'Creation of dyn...', '{homedir}/{webroot}...', 102)
#2 {homedir}/{webroot}/core/lib/Drupal/Core/TypedData/Plugin/DataType/Map.php(87): Drupal\Core\TypedData\TypedData->setValue(NULL, false)
#3 {homedir}/{webroot}/core/lib/Drupal/Core/Field/FieldItemBase.php(125): Drupal\Core\TypedData\Plugin\DataType\Map->setValue(Array, false)
#4 {homedir}/{webroot}/modules/contrib/tablefield/src/Plugin/Field/FieldType/TablefieldItem.php(206): Drupal\Core\Field\FieldItemBase->setValue(Array, false)
#5 {homedir}/{webroot}/core/lib/Drupal/Core/TypedData/TypedDataManager.php(208): Drupal\tablefield\Plugin\Field\FieldType\TablefieldItem->setValue(Array, false)

FrankieD3 → created an issue.

Small update to regex used in example. It was overly verbose, and may dissuade newer developers.