Did some more digging and noticed that createHandlerInstance() in EntityTypeManager.php gets passed in a $class variable with the value of "Drupal\group_content_menu\GroupContentMenuStorage", which doesn't seem to exist? If I call $entity_type->setStorageClass(SqlContentEntityStorage::class); in group_content_menu_update_9301() before $definition_update_manager->updateEntityType($entity_type); gets called, then everything seems to work fine and the update goes through?
Hi again! I used drush php:eval "module_load_include('install', 'group_content_menu');group_content_menu_update_9301();" for debugging and was able to produce this:
Error: Class name must be a valid object or a string in /app/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php on line 283 #0 /app/web/core/lib/Drupal/Core/Entity/EntityTypeListener.php(112): Drupal\Core\Entity\EntityTypeManager->createHandlerInstance(NULL, Object(Drupal\Core\Entity\ContentEntityType))
#1 /app/web/core/lib/Drupal/Core/Entity/EntityDefinitionUpdateManager.php(159): Drupal\Core\Entity\EntityTypeListener->onEntityTypeUpdate(Object(Drupal\Core\Entity\ContentEntityType), Object(Drupal\Core\Entity\ContentEntityType))
#2 /app/web/modules/contrib/group_content_menu/group_content_menu.install(24): Drupal\Core\Entity\EntityDefinitionUpdateManager->updateEntityType(Object(Drupal\Core\Entity\ContentEntityType))
#3 /app/vendor/drush/drush/src/Commands/core/PhpCommands.php(32) : eval()'d code(1): group_content_menu_update_9301()
#4 /app/vendor/drush/drush/src/Commands/core/PhpCommands.php(32): eval()
#5 [internal function]: Drush\Commands\core\PhpCommands->evaluate('module_load_inc...', Array)
#6 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array(Array, Array)
#7 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#8 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#9 /app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(391): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#10 /app/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#11 /app/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#12 /app/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#13 /app/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#14 /app/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#15 /app/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /app/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run(Array)
#17 /app/vendor/drush/drush/drush(4): require('/app/vendor/dru...')
#18 /app/vendor/bin/drush(119): include('/app/vendor/dru...')
#19 {main}
Error: Class name must be a valid object or a string in Drupal\Core\Entity\EntityTypeManager->createHandlerInstance() (line 283 of /app/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php).
[warning] Drush command terminated abnormally.Apparently this is also being discussed in the Paragraphs EE modules issue queue with a possible fix: 🐛 Add in between button is no longer horizontally centered when using Gin Active .
We're experiencing the same issue when we upgraded: gin (3.0.0-rc13 => 3.0.0-rc14).
@heddn I'll get back to you at the end of the month when doing updates again.
Unfortunately nothing gets logged into Drupals logs. The only thing I'm getting is this in my terminal:
Module Update ID Type Description
-------------------- ------------------------- --------------- -------------------------------------------------------
group_content_menu 9301 hook_update_n 9301 - Update group content menus to be publisheable.
group_content_menu convert_to_revisionable post-update Update group content menus to be revisionable.
-------------------- ------------------------- --------------- -------------------------------------------------------
// Do you wish to run the specified pending updates?: yes.
> [notice] Update started: group_content_menu_update_9301
> [error] Class name must be a valid object or a string
> [error] Update failed: group_content_menu_update_9301
[error] Update aborted by: group_content_menu_update_9301
[error] Finished performing updates.
MR 36 seems to fix the issue for us. Running 2.1.1 w/Drupal 10.3.6.
alexander tallqvist → created an issue.
alexander tallqvist → changed the visibility of the branch 3224816-3170013-3x-combo to hidden.
alexander tallqvist → changed the visibility of the branch 3224816-3170013-3x-combo to active.
I'm encountering exactly the same issue. A caching solution where we can configure it with a simple key sounds like a great idea. At the moment, the only workaround I can think of is to manually import the source data into a database or store it locally on disk, and then run the migration against that stored data.
walkingdexter → credited alexander tallqvist → .
I've also tested this solution - working as expected (and IMO the right approach).
Hi @sukr_s. Turns out that my "Steps to reproduce" instructions were not thorough enough. In order to replicate the situation I'm experiencing, you need to have the media_entity_browser module installed together with its dependencies. These were my exact steps today when I reproduces the issue:
1. Install a fresh version of Drupal 10.3.2.
2. Enable the media and media_library modules that come with core.
3. Install and enable the media_entity_browser module together with its dependencies: composer require 'drupal/media_entity_browser:^2.0'; drush en media_entity_browser.
4. Disable the "Auto open entity browser" setting at: /admin/config/content/entity_browser/media_entity_browser_modal/edit.
5. Edit the article content type and add the previously mentioned fields:field_image_caption_short (short text field) andfield_main_media (entity reference to media, bundle=image, limit=1).
6. Edit the form display for the article content type and set the widget for the Main media field to: Entity browser -> Media entity browser (modal).
7. Create a custom module and add the previously posted hook to it.
8. Add an new article. Not that the field_image_caption_short is always displayed wheter or not the field_main_media field is referencing an image or not.
9. Apply the patch I posted in #2 and repeat step 7. Everything should work as expected.
I'm guessing you we're trying to replicate my issue with the "Autocomplete" widget, which indeed seems to work as intended. Also, said widget formats the selector name to field_main_media[0][target_id] instead of field_main_media[target_id], just as you said. I triple checked that the selector is indeed field_main_media[target_id] when using the media entity browser. My guess is that anytime any kind of JS functionality is involved, the #states break because of the missing detach method.
Adding the mentioned patch.
alexander tallqvist → created an issue.
Still experiencing the same problem @thatguy described when running Drupal 10.3.2. The patch provided in #5 seems to fix the issue. Re-rolling the same patch for 10.3.2.
alexander tallqvist → made their first commit to this issue’s fork.
I can also confirm that this does the trick. No need to configure any settings for the text format.
composer require 'drupal/ckeditor5_plugin_pack:^1.1'
drush en ckeditor5_plugin_pack ckeditor5_plugin_pack_find_and_replace
drush pmu ckeditor_find
drush cex -yStill experiencing this. Updated from Drupal 10.2.7 to 10.3.2. Had to manually go trough various node, taxonomy and views configuration in order to get the language back to the original English.
Re-rolled the patch for version 8.x-2.11. Seems to be applying / working fine. Running Drupal 10.3.2.
Tested the patch #2 with Drupal 10.1.8 and media_entity_download 2.0.0. Seems to be working as intended on our site. The files now have the correct filenames as their names when downloading them.
I discussed the implemented changes with a colleague and ended up modifying the merge request a bit. The route pathauto.bulk.update.form now required either the administer pathauto OR the bulk update aliases permission, and the route pathauto.admin.delete route requires either the administer pathauto OR the bulk delete aliases permission. This is because the administer pathauto permission indicates that a users should have access to everything pathauto related. The description for the administer pathauto permission has also been updated to reflect these changes.
I added a new merge request which can be tested. The merge request adds two new permissions to the module. The permission bulk update aliases is needed when accessing the pathauto.bulk.update.form route, and the permission bulk delete aliases when accessing the pathauto.admin.delete route. The tests and the description for the administer pathauto permission have also been updated to reflect the changes.
I'm planning to work on this the upcoming Friday at Siili Solutions Drupal-contrib day.
True, I managed to miss a few variables. On another note - do the "border size", "table drag" and "icon size" variables have anything to do with this issue, or should they be fixed somewhere else? If I'm not mistaken, it seems that only the once related to "dropbutton" are relevant (i.e. --dropbutton-border-size, --dropbutton-small-toggle-size and --dropbutton-extrasmall-toggle-size)? To me, #13 seems like a better solution when it comes to this specific issue. I wrote a new patch that targets only the related variables. Thank you for your work so far.
I quickly threw together this patch since I need it now. Might not be the best way to solve the issue, but it works for me. Personally I don't really have an opinion whether or not the variables from Claro should or should not be used.
I am experiencing exactly the same issue after upgrading to the RC6 version of the theme. I am also only using Gin as my admin theme, and our main theme is our own custom theme. Claro is also installed at version 9.5.10.
Im getting the same error on Drupal 9.5.9 when I just upgraded the module from version 2.0.0 to 2.0.1. Here is the full output:
Error message
Warning: foreach() argument must be of type array|object, null given in Drupal\Core\Render\Element\Checkboxes::valueCallback() (line 113 of core/lib/Drupal/Core/Render/Element/Checkboxes.php).
Drupal\Core\Render\Element\Checkboxes::valueCallback(Array, , Object)
call_user_func_array(Array, Array) (Line: 1287)
Drupal\Core\Form\FormBuilder->handleInputElement('siteimprove_settings_form', Array, Object) (Line: 1005)
Drupal\Core\Form\FormBuilder->doBuildForm('siteimprove_settings_form', Array, Object) (Line: 1075)
Drupal\Core\Form\FormBuilder->doBuildForm('siteimprove_settings_form', Array, Object) (Line: 1075)
Drupal\Core\Form\FormBuilder->doBuildForm('siteimprove_settings_form', Array, Object) (Line: 1075)
Drupal\Core\Form\FormBuilder->doBuildForm('siteimprove_settings_form', Array, Object) (Line: 579)
Drupal\Core\Form\FormBuilder->processForm('siteimprove_settings_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)The problem lies in the default values for some of the checkboxes. '#default_value' => $config->get('enabled_content_types') might be returning NULL, which is causing the warning. Applying the patch from the original issue seems to fix the problem for me.
Here's my attempt at a reroll for the 2.0.1 version of the module. No major changes - mainly had to move stuff around.