🇺🇸United States @pbabin

Hi

We are in Drupal 10.4.2 and found ourselves in a situation where we needed to use this patch to have the .reveal-on-hover for the lpb-controls to display. Previously the library wouldn't seem to trigger.

After the patch was applied we ended up getting a console error around line 192
let rolloverPaddingBlock = drupalSettings.mercuryEditor.rolloverPaddingBlock ?? defaultRolloverPaddingBlock;.

TypeError: undefined is not an object (evaluating 'drupalSettings.mercuryEditor.rolloverPaddingBlock')

Any recommendations?

pbabin → created an issue.

Not sure if this is the correct place to report this. I'm also getting the Object support when dumping a YAML file has been disabled. error. I saw that another post was closed that reported this error as being a duplicate. We're using layout-paragraphs (gasp) but that hasn't been the issue as we have been successful in the past in exporting and importing this data. We are actually still using the import functionality from our last export nearly a year or two ago but need to update our default content.

I installed the most recent patch and the error occurs at the $return = Yaml::encode($normalized) in the Exporter.php class. Since we have a lot of stuff being exported out I added the following to help me identify the issue

    function find_objects($array, $path = '') {
      foreach ($array as $key => $value) {
        $new_path = $path ? $path . '.' . $key : $key;
        if (is_object($value)) {
          echo "Found object at $new_path\n";
        } elseif (is_array($value)) {
          find_objects($value, $new_path);
        }
      }
    }

    find_objects($normalized);

And it looks like this is erroring out for us on a meta tag breadcrumb item we have on our page. I've included a screenshot from the xdebug if this might be helpful.

Any recommendations?

pbabin → created an issue.

Asking here but think it is unrelated. We are having this same issue where both hardcoded relative and absolute paths to files are not registered in entity_usage. I can confirm that our file structure is /sites/default/files/media, at least locally where I am doing all of my testing at the moment. I've tried multiple variations of source/target to rule out these; however, anything that is hardcode is missed.

The one factor, which I believe makes this semi-unrelated, is that I am trying to track entity usage in paragraphs with text editors as we are using the layout_paragraphs module.

Does this then point us to Track composite (e.g. paragraph) entities directly and only as their host → ? Which suggests we wait till the next major release?

Thank you in advance!

I can confirm that we experienced this issue as well. We had a bad release on our host platform and during the time we were restoring sites this error was observed in our logs.

Thank you for this pointer!

pbabin → created an issue.

@justin2pin - I had a feeling that there should have been more updates. Thank you!!!

This seems like a minor typo.

Thank you @grimreaper for linking this issue to ✨ JSON API integration Active !

I've applied the MR !9 patch from #2890651 and the crops are being brought over with Entity Share! Please note that my setup included a locked policy. With the policy turned on, the crops did not come over. I've converted the policy to create only and the crops come over and are applied correctly.

So much gratitude for this package! Thank you.

Thank you @sickness29!

We're running Crop 8.x-2.4 and Drupal 10.3.2. We applied MR !9 and tested @grimreaper's ✨ Support Crop API Active . Our setup is now bringing over the crops and displaying as our users desire.

For those of you in Acquia Cloud Site Factory seeing this feature request, you can set a Strict-Transport-Security header using a factory hook and this won't be an issue.

We had a release last night in Acquia Site Cloud Factory where 18% of the sites failed during our deploy with this same issue. We're on 10.3.2 and media_duplicates 2.0.2.

To clear this out I ran drush sqlq "ALTER TABLE media_field_data ADD COLUMN duplicates_checksum VARCHAR(255) NULL DEFAULT NULL COMMENT 'Checksum for duplicate media detection';". This allowed me then to uninstall the package and reinstall. As mentioned above, when running the update manually with drush en we did not have the missing column.

@Spokje - Dank je wel! 251 reroll of 244 is working on our end.

Applied 251 in 2.0.8 and we are not getting the session is not set error.

I'd argue for scope creep potentially. We're on Drupal 10.3.2 and using Facets 2.0.8 with search api and none of the previous patches are working. I was using patch 237 to address the session is not set issue but with 2.0.8 I wasn't able to apply this patch anymore. The patches in 3466281 don't appear to be the way to go as it is using a mock and I was told that this is usually only for testing and shouldn't be applied to code. I'd greatly appreciate some feedback on how to proceed with my current setup as my patch for 2.0.8 does not appear to be applicable.

@ELC - I greatly appreciate you chiming in on this. I'm still "relatively" new to Drupal so getting feedback like this is extremely helpful.

I'm curious as to why an earlier approach for pre 2.0.8 isn't also under your rubric as the patch I submitted was just a copy of previous work. Is it safe to assume that this entire approach isn't recommended?

I came this way from Facets with AJAX not working in most of situations → where Patch 237 → addressed our the issue with the session not being set and this comment 🐛 Facets with AJAX not working in most of situations Needs review directs individuals over to this issue as a proposed solution.

Since 2.0.8 came out, the patch 237 no longer works and the patch I proposed is not recommended so we are still stuck with facets that are completely broken because we are getting the "session has not been set" error coming up.

Any recommendations on how to address this issue in a more Drupal appropriate way are greatly appreciated.

All credit goes to @s.messaris . . . . 2.0.8 came out today and the patch for 2.0.7 doesn't work anymore. Copied and pasted the proposed changes and created a 2.0.8 patch.

Thank you @s.messaris for getting a handle on the "session has not been set" issue.

Got a ticket from our team today to address an issue where cloning a node with layout paragraphs and Mercury Editor did not bring over the content.

I found https://www.drupal.org/project/quick_node_clone/issues/3218222 🐛 Cloning Entities with Layout Paragraphs breaks structure and moves subparagraphs into Disabled Items RTBC over on the Quick Node Clone side that works; however, as I mention on that issue on the node clone creation page the content, with that patch, does not have the Mercury Editor inline editor.

I implemented MR !116, enabled the submodule, and it is cloning nodes with layout paragraphs with no issue. Added bonus the ME inline editor is working as intended on the node clone creation page.

MR !116 is working well and thank you!

Came across this issue today or at least I came across this today to address an issue where our setup is not cloning the content.

Using the following:
- Drupal 10.3.1
- Quick Node Clone 1.18
- Layout Paragraphs 2.0.8
- Paragraphs 1.17
- Mercury Editor 2.1.1

Patch #14 by @DamienMckenna works; however, for the brief moment that I looked at this patch it doesn't look it integrates well with Mercury Editor on the node creation page meaning that the content is not using the Mercury Editor inline editor.

@Hebl calls out a good fact and it looks like they are working on something https://www.drupal.org/project/layout_paragraphs/issues/3306081 ✨ Support cloning of paragraphs by integrating with popular contributed clone/replicate modules Active

I've applied the patch from layout_paragraphs and installed the layout_paragraphs_quick_node_clone submodule and it works without an issue. However, like @godotislate mentions our setup is relatively simple and does not include translations. Additionally, on the node clone create page the inline editor for Mercury Editor is displaying. So while patch #14 works, I'd advocate for the adopting the Layout Paragraphs submodule approach if you have a similar issue of cloned content not appearing when using layout paragraphs and quick node clone.

Patch with ME flag is committed on the GIN side. Closing issue here.

Thank you all for this thread. Working through integrated composer with a custom upstream on Pantheon and ran into this issue. On symphony/6.4.10 the patch in 31 doesn't work as anticipated. I was experiencing this issue that went through a 6.4.9 iteration where the warming issue came up. I had to manually run cron and the issue appears to have cleared itself.

Again thank you all.

I've tested Mercury Editor with the most recent changes from MR !476. The save button is available on both the creation of a node with ME and the edit of a node with ME.

Thank you for the update from str_contains to strpos. Old habits die hard.

Hi - I'm in Drupal 10.3.1 using layout paragraphs and came across this issue today. The call by @miro_dletlker had me search core for this issue.

Not sure if this will address the issue that others reported but there is a core issue open where I was able to address my current issue.

https://www.drupal.org/project/drupal/issues/2973863 🐛 ValidReferenceConstraintValidator should not try to enforce data integrity on pre-existing references Needs work

I'm in Drupal 10.3.1 using Mercury Editor, Layout Paragraphs and Paragraphs.

We are getting the following error when editing a node with the above setup with a particular paragraph type which is referencing an image (the image is not using a view to render - it is default).

This entity (paragraph: [paragraph id #]) cannot be referenced.

I found initially that I could clone the entity, delete the original, and then save the node. However, on the next edit the issue still remained.

I tried the patch from 39 and could not apply it.

I tried the patch from 38 and it addressed my specific issue.

Issue ended up resolving itself. I wasn't able to track down the exact root cause and what resulted in the fix; however, after an update to Drupal core this functionality started working for us again. We're currently in Drupal 10.3.1 with no issues.

pbabin → created an issue.

@szeldler & @saschaeggi - Can I propose the following change?

if (!isset($form['#gutenberg_enabled'])) {
to
if (!isset($form['#gutenberg_enabled']) && !str_contains($form['#form_id'], 'mercury_editor'))

The forms that come in from mercury_editor on edit and create is node_sf_paragraph_page_mercury_editor_form.

I've tested this change locally and it addresses the disappearing save button when using mercury editor.

If so, I'm happy to put in a merge request with the proposed change.

@saschaeggi In #13 is the fix for Mercury Editor in dev https://www.drupal.org/project/gin/issues/3459995 🐛 null is not an object (evaluating 'newParent.querySelectorAll') Fixed or something else? With the null is not an object patch with Mercury Editor the save buttons are gone. Mercury editor is looking for the ID #edit-submit which doesn't exist at this time and then hides it with javascript.

I've tried adding the mercury editor form to the code that is referenced in https://www.drupal.org/project/gin/issues/3461545 🐛 Buttons missing or not working properly in Views Active but this doesn't bring the save buttons back.

I tried the hook_gin_ignore_sticky_form_actions() without success.

Applying this patch to RC13 and removing the null is not an object patch addresses both issues in Mercury Editor.
Applying this patch to RC13 and leaving the null is not an object patch also works.

Thank you for the update and being able to parse through my sparsely populated bug report.

I've applied this patch and it removed the error for us so all of our tests passed without an issue at this point.

pbabin → created an issue.

I re-applied a few other patches and then added #237 from above. The session has not been set error that was previous being displayed is now removed. In our setup, I'm not seeing an issue.

@montag64 - I ended up having to remove another one of our patches for facets. Standard Drush cr after the build nothing else

Before 10.3 these were the patches we used

      "Facets and exposed filters don't work together with Ajax": "https://www.drupal.org/files/issues/2021-12-05/3168241-8.patch",
      "Ajax facet block seems to lose Views context": "https://www.drupal.org/files/issues/2023-01-04/2986981-32.patch",
      "Config imports of facets leads to fatal errors": "https://git.drupalcode.org/project/facets/-/merge_requests/199.patch"

after 10.3

      "Ajax issues": "https://www.drupal.org/files/issues/2024-05-07/3052574-212.patch",
      "Config imports of facets leads to fatal errors": "https://git.drupalcode.org/project/facets/-/merge_requests/199.patch"

Duplicate of https://www.drupal.org/project/facets/issues/3395567 🐛 Config imports of facets leads to fatal errors Fixed closing

Patched with MR55 in Drupal 10.3 without an issue and confirmed previous failing Cypress tests on our end our now passing. Thank you @just2pin for such a quick update.

Upgrading to 10.3 had the same issue as neclimdul and montag64 - I used the 3052574-212.patch to get this resolved.

Just added this to our code base and tested with Safari. Without we are not able to adjust the dialog size. With it, we are now able to adjust the size. Please note we are using MR 55 in addition to this so we are using Drupal 10.3 and there is an issue with dialogs and jQuery which that merge requests fixes.

We are experiencing the same issue with ME and upgrading to 10.3

Ran into an issue today that triggered this for us in Drupal 10. Patch from #6 fixed the issue.

Ran into an issue today that triggered this. The patch from MR! 1300 fixed our issue.

I think this is a core issue and not a conditional_fields error. https://www.drupal.org/project/drupal/issues/2722319 🐛 s using Text Editor always fail HTML5 validation when "required" is added via #states Needs work

We're running Drupal 10.2.5 and ran into this issue where we have a required rtf ckeditor 5 field dependent on if another field is checked. If checked, then rtf field is required. If not checked, then rtf field is not required. The issue appears if the conditions are met on the creation of a new node. I tried the #12 patch and it did not work. After recreating the conditional in a hook_form_alter the error was still there without the conditional_fields approach.

After applying the core patch, the hook_form_alter code I was working on started working and the setup we have using conditional_fields also worked without the error.

pbabin → created an issue.

pbabin → created an issue.

I am experiencing this issue with media (images) embedded in an event content type RTE body in CkEditor 5. We are in Drupal 10.2.4 w/ PHP 8.2 and using the 8.x-3.0 branch of the Entity Share suite of modules. I also have the "Embedded entity' configuration option turned on in my import entity config settings.

On the client side we end up with - The referenced media source is missing and needs to be re-embedded.

I have json api extras turned on to disable some items. As a test, I re-enabled all of the items I disabled and attempted the sync of the content type and the issue remains the same.

There are no errors in the log that appear.

I added xdebug breaks on the functions doTransform() and doUndoTransform() in the EntityShareEmbeddedEntitiesEnhancer.php; however, when I run the pull on the client these function are not triggered. This is the only place I saw .*data-entity-type="(.*)... being used as referenced in this ticket.

Is there anything that I might be overlooking what would cause the entity within the RTE instance not to be brought over correctly?

Thank you in advance.

We're looking at needing something like this as well. Has anyone been able to successfully do this and can share their code? We're just using crop api with image widget crop. I see in the database all the points that @maxpah and @grimreaper are making so I think we should be able to pass the crop information along; however, I am at a loss of where to start. It doesn't look like there is any traction on the crop api side. So is it advisable to add these modifications into our own module and try the import?

Any guidance to point me in the right direction is greatly appreciated. Entity share is such an amazing tool and our organization is extremely grateful for all that it does!

Thank you in advance.

One finally worked. I threw the following into a .module file. Very specific but may help others if they come across a similar situation where trying to implement layout_options using layout_paragraphs.

Chees.

/**
 * Implements hook_form_layout_paragraphs_component_form_alter().
 */
function my_module_form_layout_paragraphs_component_form_alter(array &$form, FormStateInterface &$form_state) {
  // Get title of paragraph form.
  $paragraphType = $form["#title"]->getArguments()["@type"];
  // Section one column limit options based on role.
  if ($paragraphType === 'Section') {
    $form['#after_build'][] = 'uclahs_custom_paragraph_after_build';
  }
}

/**
 * After build callback for layout options in layout paragraph.
 * Extend and generalize as needed if future layout options restriction needed.
 *
 * @param array $element
 *   The form element array.
 * @param \Drupal\Core\Form\FormStateInterface $form_state
 *   The Form state.
 *
 * @return array
 *   The modified form element array.
 */
function my_module_paragraph_after_build(array $element, FormStateInterface $form_state): array {
  $current_user = Drupal::currentUser();
  $user_roles = $current_user->getRoles();
  $needles = ['role_1', 'role_2', 'role_3'];
  if ($current_user->id() !== '1' && !array_intersect($needles, $user_roles)) {
    $element["layout_paragraphs"]["config"]["layout"]["background"]['#access'] = false;
  }
  return $element;
}

pbabin → created an issue.

If you have an existing installation of this package with Address 1 just updating to 2.0 prevents the ability to update from Address 1 to Address 2. Slightly modified patch.

Duplicate of https://www.drupal.org/project/address_map_link/issues/3411810 🐛 Composer dependency on old version of Address Needs review

pbabin → created an issue.

I can confirm this worked in a similar situation. We have both modules installed and saw the same error. It is removed once this patch is applied.

@thetwentyseven - thank you for the patch!

We have this working on a multisite setup in Acquia Site Cloud Factory. Thank you all for your work on this. There was only one change we needed to make . . . we had a symlink to ../vendor/simplesamlphp/simplesamlphp/www that needed to be updated to ../vendor/simplesamlphp/simplesamlphp/public. Minimal tests confirm login is working on the sites, role syncing and masquerade is working. I mention the last two as we have patches for that functionality and they are not affected by the update and still apply.

Again - thank you to everyone that has worked on this. Looking forward to getting into D10!

Confirmed patch works with upgrading to 4.0.3, applying patch and visiting the failed pages from before. Thank you - also learned something new about ternary operators.

pbabin → created an issue.

We're using patch #34 with image widget crop and responsive images. It's working like a charm. Without it the images were not displaying correctly. Thank you for this fix.

@adriancid - spun up a separate branch of our code with the latest dev branch of admin_toolbar. Spot checked 5 or 6 of the tests I remember borking in cypress and they are passing now. For us, when the code in dev is pushed, we won't need the patch offered on this page.

We ran into the same issue. We are using Gin (RC3 which has tried to address some of the issues with the recent update) and all of our cypress tests fail due to this javascript error. Adding this patch worked in our case.