🇺🇸United States @alison

volkswagenchick → credited alison → .

Working with @kwame-acquah in Mentored Contribution at DrupalCon Atlanta!

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

Working on this at Mentored Contribution at Atlanta 2025

benjifisher → credited alison → .

mradcliffe → credited alison → .

(here!)

alison → created an issue.

(removing the sponsored ticket application form -- it was the wrong link, and the one for this year is closed)

alison → created an issue.

alison → created an issue.

"here"!

After discussion with other developers on the project, I opted to not completely replace the default help text but to concatenate it field's help text to it, both to have consistency with the help text across all Linkit widgets on a given site and to minimally affect existing fields.

I think this ⬆️ is a good plan, also because it's how help text works on fields that use the core LinkWidget. On my fields that use the core LinkWidget, the resulting help text is actually an unordered list -- perhaps, for UX consistency (and the simplicity of just, using an established pattern from Drupal Core), we could do that with Linkit-enabled link fields?
👉 Here's how core + user-provided help text is put together for the core LinkWidget: https://git.drupalcode.org/project/drupal/-/blob/b57dbb43806a5434c7f7400...

And here's an example of the resulting help text markup (from one of my link fields that uses core LinkWidget) -- the first list item is my custom help text, the second list item is provided by Core:

<div id="edit-field-card-slider-slides-0-inline-entity-form-field-slide-link-0-uri--description" class="form-item__description">
  <div class="item-list">
    <ul>
      <li>If filled in, the <em>slide title</em> will be a clickable link.</li>
      <li>Start typing the title of a piece of content to select it. You can also enter an internal path such as <em class="placeholder">/node/add</em> or an external URL such as <em class="placeholder">https://example.com</em>. Enter <em class="placeholder">&lt;front&gt;</em> to link to the front page. Enter <em class="placeholder">&lt;nolink&gt;</em> to display link text only. Enter <em class="placeholder">&lt;button&gt;</em> to display keyboard-accessible link text only.</li>
    </ul>
  </div>
</div>

Re: #7 -- makes sense. I suppose it's out of scope for this issue, but I don't feel strongly about forcing a new issue, except that there's always a chance the added scope makes the resolution take longer -- but, I don't feel strongly about it.
👉 For reference, here's where that description text is set in core.

Partial review, gotta go for now!

-------
(1) Perfect world.....

We define a clear and defined scope for coordination of mentoring with an
effective plan to join and leave the working group so that the members of the
Drupal community understand our process.

We'd not say "define/defined" so close together, and I think we can drop "effective"?

-------
(2) The word "Charter": use capital or lowercase "C" in both instances (right now, it's a mix; maybe the first one is capitalized because it's in a heading; if that's the case, lowercase it, per content style guide → ; if it's actually a proper noun, capitalize it in the first sentence of the Scope section).

-------
(3) Scope, part 1 -- use the group acronym? -- so:

The Mentoring Coordinators Working Group charter applies to

Replace "The Mentoring Coordinators Working Group" with "The MCWG"

-------
(4) Scope, part 2:

The Mentoring Coordinators Working Group charter applies to its members, lead
coordinators listed on Maintainers.txt, and their roles in contribution events,
community work, and planning throughout the year.

Totally might just be me, but! I think it's unclear that the MCWG members are the same as the lead coordinators (and I just ran out of time to attempt a rewrite).

Hi and thank you for the work! I'm very sorry but I don't have an ETA on merging, I took a look at the code but I need to look at it more carefully, unless another co-maintainer can get to it before I do.

I'm sorry I don't have a better update, I just didn't want to leave y'all with complete radio silence.

Hi! Replying here for transparency and/or posterity: @jradhak also reached out via email, about Drupal 11 compatibility, and to offer to be a co-maintainer. I appreciate the communication and the offer!

Excerpts from my email reply:

I'm not going to be able to look at this til at least January 9 [...]. When I'm back, I can review your contributions and activity on Drupal.org and see if it's a good fit to add you as a co-maintainer.

Have you been participating in the nodeaccess issue queue? Could you send me a couple examples? (Or I can look into it myself when I'm back in January, this info would just expedite my review when I get back.)

Again, thank you SO much for contributing. I hope to talk with you again in a 2-3 weeks.

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.