@mglaman, it looks like sarwan_verma did that back in comment 15 - https://www.drupal.org/files/issues/2023-09-28/commerce_cart_flyout-3359... →
I was able to use the patch with https://github.com/mglaman/composer-drupal-lenient (wish I found this project earlier...). I'm kicking the tires of commerce (no live site yet), but things work.
@mglaman can you review if this is the correct direction, and then maybe someone with more commerce experience than I can polish the patch (if needed). Thanks!
sigh... the config change took forever to figure out why it wasn't working in the tests. I found https://www.drupal.org/node/2951441 → (paragraphs module) that is similar. drupal_flush_all_caches() is what is required for the config to work in the second test.
I've added screenshots from the local test results I did. Removed the Needs Tests tag to reflect that tests were added and marking as needs review.
Let me know if there should be any changes!
Sure!
Screenshots
The default (per config/install/layout_paragraphs.settings.yml) is to not show the paragraph labels and not show the layout labels. I've included screenshots of how this looks with both labels showing and with a mouse hover.
Div & a class
I've pushed a commit to the MR doing this. Naming things is hard, so let me know if there should be any changes.
Tests
I'll poke at this. I'm guessing a new test in BuilderTest.php would be best. Let me know if this is the wrong direction.
Thanks!
Marking as Needs review since sakthi_dev addressed feedback in #15.
I noticed the code was only for show_paragraph_labels and not show_layout_labels. I've enhanced the code sakthi_dev did (will try to push to MR) that shows the layout when the setting is checked. Part of this is adding an additional check to existing code to make sure the paragraph is not a layout.
Let me know if anyone has any questions and great to find this issue!
-Nate
I ran across this and it looks like the Webform module handles how this works. src/Plugin/Field/FieldFormatter/WebformEntityReferenceEntityFormatter.php is the webform file that controls this behavior and doesn't know how the layout_paragraphs module does things.
My solution for this is to use a custom display mode (preview) for my webform paragraphs. Then I display the webform URL instead of the default of the webform.
There probably could be an update to $is_entity_edit_form and $is_paragraph_entity_edit_form to fix this functionality, but that would be something for the webform issue queue (and I'm not sure its worth it).
@Dom. I was able to have a view working with masonry_views as the display format.
The biggest issue I had was including "px" in the Gutter Width setting (px isn't needed). Ideally there would be a warning to prevent people doing what I did, but that is a separate issue.
+1 from me on this. Thanks!
Thanks Dom. I plan to test it this week and report back here. If anyone else wants to test this, here is the git info that I added to my composer.json in the repositories section:
"drupal/masonry_views": {
"type": "package",
"package": {
"name": "drupal/masonry_views",
"version": "2.x-dev",
"type": "drupal-module",
"source": {
"type": "git",
"url": "https://git.drupalcode.org/project/masonry_views.git",
"reference": "9cf47eae179ddca42dcb4883461cbd555cca4809"
}
}
}Then you can reference the 2.x version of the module. Aka "drupal/masonry_views": "^2.0",
@Dom. any chance you can promote the 2.0 version on the project homepage? https://git.drupalcode.org/project/masonry_views shows the 2.x branch as default, but https://www.drupal.org/project/masonry_views → doesn't show it.
Thanks!
@mingsong, thanks for the documentation page!
One thing I got caught up on is the "if (Drupal.fullcalendar_block) {" not working. This ended up being due to the order of the JS being loaded. I resolved it by adding a dependency in my library to:
- fullcalendar_block/fullcalendar
I'm not sure if/how to add this note to the documentation page, so adding it here in case it is helpful for others. Thanks.