🇺🇸United States @webdrips

Re-rolling #11 for 1.6, and had to rework some parts of the code. We make some assumptions in the code, but it should work as long as the defaults are used for published and un-published states (published and archived, respectively).

The code should also check if the transitions are allowed, but that gets bypassed right now.

Same issue here; I think the cloning process might need to be done in a batch to avoid the issue.

However, the form to configure the clone is the one that's having the issue.

I can confirm this is an issue with feeds mapping, as I have a similar issue.

Seems the issue is actually coming from Claro's tableselect.css:

.position-sticky thead {
    position: sticky;
    z-index: 500;
    top: var(--drupal-displace-offset-top);
}

If you change it to top:unset, it fixes the overlap issue.

Even with the updated patch plus #3092247-62: "[PP-1] Prevent content from being deleted when there is an active workspace", I'm not able to upload images in the non-default workspace.

I get the following error via Ajax:

Drupal\Core\Entity\EntityStorageException: This entity can only be saved in the default workspace. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 817 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php). workspaces_entity_presave(Object)
call_user_func_array(Object, Array) (Line: 409)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object, 'workspaces') (Line: 388)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('entity_presave', Object) (Line: 416)
Drupal\Core\Extension\ModuleHandler->invokeAll('entity_presave', Array) (Line: 217)
Drupal\Core\Entity\EntityStorageBase->invokeHook('presave', Object) (Line: 900)
Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('presave', Object) (Line: 529)
Drupal\Core\Entity\EntityStorageBase->doPreSave(Object) (Line: 753)
Drupal\Core\Entity\ContentEntityStorageBase->doPreSave(Object) (Line: 483)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 806)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 352)
Drupal\Core\Entity\EntityBase->save() (Line: 293)
Drupal\file\Upload\FileUploadHandler->handleFileUpload(Object, Array, 'public://hero_images/', 0) (Line: 658)
file_save_upload('field_content_hero_0_subform_field_hero_image_0', Array, 'public://hero_images', NULL, 0) (Line: 536)
_file_save_upload_from_form(Array, Object) (Line: 1007)
file_managed_file_save_upload(Array, Object) (Line: 76)
Drupal\file\Element\ManagedFile::valueCallback(Array, Array, Object) (Line: 337)
Drupal\file\Plugin\Field\FieldWidget\FileWidget::value(Array, Array, Object)
call_user_func_array(Array, Array) (Line: 1266)
...

Trying this again as the last patch missed a directory.

Trying this again as the last patch missed a

Reroll #30 for 10.2.2, but would expect it to work on 11.x based on the minor change.

Third time is a charm: re-roll for 10.2

Ignore last patch; let's try this again

Rerolling #82 for 10.2

webdrips → created an issue.

Attaching a patch against 3.0.x-dev that fixed the issue for me.

I agree, and I've tried various versions, such as 2.0.6, 3.0.0-beta1, and 3.0.x-dev (all on Drupal 10).

They seemed to work on Drupal 9, so I believe D10 maybe the issue.

Changing the status back to active

webdrips → created an issue.

@Dave Reid only thing I can think is it was somehow lost during a D9 to D10 upgrade, as that's when I noticed the issue.

I can confirm a fresh install on D10 doesn't have this issue.

Since it may be an edge case, not sure if you want to add some sort of message on the status report page about the settings not being complete and/or a better error message?

IMHO, it should not fail the way it did though.

Otherwise, I think this can be closed.

RC4 Removed the Status Report error message for me.

I'm not sure if it's best to start a new issue or use this one, but after upgrading to RC2 and running the database updates, I'm noticing the following:

ENTITY/FIELD DEFINITIONS
Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
File
The URL alias field needs to be uninstalled.

This was the only update I applied, so I don't see how this error could've come from anywhere else.

I tried uninstalling this module and reinstalling it (after running Cron), and the same for pathauto, but I can't seem to get rid of this message.

Hi @Tirupati_Singh I'm able to repeat this on two separate servers. Perhaps I can send you some configuration files so you can try again to repeat this?

Not sure if I missed a step above like adding this to the CKEditor WYSIWYG? We are using CKEDitor 5 (Drupal core)

If so, let me know which configuration files you need?

Also we don't have private files set up, so I'm not sure if that could be the issue as well?

#192 and the Entity Field Condition module with this patch work for me on D10.1.6: https://www.drupal.org/project/entity_field_condition/issues/3091898#com... ✨ Generic Entity Field Value Plugin Needs review

#43 (and #19) no longer seem to work for me on Drupal 10 sites (10.1.5 or 10.1.6). I can't edit an existing field condition for visibility controls nor add a new one.

In both cases, I get "error: context "entity" is missing." with an "Update" button that does nothing and a "Back" link.

Steps to reproduce on an existing block with an existing rule:

1. Click the context menu and select "control visibility"
2. Click Edit
3. "error: context "entity" is missing."

On a new block or one without a visibility condition:

1. Add the block to the layout builder
2. Context menu > control visibility
3. Select Field Value and click Add condition
4. "error: context "entity" is missing."

The field in question is a list (text) field.

webdrips → created an issue.

Okay yep that was it. Anyone using their own override of views-view-fullcalendar.html.twig must make sure to update it.

Specifically, you want to make sure these lines are use the proper html attributes:

<div class="js-drupal-fullcalendar" data-calendar-view-index="{{ view_index }}" data-calendar-view-name="{{ view_id }}" data-calendar-display="{{ display_id }}"></div>
<select id='locale-selector-{{ view_index }}' data-calendar-view-index="{{ view_index }}"></select>

If you're using the old template override, you will have this (or something you overrode) instead:

 <div class="js-drupal-fullcalendar" calendar-view-index="{{ view_index }}" calendar-view-name="{{ view_id }}" calendar-display="{{ display_id }}"></div>
<select id='locale-selector-{{ view_index }}' calendar-view-index="{{ view_index }}"></select>

@Mingsong perhaps it would be helpful to let people know when upgrading the module to check if that file is being overridden with some sort of status message.

@Mingsong I don't seem to have any of those divs in my output.

In fact, I don't see the proper template at all. I see views-view.html.twig, but the fullcalendar template is never used.

For anyone coming here after upgrading to the latest version of the module, and seeing this is fixed, I had to uninstall and re-install the module to get the message to go away (and then re-import the config).

Not sure if there was a technical issue with getting a hook_update to work?

Providing a patch for now in case anyone wants to use the latest version of the module.

Adding the requested debugging, and there are no errors/warnings in the log.

Definitely cleared the cache; Drupal 10.1.6 PHP 8.1.24

Steps to re-produce: Upgrade this module from 5.1.12 to 5.1.13

See related screenshots.

@FJvdP try the latest dev just released.

Hmm my patch from #8 doesn't apply anymore, but I'm not sure it's needed now. I tried testing a few super generic words, such as "the", and didn't see any duplicates. Perhaps we can just mark this as needs review without the patch?

#92 works for me (Drupal 10.1.5), thanks.

I believe the priority on this should now be critical as CKEditor 4 is EOL at the end of this year.

The automation bot applied the updates to dev, which is actually older than the release version. I think this needs to be set back to needs work to get the proper patch in place.

Re-rolling against 6.0.3, but I can't seem to figure out where this was being used in the project, so someone else will need to test.

https://www.drupal.org/project/drupal/issues/3392572 🐛 Add missing category to Drupal\layout_builder\Plugin\Layout\BlankLayout and let modules and themes alter the list of layouts RTBC

Some combination of paragraphs manage fields, layout builder, and possibly field layout.

The patch resolved the issue.

#8 fixed the deprecated code error for me on the Paragraphs manage form display, although I don't see any empty layout settings except the default one that shows up after installing layout builder (and field layout?):

<option value="layout_builder_blank"></option>

But then I didn't get that same deprecated function error on another more vanilla D10 instance, so I'm not sure what's going on.

I don't think the patch works in all layouts (see attached).

Same as @darren.fisher #12, reverting to 5.1.12 fixed the issue for me.

I have an exposed taxonomy filter if it matters to help reproduce.

Patch #35 kicks out an error:

ParseError: syntax error, unexpected identifier "parent", expecting ";" in Composer\Autoload\includeFile() (line 443 of modules/contrib/entity_field_condition/src/Plugin/Condition/FieldValue.php).

For me, the dropdown list wasn't even sorting by the weights set, and I had to set my custom module weight to 12 (one higher than paragraphs) to get the following code working:

...
switch ($form_id) {
  case 'blah':
    $field = 'field_blah';
    break;
...
}

if (isset($form[$field]['widget']['add_more']['add_more_select']['#options'])) {
  natsort($form[$field]['widget']['add_more']['add_more_select']['#options']);
}
...

Forgot to change the status back to "Needs work"

+1 we desperately need a working D10 version ASAP.

Moving this to the proper project.

Re-applying patch from latest migrate_tools dev that uses new src/Drush dir.

The patch works for D 9.5.10, but not 10.1.2.

Either that, or there's something else wrong. I have the patch to make this module D10 compliant as well.

Anyone have this working on D10?

The patch supplied was malformatted as it contained the webroot in the path; the attached patch addresses this.

If you have the patch from https://www.drupal.org/project/bootstrap_paragraphs/issues/3349742 🐛 "Unsupported operand types: string + int" error on multiple templates Fixed , you'll need this patch instead.

D10 patch against latest dev attached (generated via rector). I haven't tested this yet, but it does pass the D10 Upgrade Status sniff test.

@chike I agree, thanks for posting that. The module now passes the upgrade status check.

This patch didn't work for paragraphs:

drush dcder node --bundle=landing_page --entity_id=XXXX
 [warning] Undefined array key "nid" Exporter.php:539
 [warning] Trying to access array offset on value of type null Exporter.php:539
 [warning] Trying to access array offset on value of type null Exporter.php:539
 [warning] array_flip(): Can only flip string and integer values, entry skipped EntityStorageBase.php:312
 [notice] Exported 1 entities of the "node" entity type.

Thanks for the tip @bcdev, that worked for me :)

Neither #8 nor #12 applied correctly for me on 2.1 (applying patches via composer).

#2 didn't apply for me using the latest dev version.

#8 didn't work for me.

I have the exact use case as #6, and we're using D 9.5.9 and version 2.0.0 of DCD.

My steps:

1. Migrate the D7 to fresh D9 site
2. drush config-set "system.site" uuid [Redacted]
3. drush migrate:upgrade --blah --blah
4. drush su (sync UUIDS via a module)
5. drush cim
6. drush dcde menu_link_content (run on prior migrated site using the same menus)
7. drush dcdi --include-id (back to the original site on the above steps)

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1011' for key 'PRIMARY': INSERT INTO "menu_link_content" ("id", "revision_id", "bundle", "uuid", "langcode") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placehold
  er_4); Array
  (
      [:db_insert_placeholder_0] => 1011
      [:db_insert_placeholder_1] =>
      [:db_insert_placeholder_2] => main
      [:db_insert_placeholder_3] => [redacted]
      [:db_insert_placeholder_4] => und
  )

Note: this still works fine on version 3.x of the module.

/**
 * Helper function from menu_item_extras_install to fix the link bundles.
 */
function MYMODULE_fix_menu_link_bundles() {
  \Drupal::entityTypeManager()->clearCachedDefinitions();
  $menus = \Drupal::entityTypeManager()
    ->getStorage('menu')
    ->loadMultiple();
  /** @var \Drupal\menu_item_extras\Service\MenuLinkContentService $mlc_helper */
  $mlc_helper = \Drupal::service('menu_item_extras.menu_link_content_helper');
  $mlc_helper->doEntityUpdate();
  $mlc_helper->updateMenuLinkContentBundle();
  $mlc_helper->installViewModeField();
  if (!empty($menus)) {
    foreach ($menus as $menu_id => $menu) {
      $mlc_helper->updateMenuItemsBundle($menu_id);
    }
  }
  $mlc_helper->doBundleFieldUpdate();
}

drush cr
drush eval "MYMODULE_fix_menu_link_bundles();"

The patch from #31 still has the same issue I reported in #25 unfortunately.

Here is the full stack trace:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "entity_field_condition.subform.helper_factory". in Drupal\Component\DependencyInjection\Container->get() (line 157 of core/lib/Drupal/Component/DependencyInjection/Container.php).

Drupal\entity_field_condition\Plugin\Condition\FieldValue::create() (Line: 21)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() (Line: 59)
Drupal\Core\Condition\ConditionManager->createInstance() (Line: 72)
Drupal\layout_builder\EventSubscriber\SectionComponentVisibility->onBuildRender()
call_user_func() (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 117)
Drupal\layout_builder\SectionComponent->toRenderArray() (Line: 88)
Drupal\layout_builder\Section->toRenderArray() (Line: 316)
Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildSections() (Line: 275)
Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildMultiple() (Line: 340)
Drupal\Core\Entity\EntityViewBuilder->buildComponents() (Line: 24)
Drupal\node\NodeViewBuilder->buildComponents() (Line: 282)
Drupal\Core\Entity\EntityViewBuilder->buildMultiple() (Line: 239)
Drupal\Core\Entity\EntityViewBuilder->build()
call_user_func_array() (Line: 101)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 788)
Drupal\Core\Render\Renderer->doCallback() (Line: 374)
Drupal\Core\Render\Renderer->doRender() (Line: 204)
Drupal\Core\Render\Renderer->render() (Line: 242)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 243)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare() (Line: 132)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
call_user_func() (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 174)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 50)
Drupal\ban\BanMiddleware->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 23)
Stack\StackedHttpKernel->handle() (Line: 718)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Now using Drupal 9.5.9 and the EFC 8.1.4

I didn't need to do anything to get this error this time except view a page on the site.

We are using this in conjunction with the Layout Builder to show various views/fields based on field conditions (e.g. a taxonomy value).

#48 works for me :)

@hopfrog did you ever figure it out?

Re-rolling #65 for 9.5.9

The patch worked for me.

The problem occurred during a migration (I believe it was during migrate-import --all).

I couldn't view the site as an anonymous user.

@voleger, this is indeed still an issue.

For me, it had nothing to do with the group_content_menu module. I migrated from D7 to D9, and had the exact same issue (no ability to select a parent item).

I uninstalled this module, and the parent selection was back.

I applied the patch in #4, and the parent selection was still there.

I believe #4 addresses an issue with this module, and I can say it worked for me.

#30 worked for me on 9.5.9

Fixing a small issue with the last patch.

Rerolling #37 for 8.5.8

Hi @Lendude ahh yes sorry about that.

This is a bit more complex as we're using the exposed filter as a "normal" block, and the view block was placed using the Layout Builder as you suggested. We use a patch for layout builder to provide visibility rules. We're essentially taking the approach of trying to use Drupal's core modules as much as possible for maintainability.

In this case, we added the block with the layout builder, and used a taxonomy term value to control visibility.

The patch that allows that is here: https://www.drupal.org/project/drupal/issues/2916876 ✨ Add visibility control conditions to blocks within Layout Builder Needs work

We have 27 core patches for this project, so there may be others involved in pulling this off.

If I remove the combined filter block, the error disappears. If I put it back, I need to click search (with or without a value in the search field doesn't matter).

I'm happy to show you the issue over Zoom if it helps at all.

Rerolled against latest dev

webdrips → created an issue.

webdrips → created an issue.

#58 is working for me too: RTBC +1