🇺🇸United States @alison

alison → created an issue.

Okay I'm done editing now, I promise...

alison → created an issue.

I'd also love to have this functionality as part of the module, FWIW! -- meanwhile, thank you @j_s for developing and sharing!

My workaround so far was to add a twig computed field, and hard-code the prices per number field, and do multiplication behind the scenes..... but then I have to skip all the nice "Price" fields and only send "total price" (based on the twig computed field) to the webform_product handler, and my "cart" only shows one item, rather than an item for each thing on my webform that has a price.

Our JSON source migrations are also still broken, on 6.0.4, and fixed/fine when we revert to 6.0.2.

I wasn't able to apply MR 102 or 103 to 6.0.4, I haven't tried with 6.0.x yet, I was pausing first, because GitLab says the pipelines failed with those anyway (but I might still try).

(I'm afraid I don't have other ideas to contribute!)

Changing status back to "Needs work" (sorry for the issue notification clutter!)

Hmmm actually, I still can't enable commerce_webform_order or commerce_webform_order_demo via Extend (in Drupal admin UI) -- it says this (same as in the issue summary):

Machine name: commerce_webform_order
Version: 3.0.0
Requires:

CommerceAddressFieldEntityInline Entity FormTokenDatetimeViewsFilterUserSystemCommerce CartCommerce OrderCommerce PriceCommerce StoreOptionsTextPathPath aliasCommerce Number PatternEntity Reference RevisionsProfileState MachineCommerce ProductCommerce CheckoutWebform (>= 6.1) (incompatible with version * ? *)

Required by:

Commerce Webform Order Demo (disabled)

Attached is a screenshot of what I see on "Extend," after updating to commerce_webform_order 3.0.0 (which includes the commit 2ebe4ca6).

("incompatible with" is in red, and the checkbox next to both "commerce webform order" modules is disabled)

(but, I can enable these two modules via Drush)

Thanks! When I updated to 3.0.0, and when I ran updb, I still got this error:

 [error]  Commerce Webform Order requires this module and version. Currently using
Webform version
 (Currently using Unresolved dependency Webform (Version >= 6.1 required)
)

But then the DB update did seem to run successfully ¯\_(ツ)_/¯

I tried enabling a random other module, and uninstalling that random other module, and I didn't get any errors, soooo maybe it's fine?? I don't know why it still complained about the webform version, but I can live with it, if it's ok now. And I know how to band-aid it if it gives me trouble down the road.

@goose2000 So sorry, I definitely thought I posted this -- I commented out the webform module dependency in the info yml file, and that hacky workaround has been working for me. Literally, I comment out this line:

- webform:webform (>= 6.1)

So, the dependencies section of commerce_webform_order.info.yml on my project looks like this:

dependencies:
  - commerce:commerce (>= 2.19)
  - commerce:commerce_cart
  - commerce:commerce_checkout
  - commerce:commerce_order
  - commerce:commerce_price
  - commerce:commerce_store
  # - webform:webform (>= 6.1)

So far, I'm able to use the module fine (knock on wood).

Later, when I updated an unrelated module, I did get an error when I ran database updates via drush -- but it didn't block me from running database updates:

drush updb
 [error]  Commerce Webform Order requires this module and version. Currently using
Webform version
 (Currently using Unresolved dependency Webform (Version >= 6.1 required)
)
Requirements check reports errors. Do you wish to continue? (yes/no) [yes]:
 > yes

(and then I carried on)

P.S. Slightly shortening the title edits I made in my last update.

I get this same problem, I have the same versions of everything as you've specified in the issue summary.

Workaround: I was able to enable it via drush, i.e.
drush en commerce_webform_order

(After running that, commerce_webform_order and commerce_purchasable_entity were enabled.)

I know that's not an option for all environments, but, sharing in case it helps. If drush isn't an option, I wonder if you could manually update core.extension.yml and enable the module via config import?

Caveat: I've only just enabled it, I haven't tried using it yet, not sure if I'll run into issues -- I'll report back if I have anything to report!

P.S. I tried enabling commerce_webform_order_demo via drush, no luck with that one -- got this:

$ drush en commerce_webform_order_demo

In UnmetDependenciesException.php line 100:

  Configuration objects provided by <em class="placeholder">commerce_webform_order_demo</em> have unmet dependenci
  es: <em class="placeholder">webform.webform.cwo_demo_subscription (webform_entity_handler)</em>

P.P.S. Adding more specifics to issue title.

Thanks so much for sharing @sethhill! We've paused on our internal project to experiment with Mercury Editor, but I've got this saved for if/when we finally circle back to that effort (🤞🤞). And meanwhile, I'll share this with the other person I know who's been experimenting with Mercury Editor.

A little rewording in the warning box about using downloaded patch files / not using GitLab MR patch file URLs; also some rewording around references to this warning.

Among other things, I moved the last sentence in the warning box to the start of the warning box, because I think it's the most straightforward of all the sentences in the box :)  (I think the other sentences are valuable, too, I just think this one is the best "first sentence".)  This is the sentence I mean:

If you use the URL to the Gitlab MR directly, your codebase will change without warning, as people work on the merge request.

• Also, I added a heading for this warning, so it's in the "on this page" navigation. (Although, I don't love the heading text I came up with, I hope someone comes up with something better!)
• I left the anchor in the warning box, to preserve existing links to it.
• I added a mention of the "Local patches" section of the Drupal Sun article.

-------

❓ Thought: Maybe the warning box content could be shortened to just a couple sentences? -- for example:

The contents of merge request patches on GitLab will change as commits are pushed!

If you use the URL to the GitLab MR patch file directly, your codebase will change without warning, as work on the merge request continues.

And the rest could be regular paragraph text after the box?

Main purpose of this edit: Update language and one screenshot to reflect current button/link text on GitLab -- now, it's the "Code" drop-down (not "Download"), and it's "Patches" and "Plain diff" (not "email patches").

Other changes:

• Add links to full screenshot files (and alt text to those images, since they are now linked).
• Rewrite the instructions for using the "plain diff" link on drupal.org issues, with more specific landmarks, so it's easier to find, especially for screen reader users (note: I don't mean literal aria landmarks).
• Add "or add .diff" to the instructions for getting patch files from GitLab.
• Add ".patch versus .diff" before the section that explains the differences between these patch file options.
• Make minor typo/grammar/capitalization fixes (gitlab to GitLab, url to URL, some additional commas for clarity)

-------

I didn't touch the "Patch files for use with Composer" section.  There's outdated GitLab language in that section, too, but once I started looking at it, I stopped.  I think there's a lot of overlap, so probably the sections should be reorganized a bit, to remove or minimize redundancies?  But that was more than I could get into this evening :)

@nilesh.addweb Thank you! When I apply the patch, though, I no longer have Big Menu functionality on any of my menus -- even after enabling those menus in the Big Menu settings form. I'm not sure why, I don't see any errors in logs, it's just not functioning for me -- did it work for you?

Besides that, a few other notes:

1. The first time I go to the settings form, I get a warning in logs (⬇️). I think it'll be happier if you change the default value (in bigmenu.settings.yml) to { }.
   Warning: foreach() argument must be of type array|object, null given in Drupal\bigmenu\BigMenuForm->buildOverviewForm() (line 62 of /app/web/modules/contrib/bigmenu/src/BigMenuForm.php)
2. As the patch is currently written, Big Menu is immediately "disabled" on all menus -- site admins have to go to the settings screen and enable menus, in order for Big Menu to keep working.
   • Either there should be an update hook to enable Big Menu on all menus; or,
   • The setting could be revised so that this option is a "negative" option, i.e. checking a box next to a menu would disable it (example: "disable_themes" option in the Chosen module, but this would be menus, of course) (this field in the Chosen module settings is also an example of the checkbox field type); or
   • Allow either way: list the menus with checkboxes next to each one, and then have a "negate this condition" option, like in Block visibility settings. (This option would also need an update hook.)
     • (what I'm referring to) In Block visibility settings > Vocabulary, there's a "negate this condition" checkbox.
3. I think checkboxes would be better UX for this field, and more consistent with similar fields on Drupal admin forms (instead of a select field).
4. I think the language would be better as "enabled menus" rather than "available menus", what do you think? (Or "disabled," if you go with the "negative" option.

Finally back to re-test!

FYI, on my current project, I'm only using snippet to do text format mapping on all my rich text fields (so far) -- so, it's only one snippet, and it's only on one type of field/data/whatever -- and only on one use per migration.
Before today, I was using the 2024-08-01 version of the patch/MR.

• Today, I applied the latest version of the patch/MR.
• I ran one of my "upgrade_d7_node_complete_TYPE" migrations that I'd run previously, with the --update flag -- everything worked great.
• I rolled back that "upgrade_d7_node_complete_TYPE" migration, then re-ran it, just, to simulate doing it "fresh" or something -- everything worked great.
• I did the same thing with one other "upgrade_d7_node_complete_TYPE" migration -- success with that one, too.

"Everything worked great" = node data came in, no errors, proper text formats applied to rich text fields 🎉

Please let me know if there's any other info I should share. Thank you!!

benjifisher → credited alison → .

benjifisher → credited alison → .

jasonglisson → credited alison → .

Here 🙋‍♀️

Reviewing the charter as well as Matthew's suggestions (#7)...

Scope:

I like this (from #7):

The Mentoring Coordinators Working Group charter applies to its members, the lead coordinators

Duties:

First duty in the list, "Organizes contribution events (DrupalCon, DrupalCamps, etc.)":

Runs workshops for first-time contributors at DrupalCons, Camps, and events.

How about:

Runs workshops for first-time contributors at Drupal conferences, camps, and other events.

Third duty, "Maintains the mentoring ecosystem":

Maintains the drupal.org Mentoring project issue queue.

Should this be linked to the Mentoring project (or the actual issue queue)?

Last/fourth duty, I like this, from Matthew (#7) -- "Works with the Drupal community" seems like a fitting rename of this duty.

Membership:

Actively participating in multiple mentoring events and helps them execute well.

The second half of the sentence isn't right, but I haven't figured out how to rephrase yet -- OR, maybe remove the second half, because it's covered in the next line??

Regularly volunteering for contribution mentoring events and help to lead parts of those events(for example, helping with communications at an event, etc...).

So, "Actively participating in multiple mentoring events and helps them execute well." => "Actively participating in multiple mentoring events."

Avoiding the specific "#" makes sense to me (again, #7), and I'd say "in" not "at" -- i.e.

Regularly participates in mentoring meta meetings in mentoring Slack channels.

They bring new ideas, skills
and suggested processes to the team.

How about remove "new," and then just "processes"? -- "They bring ideas, skills, and processes to the team."

-------

I'm thinking about the wording under Vision; I asked a question on Slack during today's meta meeting, will keep thinking.

-------

(Meanwhile, I did a commit with some punctuation and language things.)

Hmmm so, is that one (3466281) a duplicate, or are they separate issues? (or are they separate issues and we've scope-creeped on this thread (3052574)?)

🐛 Fix access checks for bundle permissions to avoid triggering a config validation error Fixed has been committed (backported) to 10.3.x, so it'll be included in the next 10.3.x release.

@junaidpv Are you saying you're using 10.3.x dev or that you applied that commit diff/patch to 10.3.1 (I think you can use this diff as a patch), and you still get the problem unless you uninstall admin_toolbar_tools?

We also started having trouble when we updated to core 10.3 (10.3.1, to be precise, but we skipped 10.3.0).

We have a view page with an exposed form, plus the facet block. As has been described, when you go to the view page, you can select a facet checkbox -- everything works fine -- but then you can't uncheck that box, or select another box in the same facet (this view has two facets in use on it -- you can check a box in the other facet, but then, same thing for that facet: you can't deselect that box, or select another box in that facet).

#244 completely fixes the issue for us. Full disclosure: I did not try the other recent patches. (We're on Facets 2.0.7.)

Add link to GitLab, suggesting people refer to the README for further documentation (just linked to GitLab, considered a more specific anchor link target, i.e. https://git.drupalcode.org/project/facets#facets , but wasn't sure, so, left it without the "#" fragment for now).

MR #8487 fixes the dblog warning flood for me on 10.3.0! (PHP 8.1, in case it matters) I don't see any side effects.

(Setting to RTBC in hopes of getting it into 10.3.1 tomorrow -- apologies if this is bad form because it's not 11.x-dev as the issue is tagged.)

Oh! Even though it says "test" in the name, it had not occurred to me that this module was meant for testing the module, like for automated tests / debugging -- I thought the intent of this module was more like a demo/example module. I suppose then it would be called Mercury Editor Setup Demo or Mercury Editor Setup Example...

Obviously I'm biased because I didn't know about using test modules like this (to try the module with a demo/starter-setup, not just for automated testing), but, if y'all are going to use this module in how-to presentations, I recommend including an explanation of how to enable the module, or point to documentation about how to enable test modules -- again, I'm biased, but I don't think it's common knowledge among site builders who aren't also contributed module developers.

That said, I get it now, thank you!

MR55 works for me on 10.3, too (was going to test on 10.2.6 buuuut thank you @sethhill for already doing that!)

Same here! I go into the node editing form (existing basic page with mercury editor enabled, and layout paragraphs functionality), and I get this in browser console (Firefox on Windows 11):

Uncaught TypeError: event is undefined
    handle https://my-site.pantheonsite.io/core/misc/dialog/dialog-deprecation.js?v=10.3.0:12
    jQuery 7
    openDialog https://my-site.pantheonsite.io/modules/contrib/mercury_editor/build/js/dialog.drupal.js?sfp58z:194
    show https://my-site.pantheonsite.io/modules/contrib/mercury_editor/build/js/dialog.drupal.js?sfp58z:217
    attach https://my-site.pantheonsite.io/modules/contrib/mercury_editor/build/js/edit-screen.js?sfp58z:168
    attachBehaviors https://my-site.pantheonsite.io/core/misc/drupal.js?v=10.3.0:166
    attachBehaviors https://my-site.pantheonsite.io/core/misc/drupal.js?v=10.3.0:162
    <anonymous> https://my-site.pantheonsite.io/core/modules/big_pipe/js/big_pipe.js?v=10.3.0:153
    <anonymous> https://my-site.pantheonsite.io/core/modules/big_pipe/js/big_pipe.js?v=10.3.0:184
dialog-deprecation.js:12:24

When I click the "plus" icon, it loads the paragraph picker dialog, but there's this in console:

An error occurred during the execution of the Ajax response: TypeError: event is undefined ajax.js:1147:19
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1147
    (Async: promise callback)
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1145
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:588
    jQuery 6
    execute https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:711
    lpbUiClick https://my-site.pantheonsite.io/modules/contrib/mercury_editor/build/js/post-messages-listener.js?sfp58z:14
    attach https://my-site.pantheonsite.io/modules/contrib/mercury_editor/build/js/post-messages-listener.js?sfp58z:59

Then I pick a paragraph type (button, in my case, because it's simple, just a plain text field and a link URL field), and the next dialog loads, but I get this in console:

An error occurred during the execution of the Ajax response: TypeError: event is undefined ajax.js:1147:19
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1147
    (Async: promise callback)
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1145
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:588
    jQuery 6
    eventResponse https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:803
    Ajax https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:650
    jQuery 8
    Ajax https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:639
    ajax https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:267
    bindAjaxLinks https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:335
    bindAjaxLinks https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:307
    attach https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:54
    attachBehaviors https://my-site.pantheonsite.io/core/misc/drupal.js?v=10.3.0:166
    attachBehaviors https://my-site.pantheonsite.io/core/misc/drupal.js?v=10.3.0:162
    insert https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1393
    jQuery 2
    insert https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1385
    openMercuryDialog https://my-site.pantheonsite.io/modules/contrib/mercury_editor/build/js/dialog.ajax.js?sfp58z:43
    commandExecutionQueue https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1050
    (Async: promise callback)
    commandExecutionQueue https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1043
    commandExecutionQueue https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1040
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1099
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:588
    jQuery 6
    execute https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:711
    lpbUiClick https://my-site.pantheonsite.io/modules/contrib/mercury_editor/build/js/post-messages-listener.js?sfp58z:14
    attach https://my-site.pantheonsite.io/modules/contrib/mercury_editor/build/js/post-messages-listener.js?sfp58z:59

Then, I fill in the two simple fields, and hit "Save" -- nothing happens, dialog stays up, no button is added to my layout -- and I get this in console:

An error occurred during the execution of the Ajax response: TypeError: event is undefined ajax.js:1147:19
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1147
    (Async: promise callback)
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1145
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:588
    jQuery 9
    eventResponse https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:800
    Ajax https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:650
    jQuery 8
    Ajax https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:639
    ajax https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:267
    loadAjaxBehavior https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:47
    loadAjaxBehavior https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:44
    attach https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:52
    attachBehaviors https://my-site.pantheonsite.io/core/misc/drupal.js?v=10.3.0:166
    attachBehaviors https://my-site.pantheonsite.io/core/misc/drupal.js?v=10.3.0:162
    insert https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1393
    jQuery 2
    insert https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1385
    openMercuryDialog https://my-site.pantheonsite.io/modules/contrib/mercury_editor/build/js/dialog.ajax.js?sfp58z:43
    commandExecutionQueue https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1050
    (Async: promise callback)
    commandExecutionQueue https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1043
    commandExecutionQueue https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1040
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:1099
    success https://my-site.pantheonsite.io/core/misc/ajax.js?v=10.3.0:588
    jQuery 3

"Cancel" also doesn't work, but the "X" at the top-right of the dialog does work, so that's how I make my escape.

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 Postponed: needs info )

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.)