🇺🇸United States @alison

alison → created an issue.

So, while doing more digging, I uninstalled Mercury Editor, and tried the layout paragraphs experimental "builder" tool (you can enable it on "manage display" rather than "manage form display", for your content type that has paragraphs field) -- and I ran into **similar** though not identical issues -- mainly that there was no floating "edit" panel for paragraph entities that didn't have div.attributes on/around them.

So then I looked at #3223483: Using Twig field value removes lpb-controls and "Choose component" + icon →

And I think my issue isn't like yours after all, sorry! -- doing this has solved my issue (and I tried it with "article" and "container" instead of "div", just to be sure):

{% if elements['#layout_paragraphs_component'] %}
  <div{{ attributes }}>
{% endif %}

The rest of my custom template stuff goes here... then...

{% if elements['#layout_paragraphs_component'] %}
  </div>
{% endif %}

-------
Honestly, I don't think it's super clear that Layout Paragraphs requires the attributes to be "on" an element, it's not enough to just "render" the attributes object, buuuut that's at least partially because I'm frustrated I didn't know :) That said, I'll continue to watch this issue, I hope you find a solution soon!

If there's maintainer support for moving this module into mercury_editor/modules, I can submit a MR!

alison → created an issue.

I'm running into something like this, too -- in my case, no SDC, but I do have very customized paragraph entity templates, sometimes very stripped-down. A bit of a variation in my case: If I have the standard div wrapper in the paragraph template, i.e.

<div{{ attributes.addClass(classes) }}>
  {% block content %}
    {{ content }}
  {% endblock %}
</div>

Mercury Editor works fine. If I don't, if I have more bare-bones paragraph templates (i.e. without this standard div wrapper), Mercury Editor doesn't work -- I get vanishing (and sometimes duplicating?) content, and no floating "edit" panel when I mouse over the content.

(So, I'm not saying it's necessarily the identical issue, but the buggy behavior is very similar, so I'm chiming in anyway!)

@nicxvan For me, it was important to also check my layout/section paragraph type and its template, not just the paragraph types that I place inside the section, if that makes sense -- or, just for the sake of testing, allow placing "card" paragraph entities without layout/section parent paragraphs (i.e. on your node "form display" settings > paragraphs field > uncheck this box: Require paragraphs to be added inside a layout, aka "require_layouts" config).

(sorry for the extra comment) And, is issue #3362776 a requirement / prerequisite for the fix(es) on this issue (#3426739)?
🐛 Inline text editor not working RTBC

Hi! If I wanted to test this, should I try MR 46, or, which MR? Thanks!

Oh I would **love** this feature!!

Sort of workaround: In my testing, the "Done" button (at the top next to "Save"), has the same effect as a hypothetical "Cancel" button, but obviously that isn't clear! -- though it does raise the question of what language will work best for these buttons... Only having "Cancel" would also be misleading.

Functions that a set of buttons could have (i.e. some or all of these, but not these labels) --

1. Save and continue editing
2. Save and exit / view the page
3. Cancel but stay on editing screen
4. Cancel and exit / view the page

Works for me!

More details:

• Tested with Mercury Editor 2.1.0 (Drupal core 10.2.6).
• On "Extend" (/admin/modules), there's now a "Configure" link with Mercury Editor (before applying the patch from #2, there was no such link).
• When I click that configure link, I'm taken here: /admin/config/content/mercury-editor -- success!

Terribly sorry for my mistakes in #14 and subsequent thread clutter!

This new-new patch (#15) only does two things:

• Use spectrum 1.8.0, from the CDN (like #10).
• Re-order the dependency libraries to be alphabetical (like #10).

In my testing, this patch (#15) applies cleanly to 1.1.x-dev, 1.0.x-dev, and 1.1.0, and the Spectrum functionality is working properly on my site.

Issue status

Spectrum is still broken for me (1.1.0 and 1.1.x-dev), because the Spectrum library version and external source part of this issue (and the remaining part of the patch on #10) hasn't been committed/fixed, so that's why I'm posting on this thread rather than a new thread. Of course, I can't change the issue status back to "needs review," so maybe this is a bad idea... but hopefully this will help anyone who stumbles upon this issue in the meantime?

Excessive details you probably don't need

"just in case"...

#15 vs. #10

TL;DR: #10 no longer applied because of two "conflicting" commits:

1️⃣ Commit #5736bd1 (March 19, 2024), which conflicted with #10 because it...

• added the core/once dependency to style_options.libraries.yml
• replaced deprecated use of jQuery once, in js/color-spectrum.jquery.js

This new patch (#15) doesn't make any changes to js/color-spectrum.jquery.js -- in my testing, Style Options + Spectrum work fine on my site leaving this JS file as-is. (I'm guessing the changes to js/color-spectrum.jquery.js in earlier versions of this patch were only necessary with the deprecated jQuery implementation?)

2️⃣ Commit #112a40a (April 21, 2024), which conflicted with #10 because it...

• updated core_version_requirement in style_options.info.yml

In conclusion, this new patch (#15) simply updates the Spectrum library version (1.6.0 => 1.8.0), and uses the external/CDN library.

I did some more investigating!

TL;DR: Attached is a new patch that does "what's left" from #10. In my testing, this patch applies cleanly to both 1.1.x-dev and 1.0.x-dev.

(I can't change the status back to "needs review," but hopefully this will help anyone who stumbles upon this issue in the meantime!)

More details:

1️⃣ Looks like this commit, March 19, 2024: https://git.drupalcode.org/project/style_options/-/commit/5736bd1fa7b7d8...

• does the changes to js/color-spectrum.jquery.js that were in the patch on #10, in a slightly different way, but still does them
• AND it adds the core/once dependency to style_options.libraries.yml

2️⃣ This commit, April 21, 2024: https://git.drupalcode.org/project/style_options/-/commit/112a40a8b843b1...

does the change to style_options.info.yml that was in the patch on #10 (simply updating core_version_requirement)

So, the attached patch does "the rest of what was in #10" (other changes to style_options.libraries.yml).

Is it possible #10 didn't make it in after all?

-------

I don't see this fix in the 1.1.x commit log on GitLab (or the 1.0.x commit log), or in the June 2024 1.1.0 release → (and actually, I don't see a commit link in this issue thread).

So, I looked at the Style Options project on GitLab, and I don't see the changes in any of the relevant files there, either (I figured, sometimes maintainers make the changes manually / in commits not directly tied to issue threads, due to limited time).

benjifisher → credited alison → .

(we worked on the MR together, but I forgot to mark the issue ready for review -- here we go)

The core media embed button is only available if you enable core Media Library (it's not enough to just enable Media) -- but you can allow embedding media entities with just Media.  Updated "When using Video Embed WYSIWYG" > "Prerequisites" to clarify.

I know this was marked as a duplicate, but 🐛 Restrict access to empty top level administration pages Fixed is fixed and, as far as I can tell, included in 10.2, and I still have a "Workflow" link in my admin menu, even with nothing enabled that goes in there, and therefore just takes me to an empty "access denied" page. (FWIW, I'm logged in as user 1.)

Am I conflating stuff, is what I'm describing actually something else and I should submit a new issue, or?

Submitted merge request.

Heads-up: The default branch on GitLab is still 3.x, but I think I set this MR to merge into 4.x -- or I hope so!

alison → created an issue.

So, I'm still not sure if my issue is related, but maybe/probably it isn't -- it's a bit of a clunky, very old site and sometimes, especially when it comes to the webform/commerce/webform_rules/commerce_webform modules that are all in there, I struggle to discern which module is responsible for each part, BUT...

I also had some log messages when I submitted the form -- did you?

ANYWAY, .......I ended up downgrading this module to 7.x-1.6, and that fixed the problem for me. Icky, but effective :( Have you already tried that?

-------

P.S. The dblog messages I got:

Notice: Undefined index: components in commerce_webform_get_products_from_webform_submission() (line 283 of /path/to/mysite/sites/all/modules/commerce_webform/commerce_webform.module).

Warning: Invalid argument supplied for foreach() in commerce_webform_get_products_from_webform_submission() (line 285 of /path/to/mysite/sites/all/modules/commerce_webform/commerce_webform.module).

Notice: Undefined index: sid in commerce_webform_order_create() (line 166 of /path/to/mysite/sites/all/modules/commerce_webform/commerce_webform.rules.inc).

P.P.S. I'm cross-posting this update on 🐛 Submission tokens disappeared and stopped working Active

Any chance you also have webform_rules and/or Commerce (and/or commerce_webform?) -- I started having issues with missing submission IDs, but I have all of these modules ^^

And, do you see anything in "Recent log messages" when you submit the form?

I recently updated webform 7.x-4.25 => 7.x-4.26, and webform_rules 7.x-1.6 => 7.x-1.7. After these updates, my rules that add products to the shopping cart don't work, *and* watchdog/dblog/"Recent log messages" shows notices and a warning that indicate that the submission ID is missing. (I have no recent updates to Commerce or Commerce Webform.)

I tried downgrading webform to 7.x-4.25, and it didn't help, my shopping cart was still broken.
I tried downgrading webform_rules to 7.x-1.6, and (after clearing cache), the problems went away, my shopping cart works again (phew).

So, I'm leaving it at that -- idk if this will help, but, sharing just in case!

-------

P.S. The dblog messages I got:

Notice: Undefined index: components in commerce_webform_get_products_from_webform_submission() (line 283 of /path/to/mysite/sites/all/modules/commerce_webform/commerce_webform.module).

Warning: Invalid argument supplied for foreach() in commerce_webform_get_products_from_webform_submission() (line 285 of /path/to/mysite/sites/all/modules/commerce_webform/commerce_webform.module).

Notice: Undefined index: sid in commerce_webform_order_create() (line 166 of /path/to/mysite/sites/all/modules/commerce_webform/commerce_webform.rules.inc).

P.P.S. I'm cross-posting this update on 🐛 Webform data tokens appear to only work on first reaction Active

I think I'm having the same issue -- not totally sure yet, but I think maybe.

And, I wonder if it could be related to this?
🐛 Submission tokens disappeared and stopped working Active

benjifisher → credited alison → .

(I created a **draft** merge request, just to make it easier to grab + try out a patch of the work so far.)

I applied these changes: https://git.drupalcode.org/project/drupal/-/merge_requests/7309/diffs

Are those the correct changes to try out? I did that, cleared cache, and tried to add hr.special|Special HR to my Styles list, without success. (I also couldn't add it to "Source Editing".) I tried it on a "Full HTML" text format, which doesn't have any HTML tag limits, idk if that's relevant?

(I think I'm probably not using this the way it's meant to be used, but, I'm not sure how to do it.)

Thank you!

alison → created an issue.

I know there are other tasks before this can be RTBC, but just chiming in to say that #74 worked perfectly for us on 10.2.0, thank you so much for the fix!!

I submitted a MR with a new code example, based on something I wrote/used myself earlier today.

(It's not exactly like str_replace, simply because the code examples in dom_str_replace are structured differently -- with less extensive explanations -- and I didn't restructure what's in dom_str_replace. So, that's why that is.)

(See "Issue summary" > "Proposed resolution" for an alternative idea.)

alison → created an issue.

I think this issue (#2998318) and 🐛 FilterHtmlImageSecure filters out valid local svg images Needs work may be duplicates of each other.

I think this issue (#2855653) and 🐛 "Restrict images to this site" restricts images that, by definition, *are* on this site. Needs work may be duplicates of each other.

I ran into this today, while trying to fix a bunch of alt attribute values that people left with meaningless placeholder values (and they should really be empty anyway).

This worked, on line 95 -- h/t @danflanagan8 on Slack:

if (!(array_key_exists($option_name, $this->configuration))) {

But I can also see the merit of @koosvdkolk's suggestion in #2, because (again, h/t @danflanagan8 on Slack), maybe no other options should be allowed to be empty?

Probably we need maintainer input on this!

@Wim Leers I can take a stab, is the idea that it would get added as a new drupal-ckeditor plugin in here?
web/core/modules/ckeditor5/js/ckeditor5_plugins/

(aka here: https://git.drupalcode.org/project/drupal/-/tree/11.x/core/modules/ckedi...)

benjifisher → credited alison → .

I just started using #19 to do identical processing on a bunch of rich text fields and I'm in love, this feature is absolutely wonderful, THANK YOU!!

The status is "Needs work" not "Needs review," so I won't change it to RTBC, but do y'all know what's left needing work, or maybe can we move this to RTBC........?

Thank you for all the work on this issue!

I tried the patch on #69 on 1.x-dev this evening, and:

• It applied cleanly.
• When I ran node migrations with --update, nodes for which "Generate automatic URL alias" is disabled on my Drupal 7 source site now have this checkbox disabled on my Drupal 10 destination site 🎉
• When the source node had that ^^ box unchecked, and if I change the alias value (from the node form), and then re-run the node migration on the Drupal 10, so far, I'm not seeing the custom alias show in the URL alias field on that same node's node edit form in Drupal 10.
• I haven't tested any non-node migrations.

I'm not totally certain of the intended behavior, so I won't say if it's working or not working :) The issue summary might need an update, but that could just be my relative unfamiliarity with the issue.

I do have a question: Can the changes in this patch be used to disable "Generate automatic URL alias" during a node migration? Like, is there anything in the new/updated process plugin(s) that would let me set that field value in the process section of my node migration?

About me:
- Drupal 10.2.0
- Pathauto 1.x-dev (from this evening)
- Using "classic" node migrations, not "node complete"
- Preserving node IDs, not migrating revision history, not preserving VIDs.
- Not a multilingual site
- (Anything else?)

alison → created an issue.

Just in case it's at all helpful to anyone who stumbles upon this thread... Here's what I did:

1. I started with the instructions on the project page: https://www.drupal.org/project/migrate_file_to_media →
2. BUT, in the generated “step1” migration, I modified the source plugin to media_entity_generator_d7
3. Then, after importing the migration configs...
4. I ran
   drush migrate:duplicate-file-detection cwd_migrate_cvm_mf2m_canine_image_step1
5. Then
   drush mim cwd_migrate_cvm_mf2m_canine_image_step1
6. Then
   drush mim cwd_migrate_cvm_mf2m_canine_image_step2

I didn't do the "everything in one go" option (i.e. I didn't add the media_file_copy process that's in the D7 to D7 example YML), because we need all files migrated over for this migration, not just files referenced in file fields (therefore, we're just using upgrade_d7_file from Drupal core to do the file entity migration).

-------
Anyway, hope this helps!

Patch #4 worked perfectly for me, too! +1 for RTBC

MR has conflicts even with 9.x (but also needs to be redone against 11.x) -- anyway, adding "needs reroll" tag (right?)

At the risk of causing confusion...... #27 fixed our issue of "if page.region_name" being "incorrectly" evaluated as true. We haven't used any of the twig workarounds, nor have we added/used the core patch on 🌱 [meta] Themes improperly check renderable arrays when determining visibility Needs work .

Does that track with what folks expect this patch to do? (I'm very pleased haha, I was just rereading the issue summary today, and I wasn't sure if I lost track of what was meant to be addressed in this issue vs. the core issue.)

-------
Put another way...

Page template excerpt -- "sidebar_primary" is a region that contains a menu block:

      {% if page.sidebar_primary %}
      <div id="sidebar-top" class="secondary">
        {{ page.sidebar_primary }}
      </div>
      {% endif %}

Without the patch (#27), the resulting markup is this:

<div id="sidebar-top" class="secondary"></div>

With #27, the div simply isn't there 🎉 And that's certainly what I was hoping for, but...

Does that fit with everyone's intentions/expectations? -- even without the twig filter workarounds?

alison → created an issue.

+1 for restoring this capability! And meanwhile / regardless, thank you SO MUCH for this module!!!!!!!!!!

You're welcome, thank YOU!

I had an issue where block configs for a ton of my blocks, including content blocks, were failing to come in. MR #3198 fixed that problem, all my blocks that are content blocks migrated properly 🎉 A few remaining issues, and I don't know if they're related to *this* issue! -- and I don't have a ton of info yet, I just tried the patch on Friday, I'll continue hammering away at the remaining missing blocks this week and share more if I have more to share --

Meanwhile, my remaining issues that may or may not be relevant to *this* issue:

• "Seven" blocks came in with "seven" in the block machine name, but "claro" in the actual theme setting in the block.
  • In other words, the block machine names are, for example seven_user_login (but the theme setting is "theme: claro", as it should be -- so the blocks are properly configured, it's just the wrong theme name in the machine name).
  • Definitely not the end of the world, but, sharing!
• Views blocks didn't come in.
• Menu Block module blocks didn't come in.

alison → created an issue.

I came across a couple other "site building things" that don't migrate smoothly / out-of-the box due to not being in the source site database when they're in Features (image styles, views), and posted about it here:
https://www.drupal.org/forum/support/upgrading-drupal/2024-01-24/upgradi... →

Mainly, I'm just sharing in case it's helpful to others, but if anyone's run into other "site building things" that behave like that, I hope you'll comment on the Forum thread!

#16 worked great for me!

More specifically:

• It applied cleanly for me on core 10.1.
• I successfully regenerated my node type migration (I'm using migrate-upgrade).
• I ran the node type migration with --update, and the menu settings came in properly 🎉
• I enabled a custom menu for one of my content types and re-ran the node type migration -- that menu setting came in properly, too (goal: test with a menu that isn't specifically mapped).

Thank you for the fix!!

I know this is both old and has up-in-the-air elements to it, BUT, I successfully applied MR #849 to a Drupal 10.1 site, and then successfully migrated users of just one role. (I only applied the changes in MR #849, I didn't grab anything from #2833060 🐛 SqlBase::prepareQuery() should be called also on count Needs work .)

I did get warnings when I ran drush mim, but it still ran successfully -- but I'll share them anyway:

 [warning] Undefined array key "conditions" SqlBase.php:365
 [warning] foreach() argument must be of type array|object, null given SqlBase.php:365
 [warning] Undefined array key "joins" SqlBase.php:370
 [warning] foreach() argument must be of type array|object, null given SqlBase.php:370
 [warning] Undefined array key "fields" SqlBase.php:375
 [warning] foreach() argument must be of type array|object, null given SqlBase.php:375
 [warning] Undefined array key "conditions" SqlBase.php:365
 [warning] foreach() argument must be of type array|object, null given SqlBase.php:365
 [warning] Undefined array key "joins" SqlBase.php:370
 [warning] foreach() argument must be of type array|object, null given SqlBase.php:370
 [warning] Undefined array key "fields" SqlBase.php:375
 [warning] foreach() argument must be of type array|object, null given SqlBase.php:375

My very rough take on those warnings is that they mean my conditions syntax could/should be better. (I copied from one of the code examples in SqlBase.php, but maybe I certainly may have misinterpreted it.)

Speaking of which, here's the "source" section of my user migration YML:

source:
  plugin: d7_user
  joins:
    -
      table: users_roles
      alias: ur
      condition: u.uid = ur.uid
  conditions:
    -
      field: ur.rid
      value: [6]
      operator: IN
  distinct: TRUE

#5 fixed the issue for me (PHEW).

I stopped by to say I have this issue with other types of migrations (view modes, field instances) -- looks like y'all already accounted for that, though! -- but, issue could use a title and summary update, I think? (but I'm too anxious to add that tag myself :) )

ANYWAY. Thank you for the fix!! -- it applies cleanly and does the trick on Drupal core 10.2.0, btw (I haven't tried on 11.x).

Thank you! -- in case it helps anyone else who stops by this thread, my process for using the generated migrations was (and idk if this is best / correct, but it ended up working for me):

TL;DR: Run the field group migrations after field, field_instance, and field_instance_widget_settings migrations.

More specifically, this was my order of things:

1. Run some migrations that tend to be dependencies of node/content migrations:
   
   1. upgrade_d7_user_role
   2. upgrade_d7_filter_format
   3. upgrade_d7_node_type
   4. upgrade_d7_user
   5. upgrade_d7_field
   6. upgrade_d7_view_modes
   7. upgrade_d7_taxonomy_vocabulary
   8. (then specific taxonomy/vocab migrations)
2. Then...
   
   1. upgrade_d7_field_instance
   2. upgrade_d7_field_instance_widget_settings
3. Then, "field group" migrations, i.e. upgrade_d7_field_group_node_news
4. P.S. It also worked when I ran the field group migrations before the field instance widget settings migrations (accidentally, but it worked).

OH! Never mind, I see it now!!

@kevinquillen What's the reason for putting the features modules into the Drupal 9 site codebase? I'm missing where/how that part fits in.

FWIW, I tried the patch on #13 applies cleanly and fixes the bug for me (on core 10.1) 🎉

(Sorry for the comment noise due to me not thinking to try it before posting my previous comment........)

I'm actually running into this bug not just with the "preview" but with my view block display as shown on my site -- but y'all are only running into this bug with the view preview? (I'm trying to figure out if I've run into the same bug or something different.)

(Or maybe it's not just me, per @tjmoyer over here: https://www.drupal.org/project/drupal/issues/3265798#comment-15159116 🐛 [view:total-rows] problem in Display a 'Specified number of items' pager RTBC )

About me:

• Drupal 10.1
• View block display with "display a specified number of items" (I reduced it to "1" for testing)
• More link: Yes ("always show" unchecked -- but when I check it, it does show)
• Link display: Custom link (b/c we've got custom argument stuff going on)

When I view a page where the view block display is placed, the "more" link doesn't show unless I enable "always show." Furthermore, we happen to still be working on the Drupal 10 upgrade for this particular site, so I can see that the "more" link behavior works fine on the Drupal 9 version of the site, and is broken on the Drupal 10 version of the site.

We've been using 2.x releases for a while, so I'm inclined to just downgrade to 2.0.0-rc9, rather than to 1.x.

But, I see others saying it went fine for them to go to 1.x (thank you for that!), I just feel anxious about it. Still thinking, just, sharing my "thinking out loud."

@AvO WebWorks Is the module working for you in Drupal 10, or just installing cleanly?

@robcarr The psr/cache error you're seeing is during composer tasks, or when actually using the DOI lookup functionality in your site?

I agree that the issue shouldn't be considered "fixed" if we can't use "core-recommended".

-------

But also, when we do all the fiddling to composer-install the latest dev version of this module on a Drupal 10.1 site, we get a WSOD + fatal error when we try to use the DOI Lookup tool, so that's why I'm wondering if the module is really working for you, @AvO WebWork, or is it just composer-installing? I'm not sure if this error we're getting belongs in this thread, a new thread, or the renanbr/crossref-client project, I welcome advice on that front -- I do know that the module definitely isn't working for us on Drupal 10.1 🙂 Here's the fatal error (seen on /admin/content/bibcite/reference/lookup) -- we can re-file elsewhere if necessary, I just didn't want to say "it's not working for us but I'm not going to tell you any details":

Fatal error: Declaration of RenanBr\CrossRefClient\RateLimitProvider::getLastRequestTime() must be compatible with Concat\Http\Middleware\RateLimitProvider::getLastRequestTime(Psr\Http\Message\RequestInterface $request) in /code/vendor/renanbr/crossref-client/src/CrossRefClient/RateLimitProvider.php on line 37

FWIW, with MR 15, database updates run smoothly for us 🎉

(Anyway, setting issue status to Needs review.)

alison → created an issue.

Thank you for the share @flyke! We might end up in that boat eventually, it's good to hear it was pretty doable for you.

-------

General update for the class:
It turns out, when I recreate the sitemaps (post upgrade), if I use the same machine name as what existed before the upgrade, the inclusion/bundle settings are right there when I go to /admin/config/search/simplesitemap/entities (more specifically: /admin/config/search/simplesitemap/entities/node -- I haven't tested any other entity types or custom links, we're only including nodes).

Soooooooo kinda uncomfortable to be honest, that the sitemaps were "gone" but the settings still "there" -- but I guess I'll take it??

I took a very quick swing at updating composer.json and README (MR 15) -- also, the fork was created off of the 1.x branch, ugh, so there's an extra branch in there (I tried to delete it but couldn't, maybe someone else can -- the branch to delete is called 3400936-simplesitemap-version-compatibility).

IMPORTANT: This change shouldn't be merged until after ✨ Make compatible with simple_sitemap 4.0 & domain_entity Needs review is done -- I'm still setting it as "needs review" for now, to get input and whatever, but after review, it'll need to be on hold until the simple_sitemap 4.x compatibility fixes are done 🙃

QUESTION: Should we also set a conflict key in composer.json, or just the version constraint in the require section?

alison → created an issue.

I'm experiencing this issue, too! -- updated viewsreference 2.0.0-beta6 => 2.0.0-beta7, and the only "extra settings" I can enable are Argument and Pagination. I checked on an environment that still has beta6, and on that environment, I can enable/disable all the "extra settings" checkboxes.

• My field is a simple viewsreference field on a node, no Paragraphs involved.
• I don't lose the other "extra settings" in the node edit form until I save the field settings -- until I save the field settings (and lose the "extra settings"), the "Include View Title" checkbox still still shows in the node form. (That said, I haven't tried enabling that checkbox to see if it "works" or if it's just "there" -- and I'm afraid at this point I just need to roll back the update and carry on with work, I can't do that test right now -- but I figured I'd at least share what I saw!)
• I don't see anything in watchdog/drupal logs.

FWIW, I'm still on Drupal 9.5.11 (PHP 8.1).

In a development environment -- specifically, a Pantheon multidev...

I tried manually recreating the default sitemap for this site, and sitemaps for two of the many (many) domains configured for this site, then I generated them.

1. Previously (see comment #64): I did "generate domain's sitemap variants" here: /admin/config/domain/domain_simple_sitemap/config -- and then I saw "sitemap types" for each of my domains.
2. Then (today), I added new sitemaps (one for the default domain, and two others) -- from here: /admin/config/search/simplesitemap
3. Then, I went to "Inclusion," and configured the "content" entity type to match the settings we have on prod (including/excluding various content types): /admin/config/search/simplesitemap/entities
4. Then, based on comment #63, I deleted the "Default hreflang sitemap" sitemap type.
5. Then, I queued/generated the sitemaps, here: /admin/config/search/simplesitemap

And, they did get generated, or, I think they did? There are WAY more links in each sitemap than how many links are in the sitemaps on the live site, and also, the sitemap links go to the prod URLs -- like, I see the three sitemaps I created when I go here (plus "Sitemap index" which is "disabled"):
/admin/config/search/simplesitemap
But the link counts for each are higher than the "max_links" setting (which is the default: 5000) -- and, each sitemap link goes to the prod domain URLs. Even if I manually navigate to the dev URLs, with "sitemap.xml" tacked onto the end, the links are prod URLs.

THAT SAID, I'm looking at another multidev, with the prior versions of domain/simple_sitemap/domain_simple_sitemap, and, while the sitemap links over there are the dev URLs, the links inside the sitemaps are all prod domain URLs -- so maybe that part is fine?? (I'm really hoping y'all have more experience with multiple domains + sitemaps than I do 🤞)

Even so, the number of links in the sitemaps is concerning, I think? (way higher than the live site, and the 5000 max setting) -- really, overall I just feel really unsure and apprehensive, like, if this is the kind of thing that simply doesn't quite work on a dev environment, I can mostly accept that, but I don't know what I should be seeing / I don't know how to know if things are going to work correctly on the live/prod site.
>> I did try the "remove_duplicates" checkbox, but after regenerating, the link counts per sitemap were still just as high.

And, I do still wonder if I'm supposed to have to rebuild everything manually, or if the sitemaps should've still existed after I upgraded the modules and ran database updates, y'know?

Sorry, I know I'm rambling, I just feel pretty lost 😖

-------
FWIW: I do know the dev subdomains are configured fine because I tested them after adding them to the Pantheon multidev -- I can get to the dev URLs for the two domains I configured on this environment, and I see the "test edits" to content that I made on that environment, when view content on these dev domains.

I'm trying the latest patch (#53), and I'm wondering... am I supposed to have to recreate all our sitemaps?

(I'm on Drupal 9.5.11)

What I've done so far:

1. Add the patch in #53 (in our case, that means adding it to composer.patches.json)
2. Update modules:
   • drupal/domain (1.0.0-beta8 => 2.0.0-beta1)
   • drupal/domain_simple_sitemap (dev-2.x 198f364 => 2.0.0-beta1)
   • drupal/simple_sitemap (3.11.0 => 4.1.7)
3. Run DB updates
4. At that point, I saw no sitemaps or sitemap types.
5. Then, I did "generate domain's sitemap variants" here: /admin/config/domain/domain_simple_sitemap/config
6. Now, I see a "sitemap type" for all my domains.
7. Still there's only the "Sitemap Index" sitemap here: /admin/config/search/simplesitemap.
8. I tried clicking "rebuild queue" and "rebuild queue & generate" on that same admin page -- no dice. (Logs say "The XML sitemaps have been regenerated." and there are no errors.)

Do I need to recreate them all...? -- if yes, okay, but obviously I wanted to check first! (and obviously I'm hoping I'm mistaken 🤞🤞)

FWIW, we were running a pretty old version of domain_simple_sitemap dev-2.x -- I mean, it's still the 2.x branch, but maybe we missed an upgrade path along the way between dev-2.x 198f364 and 2.0.0-beta1...?

-------

P.S. Specific steps I took for updating the modules, in case it matters:

$ composer require drupal/domain:^2.0@beta drupal/simple_sitemap:^4.1 drupal/domain_simple_sitemap:^2.0@beta --no-update
$ composer update drupal/domain drupal/simple_sitemap drupal/domain_simple_sitemap

Hi all! Following up on a Slack conversation...

A "solution" some of my colleagues came up with -- not going to be a broadly helpful solution, but it might help some folks who come across this issue (note: see "Limitation" below!) --

TL;DR: We're using optgroup elements, and repeating the first/parent item, so that there's a "selectable" version of that parent item (optgroups themselves aren't selectable).

⚠️ Limitation: You can't nest optgroups, so this solution only works with one hierarchy-level, so to speak. As such, it isn't a solution for menus, and it won't work with "has taxonomy term (with depth)" situations with more than 2 depth levels. So, like I said, it's not going to be helpful for actually solving this broader issue, but I'm sharing anyway, in case it helps someone with a comparable use case!

-------

All the details are in this "optgroup demo" gist. (Let me know if you have any questions -- I'll see updates here, but the quickest way to reach me is on Drupal Slack: @alison)

I think we can close 🐛 Empty blocks get displayed Needs review as a duplicate of this issue (#3271218)?

And maybe add contrib credit here, for folks who contributed over there.

I think this issue might could be closed as a duplicate of 🐛 Menu block renders when tree is empty as of 8.x-1.8 [regression] Needs review

It's tough, they were both opened at almost the same time, but I don't think we need both 😖

And #3271218 has been added to #3318811: [META] Plan for Menu block 8.x-1.11 release →

@shelane I see that the patch in #3271218 didn't work for you last year -- I wonder if the latest patch on that issue might work for you? ( https://www.drupal.org/project/menu_block/issues/3271218#comment-15268732 🐛 Menu block renders when tree is empty as of 8.x-1.8 [regression] Needs review )

Either way, though, I think the issues should be consolidated -- maybe a maintainer will add contrib credit for folks who've contributed to this issue (not my call, lucky for me 😆).

@banoodle I think your best bet is to open a new issue -- possibly linking to this issue for context!

(That said, I still see the functionality in the module code and in my site usage. Make sure you have the "Display title" checkbox checked in the menu block settings form, just as a starting place -- that checkbox shows/hides the new "Use as title" field, which is inside the "Advanced Options" fieldset. But if you still don't see the setting, I recommend opening a new issue, maybe with the "support request" category (or "bug report").)

alison → created an issue.

I can see that declaring a single default/official/recommended tool could help someone coming in literally on their own (i.e. not part of a team that has input on what tool they use), who sees two choices and is like "er, ok but, now what? how am I supposed to pick??" To me, it's a not-nothing consideration, but not enough of a reason to recommend a single tool. So far, I don't see other ways it'd help less technical users more than "knock out some very old recommendations [...] by presenting a couple of good starting points for developers" (@wells #74) would help less technical users.

And, I think declaring one recommended tool will definitely have other effects. I think with these kinds of things (like SO many other tech things) (and non-tech things), people have their preferences and comfort zones, and a declaration like this would be something some folks would point to when trying to insist that the tool they use is Better and not just Better, significantly better, and their colleagues should all have to switch.

More importantly, I think one tool being officially recommended does imply more than just "we narrowed it down for you," I think it implies Drupal expects there will be better ongoing support of that tool. I don't think anyone is saying ddev is better supported than lando (right?), but I think it's a reasonable thing for a team lead to think if they see this kind of official/default recommendation -- and meanwhile, I think the implication alone can be a self-fulfilling prophesy (i.e. implying one is better leads to less use/support of the other).

Yes, I'm primarily a lando user. I've used ddev, I have no complaints, it's excellent, and, lando is what's comfortable for me -- and lando is also excellent (I don't think anyone's saying "lando is garbage"). And, I know no one's going to take lando away from me, BUT, as others have said, I don't think making a declaration like this will help less technical users -- I'd add, I don't think it'll help less technical users enough to outweigh the side effects on the local dev ecosystem overall.

-------

Extra thoughts:

@kevinquillen #73:

This would remove the guesswork and high difficulty of even trying to run Drupal on your own.

Totally agree, but as I say above, I don't think it's worth the effect it'll have on the ecosystem. (But removing outdated docs, yes please!)

@wells #56:

My only concern here is... what is the real different between "official" and "default". Obviously the two words have different meanings but if we're talking about changing every instance of documentation to use DDEV as the default the practical difference seems almost non-existent.

Agree.

@wells #63:

DDEV and Lando at least have their own primary references for how to get started in Drupal. Instead of defining a default could Drupal's documentation point directly to those sources for each tool?

Agree -- and, I really like the language suggested in #72 ✨ Recommend DDEV as the default Drupal local development environment Active (@wells)

Fabulous, thank you @Fernly!

FWIW, the patch in #34 does apply fine to 10.1!

I attempted to adjust the tests so it runs against 10.1.x, too; I hope I did it right, if not, ...oops and I hope it doesn't cause a hassle, I gave it a shot 🤞

#69 doesn't apply to Drupal 10 (10.0 or 10.1), because (as far as I can tell), processDate() isn't there anymore -- as of #3256549: Deprecate core/drupal.date asset library in 9.4.0 → .

I can't tell if this issue is still needed for Drupal 10 (but with a rewrite), or if it can be closed (given that Drupal 9 EOL is coming up in less than a week)?? -- I poked around a bit, but I'm just not sure where to look.

Wow, I was so so so so confused as to why four content types' field groups had migrations and no others! (because, Features were maintained for a while after this site was built but not forever, so there are content types and stuff with outdated or zero features)

Thank you everyone on this thread for sharing, and thank you @kevinquillen for the solution share! -- I haven't tried that part out yet, we're in a discovery phase, but I'm adding this to my notes for when we get to implementation.

benjifisher → credited alison → .

#11:

What about the case to remove the role if there is a figcaption present? It seems to trip the validators right now.

See also: 📌 Remove role="group" from figure in FilterCaption output Postponed: needs info

(in case other people find themselves here)

Maybe this issue is close to 🐛 Dynamically instantiated CKEditor 5 instance's toolbar occludes Drupal's toolbar if it has focus and the form is part of paragraph Active ? -- although in that case, the issue only happens when CKEditor 5 isn't present when the page initially loads, so maybe not??......

Hi! So I reproduced this issue in Drupal 9.5.10, and in Drupal 10.1, under slightly different circumstances -- but I think the key detail is still valid: CKEditor isn't there when the page initially loads.

FYI: These steps are based on when I reproduced the issue in a plain DrupalPod workspace with Drupal 10.1 and the Umami install profile.

1. On a Drupal 9.5.10 or Drupal 10.1 site -- ...
2. Go to Text formats and editors: /en/admin/config/content/formats
3. Drag "Plain text" to the top of the list, so it'll be the default/active text format when you create a new node.
4. Create a new Basic page.
5. On the body field, switch the text format to "Basic HTML"
6. Put a ton of content in the body field, so the CKEditor field is taller than the viewport.
7. Behold: CKEditor toolbar is "on top of" the admin menu.

Attached: Screenshots of this behavior, in Drupal 10.1 and Drupal 9.5.10.
→ →

-------

@vermario Do you have the admin_toolbar module enabled? -- to be clear, I reproduced the issue we're talking about here with and without the admin_toolbar module. BUT, when CKEditor 5 is present when the page initially loads, I have another issue (maybe unrelated!!): The CKEditor 5 sticky toolbar obscures admin_toolbar drop-down menus ( example → ). Again, I really, really don't know if it's the same issue, but, just wondering if you happen to have that issue, too (if you have admin_toolbar).

@Wim Leers Yeppers!

• Drupal core 9.5.10
• Editor Advanced Link 2.2.4
• (Also in the mix: Linkit 6.0.0 -- I did try disabling Linkit, the errors still happened; only thing that cleared the errors is disabling editor_advanced_link functionality on that text format.)

Do you / do y'all think it's noteworthy that the errors only happen on a text format with "limit allow HTML tags" enabled? -- I did try adding stuff to the allowed tags list (by way of "source editing" > "allowed tags" list), but I still got errors. But maybe (hopefully?) I just didn't add everything it needs? (meaning, maybe the EAL module doesn't automagically add all the necessary tags when you enable that button)

(Attached: filter + editor config yml for my filtered_html text format, in case it's useful.)

Apologies if this is an unrelated issue, no scope-creep intended -- and if that's the case, I'll open a new issue -- it just "felt related" --

I'm getting Uncaught CKEditorError: collection-add-item-invalid-index any time I try to add a link in CKEditor 5, in a text format with "Limit allowed HTML tags and correct faulty HTML" enabled -- do y'all only have the issue you're seeing in text formats with "limited allowed HTML" enabled, or also in a text format that allows all HTML tags?

More about me:

• Drupal core 9.5.10
• Linkit 6.0.0 -- I did try disabling Linkit, the errors still happened
• Editor Advanced Link 2.2.4 -- then I tried disabling Editor Advanced link, errors went away (and linkit worked fine)

More error stuff:

Uncaught CKEditorError: collection-add-item-invalid-index           ckeditor5-dll.js?v=35.4.0

Read more: https://ckeditor.com/docs/ckeditor5/latest/support/error-codes.html#error-collection-add-item-invalid-index
    at i.addMany (ckeditor5-dll.js?v=35.4.0:5:525625)
    at i.add (ckeditor5-dll.js?v=35.4.0:5:525522)
    at editorAdvancedLink.js?v=9.5.10:1:11273
    at Array.forEach (<anonymous>)
    at h._addGroupsToFormView (editorAdvancedLink.js?v=9.5.10:1:11167)
    at Ke.<anonymous> (editorAdvancedLink.js?v=9.5.10:1:10076)
    at Ke.fire (ckeditor5-dll.js?v=35.4.0:5:502334)
    at Ke.set [as visibleView] (ckeditor5-dll.js?v=35.4.0:5:508922)
    at Ke._showView (ckeditor5-dll.js?v=35.4.0:5:462705)
    at Ke.add (ckeditor5-dll.js?v=35.4.0:5:460104)

(1) Oops, screenshot mistake -- uploaded the correct "problem shot" this time -- will edit my previous message to link to the correct "problem shot" (and removed the mistake screenshot from being displayed).

(2) RIGHT after I commented, I found these 🤦‍♀️
https://www.drupal.org/project/drupal/issues/3259380 →
https://www.drupal.org/project/drupal/issues/3348132 🐛 Dynamically instantiated CKEditor 5 instance's toolbar occludes Drupal's toolbar if it has focus and the form is part of paragraph Active

But I still have the problem -- maybe it's because I'm on Drupal core 9.5.10, but I thought the fix in #3259380 was for 9.x.

I'll ask on Slack and report back.

I came across this while searching for an existing issue -- I'm experiencing the same thing with the regular core admin menu + admin_toolbar + admin_toolbar_tools (Drupal core 9.5.10, CKEditor 5, Admin Toolbar 3.4.1) -- so maybe it does belong in the CKEditor 5 issue queue?

Screenshots attached.

• No problematic overlap at first: https://www.drupal.org/files/issues/2023-08-22/admin-menu-cke5-sticky-to... →
• Then, when the CKEditor 5 toolbar becomes "sticky" (i.e. when I scroll down in the editor), the problematic overlap happens: https://www.drupal.org/files/issues/2023-08-22/admin-menu-cke5-sticky-to... →

I tried applying the changes in commit #a91193b to my site, running Gutenberg 2.7.0, and the patch applied fine, but I don't have any checkboxes for my custom Gutenberg blocks on the content type settings form.

(Is it still in-progress, that's all, or?)

Thank you!

Has anyone migrated from wysiwyg_template to ckeditor_templates? (if yes, do you have advice?)

volkswagenchick → credited alison → .

volkswagenchick → credited alison → .

volkswagenchick → credited alison → .

laura.gates → credited alison → .

laura.gates → credited alison → .

Progress made, not done yet. Few questions:

Question 1:
I ran into something I didn't expect -- inside the parameter description lists, I couldn't use ` marks to format text as "code" (regular code HTML tags worked, but not the backticks). In other words, the following does not work, in the cheat-sheet.md file:

  <dt>`$name`</dt>

The following does work: (imagine no "spaces" in the code tag) (I got tired of fighting with this editor to output the literal code tag inside the code snippet)

  <dt>< code >$name< /code ></dt>

Not the end of the world, but it made me wonder:
Is there a different way I should add parameter details in markdown, rather than the description lists as they're done in Drupal docs?

Question 2:
File URI - this bit:

Media fields are fully supported including OEmbed resources, in which case it will return the URL to the resource, ...

It should be "it will return the URI of the resource", correct? -- just wanted to gut-check it before changing.

Question 3:
File URL - the last section of this one, under this text: "It is also possible to extract file URL directly from an entity."

The code examples are:

{{ image|file_url }}
{{ media|file_url }}

Is the first example, {{ image|file_url }}, meant to demonstrate getting a file URL from an image file entity, or from a media entity that's a "media type called image"?

(Depending on your answer) I suggest adding a comment before each one, i.e.

{# On an image file entity: #}
{{ image|file_url }}
{# On a media entity: #}
{{ media|file_url }}

Question 4:
File URI and File URL: The 2.x cheat sheet section on File URI starts with "Returns a file URI string." -- thoughts/feelings on adding this to the 3.x version? (If yes, I'll also add to the File URL section, "Returns a file URL string.")