@solideogloria

FYI, Select2 hasn't been updated for even longer than Choices. If we're going to consider ChoicesJS abandoned, the same should be said about Select2...

Triggered a rebase

Is there a way to remove the unneeded settings without resaving every field manually in the UI? Or a way to automate resaving them all?

@La558 You don't quite understand. In order to use those Webform sub-modules, you need to require the libraries. For example, in your composer.json:

    "require": {
        "wikimedia/composer-merge-plugin": "^2.0"
    },
    "extra": {
        "merge-plugin": {
            "include": [
                "web/modules/contrib/webform/composer.libraries.json"
            ]
        },

You would remove this, and explicitly require the libraries you need instead.

The error is one that I fixed in ✨ Add option to disable cron activity Needs review , but if you don't want to merge that issue's fix, it can be fixed here.

The fatal error I received earlier was fixed by clearing the cache after updating. There is still an error though.

Also, the settings form in 2.x is broken.

🐛 Linkchecker settings form is broken Active

solideogloria → created an issue.

solideogloria → changed the visibility of the branch 2.0.x to hidden.

Please convert the patch to a merge request if you can.

@catch I implement Drupal.theme.message, and that doesn't fix the issue, because the function isn't being called for the BigPipe messages. Only commenting out that BigPipe code fixes it.

solideogloria → created an issue.

I think you're right. The changes are completely wrong. Can you update the MR?

I agree. I was worried about disabling the module, wondering if I would unknowingly break something.

I ended up disabling it, and then exporting config, to see if anything changed.

Is there a way to patch it with composer?

Also, RE: #14, be aware that it's not valid JSON, as the escape sequence isn't valid. This is corrected:

    "scripts": {
        "drupal-scaffold": "DrupalComposer\\DrupalScaffold\\Plugin::scaffold",
        "post-install-cmd": [
            "sed -i 's#https://polyfill\\.io/#https://polyfill-fastly\\.io/#g' web/libraries/choices/public/index.html"
        ]
    },

composer.json

        "drupal/openid_connect": "^3.0@alpha",
        "drupal/openid_connect_windows_aad": "^2.0@beta",

composer.patches.json

    "drupal/openid_connect": {
      "#3011413: Autologin when one client enabled": "./patches/openid_connect-3011413-m98.patch",
      "#3375886: Warning: Undefined array key 'iss_allowed_domains'": "./patches/openid_connect-3375886-m86.patch",
      "#3441149: Add option to disallow using the 'showcore' query parameter": "./patches/openid_connect-3441149-m108.diff"
    },

I think that Upgrade Status should be re-run to see if changes are still needed. The module just released an updated version that fixes some compatibility issues. The issue title should be updated to be more descriptive as well.

We could also look at the Visitors → module and see if there are any features it has that are desirable. I've never used that module, but I see that it has

• View pages count per month.
• View pages count per day of the month.
• View pages count per day of the week.
• View pages count per hour.

I think some of these would be pretty useful. Though, if you're going to do this, it's certainly best if you don't track each individual view as a page+timestamp. It would be better to only track at the desired level of granularity, such as daily views, and then only keep the count for each day for the last month's worth of days. Older counts could be kept at a month granularity, by adding the daily view counts together and saving it for that month, then starting at zero for the new month.

However, I do agree that a separate checkbox is probably the better solution.

I use the Autologin feature as well, and the solution from the MR is working.

I don't think ✨ Enable to customize an icon HTML output Needs work should be a blocker for a stable release.

Could someone please review this? It's a significant performance increase, and it'd be nice to have this included for everyone.

@ady1503 You must be doing something wrong in your modules. You definitely shouldn't be adding exit() after those calls, as it will prevent any other code from running.

Consider opening a separate issue, as your problem is likely something else.

Not a problem. It is showing on my Drupal profile.

Did you set issue credit? I don't see any users credited.

I like that command. That would be a cool addition!

One of DDEV Drupal Contrib's features is that it does all of its work without modifying the module's composer.json. If I want to install Drush into the project myself, I have to modify composer.json.

I just looked into this yesterday. I had forgotten about the built-in commands, too. However, I use DDEV Drupal Contrib, and when I set up a contrib module dev environment, Drush isn't installed, unless the contrib module has it in its composer.json, which almost none do.

So I was trying to find a way to install Drupal from CLI, without Drush. It's not easy, and the built-in commands don't support arguments for all the options available in the UI, and you can't use MySQL instead of SQLite as far as I know.

I will note that I have never used this module, so I'm new to how it worked in Drupal 7 or should be expected to work in Drupal 10. However, I have experience with programming in Drupal, so I'm willing to help improve the code base.

solideogloria → created an issue.

+1 to #10. Yes, this is what happens. Same with choices/choices, which is also affected.

The actual issue is 🐛 AJAX MessageCommand markup and styling differs from Theme default Active , since the other was closed as a duplicate.

I think this would be cool, but it's understandable that there's not a lot of interest in terms of comments.

This is a core issue.

This patch is just a workaround that removes the layout form element.

solideogloria → created an issue.

I guess priority should be "Major" since not everyone is affected.

Yes, I found out I can view the form that way. Another workaround could be to add a try/catch.

A proper solution would be to use some static example markup that showcases some blocks in a layout, I think.

Even if I add an IF that skips using the entity_type_id of menu_link_content (this is the one that causes the issue for me, since the settings form is picking the first one using the layout builder, this is what it picks for me), I still get an error:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "layout_twocol_section" plugin does not exist. Valid plugin IDs for Drupal\Core\Layout\LayoutPluginManager are: layout_onecol, with_sidebar in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).
Drupal\Core\Plugin\DefaultPluginManager->getDefinition() (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() (Line: 83)
Drupal\Component\Plugin\PluginManagerBase->createInstance() (Line: 116)
Drupal\layout_builder\Section->getLayout() (Line: 218)
Drupal\lb_plus\Element\LayoutBuilderPlus->buildAdministrativeSection() (Line: 127)
Drupal\lb_plus\Element\LayoutBuilderPlus->layout() (Line: 99)
Drupal\lb_plus\Element\LayoutBuilderPlus->preRender()
call_user_func_array() (Line: 113)

It won't really help though, if the settings form doesn't actually work...

This completely prevents a user from changing module settings in the admin interface, short of modifying the config YAML.

Please fix this.

solideogloria → created an issue.

Convenience patch.

Removing all: revert would work, but I'm guessing that's needed for some reason? (I don't see any other changes when removing it.) So I just added an exception for input::before.

solideogloria → created an issue.

Agreed. A helpful message should be displayed instead.

Yes, my mistake for closing.

Applies and works for me.

In case the module does happen to be the cause of an error, I will ask for more info. The Drupal Core issue and patch are just (essentially) workarounds that change an Exception into a triggered error. However, I use this module and don't have any issues in 10.3, even without the patch from the Core issue.

If you still have the issue, try setting a breakpoint in the code where the error is thrown from. You might have another plugin throwing errors.

How's this?

@dadderley If you still have a problem in 10.3, then your text format is using an invalid CKEditor plugin. I had the same problem, too, prior to discovering that.

#45 workaround works for me, too.

I'd suggest marking the module as deprecated if you don't intend to support it alongside the plugin pack, and put a link/reference to the alternative on the module page.

The plugin pack works. Thanks.

composer require 'drupal/ckeditor5_plugin_pack:^1.1'
drush en ckeditor5_plugin_pack ckeditor5_plugin_pack_find_and_replace
drusn pmu ckeditor_find
drush cex -y

Closing as duplicate of 🐛 Replace LogicException with trigger_error in LangcodeRequiredIfTranslatableValues constraint RTBC . It's a core issue.

Patch #13 works in Drupal 10.3. (I don't use config_inspector either.)

If there are promoted properties, then I think it should be a convention to have each parameter on its own line. It's really helpful for readability. Since autowiring and other PHP attributes may be added as well, it would be far too long and unreadable to have parameters all in the same line.

Can you tell me what .scss file that would be in? If you look at my changes to files, nothing affected that in an scss file.

Also, is there a way to disable minification of CSS in the yarn build? It's impossible to see what changed in the CSS when it's all minified.

Still, better than before.

This still needs work, as the Gin sidebar on the edit form has a way to hide it, which is important on small screens and mobile. This sidebar cannot be hidden, so it breaks all useability on small screens, since it cannot be hidden.

I adding padding-right to the body element for the layout builder. This is the same thing Gin does on its edit page in its toolbar.scss.

Please review to see if the changes fix the issues.

This isn't always the front-end theme. On my site, content and layout editing uses the admin theme, which is Gin.

solideogloria → created an issue.

@devKhairul Can you try using the patch and see if it fixes the issue for you? If it does, the issue can be marked RTBC.

Looks good to me. Do we need to add a test to cover that noreferrer is added to links with a target attribute already set?

Updated the MRs.

Would this make the JavaScript Drupal.theme.message obsolete?

... I'm not sure that's the whole of the issue. I override/redefine Drupal.theme.message in my custom theme so that the rendered HTML for Ajax matches my theme's template file. However, it's not getting called by these Ajax messages.

If I copy BigPipe.php's changes to 10.2.7 so that the messages template isn't used and they are sent with Ajax, my custom Drupal.theme.message is called in Drupal 10.2.7 for other Ajax messages, but not for these Ajax messages sent by BigPipe. Same in 10.3.x.

If you test with a controller:

  public function test(Request $request): AjaxResponse {
    $response = new AjaxResponse();
    $response->addCommand(new MessageCommand('Test.', NULL, ['type' => 'error']));
    $response->addCommand(new MessageCommand('Test 2.', NULL, ['type' => 'status']));
    return $response;
  }

And override Drupal.theme.message:

  Drupal.theme.message = ({ text }, { type, id }) => {
    console.log('Custom theme Ajax message!');

    const messagesTypes = Drupal.Message.getMessageTypeLabels();
    const messageWrapper = document.createElement('div');

    messageWrapper.setAttribute('class', `messages messages--${type}`);
    messageWrapper.setAttribute(
      'role',
      type === 'error' || type === 'warning' ? 'alert' : 'status',
    );
    messageWrapper.setAttribute('data-drupal-message-id', id);
    messageWrapper.setAttribute('data-drupal-message-type', type);

    messageWrapper.setAttribute('aria-label', messagesTypes[type]);

    messageWrapper.innerHTML = `${text}`;

    return messageWrapper;
  }

The override is called for the controller's Ajax response, but not for BigPipe's Ajax response.