🇺🇸United States @sethhill

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.

@devanbicher, your patch worked and resolved the issue. I made a slight modification to specifically look for the layout key within the behaviors array, so that if for some reason in the future another element is added into the array it won't cause this to evaluate as true.

$is_layout = isset($behaviors['layout_paragraphs']) && array_key_exists('layout', $behaviors['layout_paragraphs']);

MR!75 makes this change and I've also attached a new patch file. Marking as RTBC.

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

I tested the MR against 2.1.x and it resolves the behavior reported, it should be good to merge. Setting to RTBC.

I agree with krystianbuczak in #7. New MR !74 removes the overrides and allows the media library to display as styled by Claro.

I have seen issues when using Mercury with Gin as the admin theme, though. One approach that often resolves these is to explicitly set the Mercury Editor Edit Tray theme to Claro in Mercury Editor settings.

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

Tested against 2.1.x and this looks good to merge. Setting to RTBC.

Reviewed this against 2.1.x and it looks good to merge. Setting as RTBC.

sethhill → changed the visibility of the branch 3468130-query-string-parameters to hidden.

Hi @alison. I ended up hitting a similar issue on a new site. It looks like I had solved it previously using a preprocess hook, like this:

function mymodule_preprocess_paragraph(&$variables): void {
  /** @var \Drupal\paragraphs\Entity\Paragraph $paragraph */
  $paragraph = $variables['paragraph'];
  $behaviorSettings = $paragraph->getAllBehaviorSettings();

  // Set style option behaviors as a logical template variable.
  if (!empty($behaviorSettings['style_options'])) {
    foreach ($behaviorSettings['style_options'] as $key => $style) {
      if (isset($style['property'])) {
        $variables['style_options'][$key] = $style['property'];
      }
    }
  }
}

and then in Twig was able to get at it with {{ style_options.my_style_option }}.

I encountered this issue as well, and in my case it appeared that the cause was attempting to close a dialog that didn't exist.

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

I haven't been able to replicate this error on 2.0.8 or the latest 2.0.x branch. Can you provide more information on your configuration?

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

Removed D9 support as well here. Looks good!

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

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

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

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

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

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