the release worked for me...thanks!
appreciate it. let me know if there is any more info I can share to help.
Willing to zoom or try making a screencast if its helpful.
sbubaron → created an issue.
I do agree with the need, I think I solved that early on by adding my own padding within my theme.
just wanted to add, great to see the progress / work you and your team are doing! while I think there's alot of buzz around experience builder, I think this "node centric" paragraph/component approach is significantly easier to understand than a page/block approach, depending on the scale of the site.
this is a hacky attempt at removing the padding that gets added on elements when focused in the mercury editor preview window.
I modified build/preview-screen.js to remove the fixed 10px padding that it sets when an element is focused.
I see there is a preview-screen.min.js which I did not modify in this, not sure where/if that comes into play in mercury editor, but I don't believe my site uses the minified one even with aggregation turned on.
I also see that there are source javascript files which I imagine are used via node/postcss to build the "build" folder file that I patched, I'm not sure what the best practices are for these kinds of patches, but this worked in dev for me.
fwiw I ended up updating to 2.2 RC1
+1 to this, its nice to indicate what your hovering over, but very distracting and the extra padding on the wrapping divs hurts your ability to predict what the end product will actually be.
I had similar issues when we first implemented, I believe the problem came down to bad html in my custom twig file, missing a closing tag on a div.
Full disclosure, I don't really know what I'm doing, but I based these changes off of layout_paragraphs_permissions disable-reorder.js which similarly defines a call to registerLpbMoveError by adding a behavior attachment. The world of drupal javascript and behaviors is quite foreign to me.
this seems to have fixed the console error and is still preventing the movement of paragraphs based on the limit settings.
I don't create patches often so apologies if I messed up the process.
sbubaron → created an issue.
sbubaron → created an issue.
Created a patch...this is a first time for me so apologies if I didn't do it correctly.
sbubaron → created an issue.
I had a similar issue with one of my (non-sdc) components -- it turned out I had some faulty html missing a closing div tag. Worked great in editor, but once saved, back into view mode, back into edit mode things would be missing.
I can confirm that the above patch along with https://www.drupal.org/files/issues/2023-10-13/3050607_drupal_10_1_5_dia... → fixed the save issue for me on Drupal 10.
While this issue seems quite stale, the referenced issue has more recent traction.
sbubaron → created an issue.
In a similar vein, I'd love to be able to have a separate page/edit form for the non-mercury stuff. In our use case those fields are mainly meta-data related and editors rarely need to change both things at the same time. The sidebar is still useful for things like revision notes/publishing options etc, but everything else could be tucked away on a more traditional edit page.
Having same issue but now with composer/installers v2.2:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires fontawesome/fontawesome 6.4.0 -> satisfiable by fontawesome/fontawesome[6.4.0].
- fontawesome/fontawesome 6.4.0 requires composer/installers ^1.2.0 -> found composer/installers[v1.2.0, ..., 1.x-dev] but it conflicts with your root composer.json require (^2.2).
Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
sbubaron → created an issue.