Got it, thanks.
The only minor annoyance (which to be honest is most likely because this is a very long running project since D8) with this is that if your CSS is too broad (e.g. you themed on button, or general form field styling) it gets applied to the back-end as well.
This is exactly why we moved away from this direction. It is virtually impossible to both apply styles from the front-end to backend forms and prevent unwanted impact on the backend ui, at least in any way that is holistic and reasonably maintainable.
I would look at providing this functionality in a separate module or look at other modules (for example, Mercury Editor) that are already doing this kind of thing. I think the the overhead of maintaining this functionality, required test coverage, adequate handling of broad use cases, etc. is too difficult to justify adding it to layout paragraphs. All of that said, providing this as a separate module with a dependency on LP should be simple to do and to maintain for your specific purposes.
Thanks for all the work on this. A few thoughts:
- It looks like more work has happened since this was RTBC, so resetting to Needs Review.
- Ideally we'd flag as RTBC once multiple people have tested / provided feedback.
- @bramdriesen - you're 100% correct about tests failing for LP 3x - I added
this issue
✨
Refactor tests in Cypress
Needs work
and we're working on it.
- And finally... can someone (@bramdriesen maybe?) provide an overview of what this MR actually does? Does this impact the front-end editing experience, or rather bring frontend styles to the backend edit form? Screenshots might be helpful as well.
FWIW, my team has standardized on Mercury Editor as the way to bring Layout Paragraphs content editing more directly into the frontend (among other authoring enhancements). We worked on multiple other directions, each with their own pros / cons, before going that route.
justin2pin → changed the visibility of the branch 3539169-fix-state-management to hidden.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → made their first commit to this issue’s fork.
justin2pin → created an issue.
I believe the hook you are looking for is hook_preprocess_layout_paragraphs_builder_component_menu to modify the list of component types rendered in the dialog.
You can also subscribe to the LayoutParagraphsAllowedTypesEvent event to alter which component types are available within specific contexts.
Merged
justin2pin → made their first commit to this issue’s fork.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → changed the visibility of the branch 3504399-the-mercury-editor to active.
justin2pin → changed the visibility of the branch 3504399-the-mercury-editor to hidden.
Opened a new MR against 2.2.x. To test in composer, use:
"patches" : {
"drupal/mercury_editor" : {
"Issue #3468550": "https://git.drupalcode.org/project/mercury_editor/-/merge_requests/104.patch"
}
}
justin2pin → made their first commit to this issue’s fork.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
Looks like #5 fixes the issue. Merged, marked as fixed.
justin2pin → made their first commit to this issue’s fork.
justin2pin → created an issue.
justin2pin → made their first commit to this issue’s fork.
justin2pin → made their first commit to this issue’s fork.
Totally agree that the UI for component selection will need to be improved / modified for many use cases. That said, I think the real life applications for this are so broad / varied that we should either (a) just rely on the existing theme system (with twig templates, preprocess and library alter hooks, etc.) for altering the UI in specific use cases and leave this issue as "won't fix", or (b) work on making it for developers to customize the existing look and feel with their own templates / css.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
@arthur.baghdasar I don't understand what commit 81f73297 has to do with SortableJS? Also that commit appears to break AJAX commands in phpunit tests.
If there is a problem with scrolling, let's open a new issue.
justin2pin → made their first commit to this issue’s fork.
justin2pin → made their first commit to this issue’s fork.
sethhill → credited justin2pin → .
justin2pin → created an issue.
Merge Request !13 introduces a data-me-max_length data attribute, which the "basic" JavaScript editor uses to enforce field length limits. Here are a few key points:
- This functionality applies only to "basic" editors and does not support CKEditor 5-enabled fields.
- Enforcing character limits in CKEditor 5 is not straightforward and requires custom solutions.
- CKEditor 5 is not the default editor for short formatted text fields in Drupal. It is only available for fields that use "textarea" form inputs.
- This approach adds a custom data attribute (
data-me-max_length) using themax_lengthsetting from the field definition. Developers who want to define custom limits for field lengths can use a custom implementation of thehook_preprocess_fieldfunction to add thedata-me-max_lengthdata attribute with the desired value.
justin2pin → made their first commit to this issue’s fork.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
Thanks Andrew! Check out MR!10 and let me know if this addresses the issue for you. This is now just picking up Layout Paragraphs operations, which means the same permissions for Layout Paragraph's "create", "delete," and "reorder" operations will be used and applied to tabs and accordions.
To use the MR as a patch, you can reference https://git.drupalcode.org/project/mercury_layouts/-/merge_requests/10.patch in your composer.json file.
If this works for you all, I'll merge!
justin2pin → made their first commit to this issue’s fork.
justin2pin → created an issue.
justin2pin → created an issue.
Good catch, thanks!
justin2pin → created an issue.
Merged. Will log bugs / feature requests as separate issues.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
Fixed in 🐛 Does not enable correctly in all contexts Fixed
justin2pin → created an issue.
justin2pin → created an issue.
Merged with 2.0.x. There is now an "me_tabs" layout plugin that allows content editors using Mercury Editor to add tabs, rename them, and reorder them with drag & drop.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.
justin2pin → created an issue.