This MR adds some additional contexts that can be evaluated against:
field_name: the Paragraphs reference field
entity_type: the entity type (node, taxonomy term, etc.)
entity_bundle: the entity bundle (content type, etc.)
It also modifies the application of restrictions such that all contexts are required to match in order for any restriction to apply. This allows setting granular or broad restrictions, depending on the combination.
For example:
field_rule:
context:
entity_type: node
entity_bundle: me_test_ct
field_name: field_me_test_content
region: _root
components:
- me_test_container
Will only match on the root level of the field_me_test_content field when it is on a node of type me_test_ct. All other instances of that field will not be restricted.
sethhill → created an issue.
This already works as long as the expected pattern and Mercury Editor template IDs are known. Documentation updated.
sethhill → created an issue.
We made a change in 🐛 Pages update incorrectly during saves when page caching enabled Active that addresses issues related to caching and previews. The behavior that we were seeing was that the editor was no longer attached to the correct revision of a paragraph, so when saving it appeared that changes were not saved. We cut a new 2.2-RC1 release with this change.
sethhill → changed the visibility of the branch 3497979-pages-update-incorrectly to hidden.
sethhill → changed the visibility of the branch 2.2.x to hidden.
sethhill → created an issue.
sethhill → created an issue.
Modified logic so multiple contexts can be passed that restrict paragraphs similarly.
This works as designed, I had the wrong layout name in my restriction.
sethhill → created an issue.
sethhill → created an issue.
sethhill → created an issue.
I made a small module called SDC CSS Relocator → to help with a similar issue that I was seeing. If there's anything that would make it more helpful while this issue awaits resolution, feel free to comment on that project page.
sethhill → created an issue.
The schema passes in Config Inspection but I do see 1 data error reported on the summary screen for mercury_editor.settings. It does not, however, show any errors on the detail screen and others have reported this behavior with the module. I think we should merge in and report any new errors separately. Thanks for the review!
sethhill → created an issue.
The MR should resolve schema structural errors. In reviewing, I noticed that the menu settings for Mercury behave differently from the dialog settings, in that menu is a string and dialog actually encodes/decodes YAML. I created 📌 Groups config in mercury_editor.menu.settings should be YAML instead of string Active to update that, as the current behavior works. Converting to YAML decoding would allow greater detail in validating the schema and improve user experience.
sethhill → created an issue.
sethhill → made their first commit to this issue’s fork.
We decided to go with the quick fix at the moment, as the work to change how Mercury Editor libraries are attached will require more changes than we want to make. Created 📌 Mercury Editor libraries are attached to entity edit forms even when Mercury is not enabled for them Active to capture that need for future development.
sethhill → created an issue.
sethhill → changed the visibility of the branch 3493649-drop-d9-and to hidden.
I experienced this out in the wild today. I think it's something to do with configuration of sites that don't have the dialog tray width explicitly set. I'll test and find a solution along with the label switch.
sethhill → created an issue.
Replicated the issue and solution. MR looks good. Thank you!
sethhill → made their first commit to this issue’s fork.
Can you provide some more details on your setup that is resulting in this warning? I wasn't able to replicate the issue locally. Thank you!
sethhill → made their first commit to this issue’s fork.
I encountered issues with Drupal\Core\Template\Attribute and SDC Display, in particular. When including an Attribute, the component display form would not render. See 🐛 Drupal attribute properties break form generator Active for details.
Even though the issue is closed as a duplicate there, the actual issue fix is on the schema-forms-php package and seems different. There wasn't a PR available there the last time I was setting up components, so this may resolve the issue I was experiencing.
I believe that this behavior was solved in 🐛 Mercury tray resizes when entity browser modal dialogs are opened Active , which is included in the latest 2.1.6 and 2.2.0-beta4 releases. We should now be tracking the current width of the sidebar and responding to that.
As I was reviewing, I noticed that I'm modifying the innerHTML of the button to toggle between "Hide sidebar" and "Show sidebar," but not doing that to the title attribute. This means that when you roll over the button the tooltip will always read "Hide sidebar." (I also seem to have a habit of somehow clicking right on that tooltip, which intercepts the click.)
Setting to Needs Work pending that title change. Let us know if you discover other scenarios where the sidebar isn't behaving as expected. Thanks!
I made some modifications to improve the experience of resizing the sidebar tray.
When collapsing and re-opening the tray using the button in the toolbar, the tray will now open at the default width. This makes the default width setting more relevant, because it's now possible to restore the tray to that default.
Resolved the issue where the tray popped open unexpectedly to a previously-stored value.
I think this is ready to merge if it looks good to others.
sethhill → created an issue.
Dialogs should be behaving quite a bit better now.
I also moved some of the handlers around on resizing the sidebar tray, so that should better detect when the sidebar is open or closed. There is still one bug where if you collapse the sidebar and then start dragging it back open, it flies open to the width before it was collapsed. I thought it better to leave that as it stands currently and get more eyes on this sooner.
I believe this is undocumented at the moment, but you can configure dialog settings based on specific Paragraph types. This is found in Mercury Editor Dialog Settings. To do so, create a new object with the Paragraph's name appended with _form. For example:
_defaults:
width: fit-content
height: fit-content
drupalAutoButtons: false
dialogClass: lpb-dialog
resizable: true
entity_ref_form:
width: 600
height: fit-content
drupalAutoButtons: false
dialogClass: lpb-entity-reference
resizable: true
formatted_text_form:
width: 800
height: 600
sethhill → made their first commit to this issue’s fork.
sethhill → created an issue.
Removed dependency on Mercury Editor and have tested. Setting to Fixed and will create new issues as more is discovered.
Looks like this code is already part of 2.0.6. Marking as fixed.
sethhill → made their first commit to this issue’s fork.
Mercury Editor is referenced in many places throughout this module. This issue requires more than removing the dependency from the .info.yml file.
sethhill → made their first commit to this issue’s fork.
sethhill → created an issue.
sethhill → created an issue.
D11 compatibility was merged in another ticket. Closing this.
Updated controllers and cypress tests. Tests are completing successfully on D10.3 and D11 now.
Since the Ollama provider is using the OpenAI-compatible format, I tried replacing the existing ChatMessage structure with that found in the OpenAI provider. This allowed image alt text generation to work using Ollama as the provider.
sethhill → made their first commit to this issue’s fork.
sethhill → created an issue. See original summary → .
I tested this patch and the module continues to operate as anticipated. Setting to RTBC.
sethhill → made their first commit to this issue’s fork.
@justin2pin I created a new configuration option for setting the default width of the tray. I put that on the Dialog Settings form, but I'm not sure that's the right context. Do you think it's better on the main Mercury Editor Settings page?
I have some questions about the intended behavior of the saved tray width when a user manually resizes it. Is that supposed to persist after a refresh or on other edit pages? I wasn't sure about that, and this needs some more refinement anyway.
For example, I didn't want to mess with the settings array, because it looked like some of those options were being set directly in dialog.drupal.js. For the time being, I created an additional drupalSettings.mercuryEditorDefaults to get the value from the configuration and then merge that in with the existing settings.
Setting this to Needs Work while we deliberate.
sethhill → made their first commit to this issue’s fork.
sethhill → made their first commit to this issue’s fork.