πŸ‡ΊπŸ‡ΈUnited States @FrankieD3

Account created on 8 June 2021, over 2 years ago
#

Recent comments

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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!

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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!

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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.

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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?

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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?

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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.

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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');
}
πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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']);
    }
  }
}
πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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!

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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 :
πŸ‡ΊπŸ‡ΈUnited States FrankieD3

Still working as of current. Marking RTBC.

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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.

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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.

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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.

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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.

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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.

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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

πŸ‡ΊπŸ‡ΈUnited States FrankieD3

#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)
πŸ‡ΊπŸ‡ΈUnited States FrankieD3

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

Production build https://api.contrib.social 0.61.6-2-g546bc20