🇨🇦Canada @joseph.olstad

@damienckenna , seems like folks are getting really busy working on Drupal CMS.

With that said, are you able to provide a one sentence proposal that is perhaps clearer than:

EoL for majors six months after the release of the second subsequent major

a suggestion from Slack that states "core does tend to like one sentence proposals".

Tagging my orgs

Thanks, I updated the Merge request for Drupal 11, I think it's good to go now

#3428282-19: Automated Drupal 11 compatibility fixes for boost →

Easy fix for the dynamic property issue is documented here:
#3500762-2: Crawling broken on D11 →

Suggest moving forward with Drupal 11, we've already upgraded a few sites to Drupal 11 and all our new development is on Drupal 11.1.x+

joseph.olstad → created an issue.

joseph.olstad → created an issue.

Perfect, thank you for the very quick response and fix!

We've been using linkchecker 2.1.0-alpha1 in production with a few patches, haven't noticed the regression mentioned in #22, not sure I understand what that is.

joseph.olstad → created an issue.

Possibly due to the use of the filebrowser module.

Good enough for now, if you want to push this further , open a new issue

https://www.drupal.org/project/book_pdfs/releases/1.0.0-rc7 →

Thank you @joris

Very good thanks for this!

joseph.olstad → created an issue.

MR 111 is for 2.0.x
MR 114 is for 2.1.x

I highly recommend that everyone use 2.1.x instead of 2.0.x, 2.0.x has a dependency on der , a very heavy module that should be avoided whenever possible.

Credit should go to @jamesyao for the Check links button functionality.

This latest patch adds a "Check links" button on the Maintenance accordion on the linkchecker settings form /admin/config/content/linkchecker

This button is back by popular demand, clients asked , they get.

joseph.olstad → created an issue.

Same as https://git.drupalcode.org/project/linkchecker/-/merge_requests/111.diff

Pretty sure this is good.

any explanation for the needs work?

hmm, I tested in my view, seeing this:

Error: Call to a member function label() on null in Drupal\linkchecker\Controller\LinkcheckerStatusController->checkStatus() (line 56 of modules/contrib/linkchecker/src/Controller/LinkcheckerStatusController.php).

joseph.olstad → made their first commit to this issue’s fork.

@tichris59, est-ce que le problème a été vue en tournant 3.0.x ou 2.0.x?

@lavanyatalwar
Yes that change was made on purpose , it is the intended label.

@jastraat , yes please create a followup ticket and PR
Great work!
and Thanks again!

probably not that hard to patch safedelete to add paragraphs support , would take some jigging but definately possible, check the field type of the paragraph make sure it's got a text format and that it's a text area field type .

patch #44 works on D10.4.6 however patch #45 fails to apply.
patch #44 works on D11.1.6 however patch #45 fails to apply.

Recommend continuing with patch #44 and ignoring patch #45

Patch #44 resolves the bug, prevents WSOD when using layout_builder on a node page in the other language.

hmm, ok we're still using the patch, my contract with the client using this has only a few hours left so I won't be able to re-test.

Hopefully this is sorted out, it's good to go AFAIK.

I just hit this also with 6.3.0-beta2 and the latest core, not sure why yet.

Apparently there may be another way around this issue, from a message in slack drupal ckeditor5 channel.

joshuami
mercredi le 23 avril à 17 h 47
We've had pretty solid results from adding source plus the following to a custom module:

mymodule_ckeditor5_allowHTML:
  ckeditor5:
    plugins: [htmlSupport.GeneralHtmlSupport]
    config:
      htmlSupport:
        allow:
          - name: table
            classes: true
          - name: thead
            classes: true
          - name: tbody
            classes: true
          - name: ol
            classes: true
            attributes:
              - key: type
          - name: div
            classes: true
            attributes:
              - key: id
              - key: aria-labelledby
              - key: data-bs-parent
          - name: span
            classes: true
          - name: drupal-media
            attributes:
              - key: data-title
              - key: data-fullsize
              - key: data-description
              - key: data-hide-translations
              - key: title
          - name: p
            classes: true
          - name: h2
            classes: true
            attributes:
              - key: id
          - name: h3
            classes: true
            attributes:
              - key: id
          - name: h4
            classes: true
            attributes:
              - key: id
          - name: h5
            classes: true
            attributes:
              - key: id
          - name: h6
            classes: true
            attributes:
              - key: id
          - name: i
            classes: true
    drupal:
      label: Arbitrary HTML support
      library: mymodule/ckeditor5
      elements: 
        - <table class>
        - <thead class>
        - <tbody class>
        - <ol class type>
        - <div class id aria-labelledby data-bs-parent>
        - <span class>
        - <drupal-media data-title data-fullsize data-description data-hide-translations title>
        - <p class>
        - <h2 class id>
        - <h3 class id>
        - <h4 class id>
        - <h5 class id>
        - <h6 class id>
        - <i class>

That failure makes no sense. , where is it getting another directive for layout_builder_st from?

@smulvih2 , yes that exception is expected, drush updb will fix it. No amount of cache rebuild will fix this, the only way to fix is by running updb or to truncate all cache_* tables.

Postponed on upstream toc_filter fix being merged/tagged/released.

For comment #45
🐛 Fatal error after updating to toc_api:^2 Active
and
🐛 Layout builder fatal error Active

Yes sorry the patch description and patch name was in error, what I meant to do was
🐛 Fatal error after updating to toc_api:^2 Active
and
🐛 Layout builder fatal error Active
3518549-and-3520464-45.patch

instead of what I put in.

looks like you sorted it out, thanks!

@liam morland, forking is problematic for a few reasons, mainly the bumpy ride for existing installs and it's not going to be something that automatically happens for those upgrading. People will stumble before they find the solution.

The merge request appears to work, what is missing is the contextual translation link however I believe this is something caused by a change in core between 10.3 and 10.4 as the workaround that was made to use layout_builder_st with 10.2 is no longer providing the contextual translation link option. This is a core regression not caused by the layout_builder_st module.

🐛 Contextual links for translation are removed by core Active

with that said, the patch workaround appears to have no effect. I left it in the merge request just in case I'm missing something in my observation(s).

The merge request has been tested, I see no regression from 10.4 to 11.1 and no regression from the override modules to the contrib version. Layout builder is functioning as it was prior to the change.

This aligns us with contrib going forward and allows us to unblock our release.

I am wondering, for expediency do we release 6.1.0 or do we re-gig the versions to match core so the first D11 WxT release becomes 11.1.0 instead of 6.1.0. To be honest, the x.x.x only makes sense if the first number corresponds to a Drupal major.

@yospyn, we're using webform_bootstrap with Drupal 11.1.6 and the latest webform module 6.3.0-beta2.

As for deprecating, I think it's too soon to deprecate. Bootstrap 3 will be supported for the duration of jQuery 4 and possibly beyond. There's tens of thousands of installs.

with that said, could fork if needed as mentioned earlier.

@ccolumbie , please try this patch: https://git.drupalcode.org/project/panels/-/merge_requests/31.diff

cd /path/to/ccolumbie/drupal/html/modules/contrib/panels;
curl https://git.drupalcode.org/project/panels/-/merge_requests/31.diff > ipe.patch;
patch -p1 < ipe.patch;

if curl doesn't work, try wget

cd /path/to/ccolumbie/drupal/html/modules/contrib/panels;
wget https://git.drupalcode.org/project/panels/-/merge_requests/31.diff
patch -p1 < 31.diff;

Nudge

This workaround fix appears to have been broken some time after Drupal 10.2

I no longer see the translation contextual link.

Something may have happened after D10.2 because even with this patch installed, I do not see the contextual link for translation. Probably due to an upstream change they probably finished it off.

Please tag an rc release or something.

alpha, beta or rc, any of the above would be good.

suggested tags:

2.0.0-alpha
2.0.0-beta
2.0.0-rc1

I would suggest that this qualifies for at least a beta. This module is way past alpha stage.

Restoring back to RTBC, since this was RTBC previously.

Ok, so now that we have a 2.0.x branch , (working), upgrade to 2.0.x, run drush updb first before a cache rebuild, then rebuild cache, review the MR 5

Ok so good news, we're able to use 2.0.x straight up with Drupal 11, the trick was to do a drush updb , otherwise no major issues found (yet), however we are using this patch: 🐛 Contextual links for translation are removed by core Active

Ya this is gone now after the updb
might have been a bad test case, I had to rebuild my environment a couple times.

With the latest change, it comes through.

Thanks!

Ok ya, this works

@liam morland , let's open a new issue for those

ah ok ya drush updb, ok I'll try that now

this magical function here:

function layout_builder_st_rebuild_container_for_v2(): void {
  // Empty post-update hook to force a container rebuild.
}

what is this for_v2? This can't possibly be a hook, how would this ever get called? Is this part of a mystery API for core?

Ok this change makes no difference, I patched 2.0.x, still unable to rebuild cache with drush without a massive exception.

drush version: 13.3.3.0
php version 8.3.20

╰❯ $ cat !$
cat layout_builder_st.post_update.php

/**
 * @file
 * Contains post-update hooks for layout_builder_st.
 */

declare(strict_types=1);

/**
 * Rebuilds the container for updating layout_builder_st to v2.0.0.
 */
function layout_builder_st_rebuild_container_for_v2(): void {
  // Empty post-update hook to force a container rebuild.
}

╭─◀ ☕ ryzen ▶ /docroot/html/modules/contrib/layout_builder_st ▶ 📂3 📃10 🔗0 ▶ 🔀 2.0.x ▶
╰❯ $ drush cr;
[error] TypeError: Drupal\layout_builder_st\DependencyInjection\ClassResolver::__construct(): Argument #1 ($decorated) must be of type Drupal\Core\DependencyInjection\ClassResolverInterface, Drupal\Core\DependencyInjection\Container given, called in /var/www/clients/client1/web1/web/docroot/html/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 in Drupal\layout_builder_st\DependencyInjection\ClassResolver->__construct() (line 14 of /var/www/clients/client1/web1/web/docroot/html/modules/contrib/layout_builder_st/src/DependencyInjection/ClassResolver.php) #0 /var/www/clients/client1/web1/web/docroot/html/core/lib/Drupal/Component/DependencyInjection/Container.php(259): Drupal\layout_builder_st\DependencyInjection\ClassResolver->__construct()

Only way past this is to truncate all cache tables.

once I truncate all cache tables, the site appears to work.

Surely there's a way to make this a lovely experience for everyone involved without having to truncate all cache_* tables manually?

ok that helps, however now that there's no more drush exception, the website throws a WSOD and dblog didn't catch it, I had to go into the error.log to find this:

Got error 'PHP message: PHP Fatal error: Cannot redeclare Drupal\\layout_builder_st\\Element\\LayoutBuilder::layout() in /docroot/html/modules/contrib/layout_builder_st/src/Element/LayoutBuilder.php on line 74'

🐛 The "layout_translation" plugin does not exist. Active

joseph.olstad → created an issue.

https://www.drupal.org/project/layout_builder_st/issues/3520833 📌 add an empty post-update hook to force a container rebuild Active

joseph.olstad → created an issue.

@phenaproxima

That doesn't work either. I truncated all the cache_ tables. like this:

TRUNCATE cache_access_policy;
TRUNCATE cache_bootstrap;
TRUNCATE cache_config;
TRUNCATE cache_container;
TRUNCATE cache_data;
TRUNCATE cache_default;
TRUNCATE cache_discovery;
TRUNCATE cache_discovery_migration;
TRUNCATE cache_dynamic_page_cache;
TRUNCATE cache_entity;
TRUNCATE cache_font_awesome;
TRUNCATE cache_menu;
TRUNCATE cache_migrate;
TRUNCATE cache_render;
TRUNCATE cache_toolbar;
TRUNCATE cache_tweets;

╭─◀ ☕ ryzen ▶ /docroot ▶ 📂12 📃15 🔗4 ▶ 🔀 11.1.x ▶
╰❯ $ drush cr;

In FieldStorageConfigStorage.php line 167:
                                                                                                                                             
  Unable to determine class for field type 'layout_translation' found in the 'field.storage.node.layout_builder__translation' configuration  
                                                                                                                                             

In DiscoveryTrait.php line 53:
                                                                                                                                                                                       
  The "layout_translation" plugin does not exist. Valid plugin IDs for Drupal\Core\Field\FieldTypePluginManager are: comment, context, datetime, entity_reference_revisions, file, fi  
  le_uri, fontawesome_icon, image, layout_section, link, metatag_computed, metatag, list_float, list_string, list_integer, path, text_long, text, text_with_summary, webform, uuid, c  
  hanged, decimal, password, uri, language, entity_reference, timestamp, created, email, map, string, string_long, integer, float, boolean

ya, I'll try that, however it is tough to expect all our clients to do that.

Ya I ran drush cr several times, also restarted php8.3-fpm , didn't help.

oops

yes this was testing a drop-in replacement for our patched version based on layout_builder_st 8.x-1.x , I ran cache rebuild several times with drush and unable to shake it. Is there a drush command for doing a container rebuild?

I'm seeing this as a possibility:

drush ev '\Drupal::service("kernel")->invalidateContainer();'

patch for toc_filter

Patch in 78 does not apply cleanly, using the diff instead of the patch, here's a new patch file with the diff instead.

Temporarily (until something better is vetted for D11) we'll be switching to 2.0.x#a8f47feb7aff (the 2.0.x branch) and applying this patch: https://www.drupal.org/files/issues/2025-04-23/3497945-and-3431600.patch →

greggles → credited joseph.olstad → .

Please apply the upstream patch!

Ah , looks good, unfortunately I'm not the maintainer of this project.