UID base field override configs can still have old default value callbacks

Does your status report show any outdated field definitions?

Can you search your site for this:

->setDefaultValueCallback('Drupal\node\Entity\Node::getCurrentUserId')

I think one of your contrib modules is using a removed method for a default callback.

Looking at my D8 code-base I can see that linky module and workflow (not the core one) do that - but there might be more.

Please set back to 'active' when you reply

Ok, can you search for the wider term Node::getCurrentUserId in your code-base?

Thanks

Then this is most definitely a bug. Thanks!

Any chance you know how this override was created? E.g do you use the base field overrides ui module?

Working on test coverage as part of Bug Smash Initiative.

This is reproducible by having a site that pre-dates 8.6.x

Working on test coverage first

Hoping for red/green here.

This one is a bit iffy as to where it belongs.

On one hand, the bug was introduced in 8.6.x when we deprecated Node::getCurrentUserId but we've since removed all the update paths from 8.6 etc - you can only update to 9.0 from the latest 8.x

So I think there is a place for this in 9.0/9.1 - because the release has shipped.

But I also think this definitely belongs in 8.9 as well.

But update path dependencies are not my strong suite, so I'll ping catch who is my go-to expert on such matters.

Crediting @PhilippJC who has done an awesome amount of sleuth work here, thanks!

New title taken from a similar report that I closed as a duplicate of this.

Can you please explain the change is DB dump?

The DB dump was created as follows:

• install minimal profile on 8.5
• enable node, content translation and language
• add article content type
• enable translation for article content type, but make author non-translatable - this creates a new base-field override for the uid field
• install drupal 8.9.1
• run update.php to get to the latest version of core
• run the dump command

Thanks, for adding the steps.

+++ b/core/modules/node/node.post_update.php
@@ -14,3 +14,26 @@ function node_removed_post_updates() {
+    if (isset($bundle_fields['uid']) && $bundle_fields['uid']->getDefaultValueCallback() === 'Drupal\node\Entity\Node::getCurrentUserId') {

I think we need to expand the scope of the fix here because this can't just this one case. How about resaving all the overridden basefields with default value callback?

1. +++ b/core/modules/node/tests/src/Functional/Update/NodeContentTranslationUpdateTest.php
   @@ -0,0 +1,45 @@
   +    /** @var \Drupal\Core\Entity\EntityFieldManagerInterface $entity_field_manager */
   +    $entity_field_manager = \Drupal::service('entity_field.manager');
   +    $fields = $entity_field_manager->getFieldDefinitions('node', 'article');
   +    /** @var \Drupal\Core\Field\FieldDefinitionInterface $author */
   +    $author = $fields['uid'];
   +    $this->assertEquals('Drupal\node\Entity\Node::getCurrentUserId', $author->getDefaultValueCallback());
   

   We're lucky this works. I'm not sure that we could continue to trust this.

2. +++ b/core/modules/node/tests/src/Functional/Update/NodeContentTranslationUpdateTest.php
   @@ -0,0 +1,45 @@
   +    $entity_field_manager->clearCachedFieldDefinitions();
   

   We should load a fresh object from the container as the container will be rebuilt during the update.

3. I wonder if there are other callbacks might be in this situation

4. +++ b/core/modules/node/node.post_update.php
   @@ -14,3 +14,26 @@ function node_removed_post_updates() {
   +/**
   + * Updates stale references to Drupal\node\Entity\Node::getCurrentUserId.
   + */
   +function node_post_update_modify_base_field_author_override() {
   

   I was wondering whether this needs to be a hook_update_N

   Yes it is fixing config but what happens if that config is invoked during another post update.

I think we need to expand the scope of the fix here because this can't just this one case. How about resaving all the overridden basefields with default value callback?

But that's a valid use of the API - to change the default value callback. I don't think we can do that for cases we know nothing about. Although we could check if it is_callable I suppose.

#22.1 can you elaborate?

#22.2sure
#22.3not sure, we can check is callable I guess, and set back to the base default if not
#22.4not sure either, happy to be guided either way

Re #22.1 we're depending on the code to by compatible with an 8.9.x db - we're making quite high level API calls - like some change in field definitions might break this and require an update to be run.

This happens with other entity types as well: media entities, paragraphs, and so on. Basically, all entities are can be affected that use EntityOwnerTrait. (edited)

Hotfix is updating default_value_callback to <EntityClass>::getDefaultEntityOwner in every uid base field override (core.base_field_override.<entity_type_id>.<bundle>.uid.yml).

Setting back to NW because of #25.

More than node: Yes.

All that use EntityOwner: No.

It happens for those that deprecated their old default value callback in favor of the new one provided by EntityOwner. So we have to extend it to specific types in core that got that treatment from the referenced issue and its follow-ups.

#27 is right, @Berdir, thanks for pointing this out.

#16: This should ideally go into both 8.9.x and 9.x (and the update needs to have the same name, or we get into trouble, see below).

It has to go into 9.x because we allow updates from 8.8.0, and it should go into 8.9.x because this allows sites to make the smallest possible steps towards 9.x (i.e. updating to the latest 8.9.x version prior to going to 9.0.x, and having one less 9.0.x update to run).

I think the shortest version of 8.9 and 9.x update trouble I can give is as follows:

1. New post update in both 8.9 and 9.0 - OK
2. New post update tin 9.x only - OK
2. New hook_update_N() in both 8.9 and 9.0 - OK
3. New hook_update_N() in 9.x only - PANIC!!!! (longer explanation at #3108658: [policy] Handling update path divergence between 9.5.x and 10.1.x).

#22.4 - while the config is invalid, the invalid thing is the value pointing to a wrong method. So I think other config manipulation in a post update would be fine - we only get the error in the OP because code is trying to call the method, which an update is extremely unlikely to do. Given that a post update feels correct in this case.

@catch I'm not sure I agree with

we only get the error in the OP because code is trying to call the method, which an update is extremely unlikely to do.

I think a post update for a site could easily have a node creation or something like that thatcould result in this error - no?

@alexpott you might hit the error itself if you were creating a node in a post update or similar, but it's not a conflict between the update functions themselves which is the usual reason we make things hook_update_N() vs post update.

Also a post update relying on getCurrentUserId() would be wrong - it should either specify anonymous or a specific user, but not depend on whether the update is run from drush or via the UI and who was logged in at the time (hence more unlikely that someone writes an update depending on that functionality).

@catch good point. I guess post update is okay here.

+++ b/core/modules/node/node.post_update.php
@@ -14,3 +14,26 @@ function node_removed_post_updates() {
+  /** @var \Drupal\Core\Entity\EntityFieldManagerInterface $entity_field_manager */
+  $entity_field_manager = \Drupal::service('entity_field.manager');
+  $fields = $entity_field_manager->getBaseFieldDefinitions('node');
+  /** @var \Drupal\Core\Field\FieldDefinitionInterface $author */
+  $base_field = $fields['uid'];
+
+  $node_types = \Drupal::entityTypeManager()
+    ->getStorage('node_type')
+    ->getQuery()
+    ->execute();
+  foreach ($node_types as $node_type) {
+    $bundle_fields = $entity_field_manager->getFieldDefinitions('node', $node_type);
+    if (isset($bundle_fields['uid']) && $bundle_fields['uid']->getDefaultValueCallback() === 'Drupal\node\Entity\Node::getCurrentUserId') {
+      $config = $base_field->getConfig($node_type);
+      $config->setDefaultValueCallback('Drupal\user\EntityOwnerTrait::getDefaultEntityOwner')->save();
+    }
+  }

Do we have to move this to \Drupal\Core\Field\Entity\BaseFieldOverride::preSave() or do something like ViewsConfigUpdater - so we can fix any base field overrides stored in config in modules / install profiles?

+++ b/core/modules/node/node.post_update.php
@@ -14,3 +14,26 @@ function node_removed_post_updates() {
+  foreach ($node_types as $node_type) {
+    $bundle_fields = $entity_field_manager->getFieldDefinitions('node', $node_type);
+    if (isset($bundle_fields['uid']) && $bundle_fields['uid']->getDefaultValueCallback() === 'Drupal\node\Entity\Node::getCurrentUserId') {
+      $config = $base_field->getConfig($node_type);
+      $config->setDefaultValueCallback('Drupal\user\EntityOwnerTrait::getDefaultEntityOwner')->save();
+    }

EntityOwnerTrait uses the class name as the callback, not the trait, I think we should keep that in sync.

Also, a bit unsure why this goes through the base and bundle field definitions instead of working with base field overrides entities directly as I did in #3159029: Update base field definitions that use the old default value callback, I think that's OK and simpler?

That said for an update function, we might want to use raw config API directly then.

Not sure about the preSave() thing, for other things we removed BC layers like that in 9.x as well together with the update functions.

I added a patch to resolve it based on other contrib modules.

Sorry, wrong Class

I solved my Error

I upgrade my drupal8 site to drupal9 and found error as below:

Error: Call to a member function getAccountName() on null in Drupal\node\NodeForm->form() (line 155 of core/modules/node/src/NodeForm.php).

Resolved by following steps:

There was config file in my "config/sync" folder.

core.base_field_override.node.content_type_name.uid.yml
core.base_field_override.node.content_type_name.uid.yml

Issue was on below line, in above config file.

default_value_callback: 'Drupal\node\Entity\Node::getCurrentUserId'

Either you can blank it as below

default_value_callback: ' '

OR

Remove that config file completely.

I removed that config files & drush cim to update in DB as well then drush cr

and Problem Solved. Hope this may help someone!

I've hit this issue with a multi-language site that pre-dates 8.6.x — originally launched on drupal 8.5.x.
The site is using core media and only a few contrib modules — pathauto, token, metatags, etc.

After moving from drupal 8.9.3 to drupal 9.0.3, adding new media leads to SQL exception.

The fix, as suggested by mukeshkanzariya in post #37, worked, but I am expanding it bellow for better readability.

cd ~/sites/drupal/web
../vendor/bin/drush cex
cd ../config/sync/example
rm *uid.yml
cd ~/sites/drupal/web
../vendor/bin/drush cim
../vendor/bin/drush cr

Every site that pre-dates 8.6.x and use content translation, core media will hit this issue.

Hope the above helps.

The rm *uid.yml might delete too much, review very carefuly what config is deleted and/or make the wildcard more specific, eg. core.base_field_override.*uid.yml. Also, review your translation settings after that for those fields, because that's what you delete with this.

I appreciate your note—Thanks!

In our case it was fine.
../config/sync/example/
only had

core.base_field_override.media.audio.uid.yml
core.base_field_override.media.file.uid.yml
core.base_field_override.media.image.uid.yml
core.base_field_override.media.remote_video.uid.yml
core.base_field_override.media.video.uid.yml

It's a simple website with little content and just two languages—only using core media images out of all types—never had translation settings on them as it was not needed.

i also have these errors after update to 9.0.3 from 8.9.
is there any progress on fixing this bug?

Also had this error after upgrade 8.9 to 9.0.3. 3153455-15.patch fixed it. But we should run 'drush updb' after patch was applying. After DB was updated error is gone.

This needs work to handle other entity types and address the other reviews.

Hi, there. I have the same issue while manually upgrading from 8.9 to 9.0.x, I thought it was caused by the Schema org Metatag 8x -1.x,
the same issue
now the same, when manually upgrading from Drupal 8.9.7 to Drupal 9.0.7 with the Schema.org Metatag 8x-2.1.

Updated many sites from D8 to D9. Most of them broken after the update (Cannot add new content) due to this bug :-(
I have created a fixing script. If you have Drush available and are on Linux (i.e. with bash available) you can use this:

https://gist.github.com/rgpublic/ddab5b2c763f30574c8a6d5eaa9cd339

It will look for all content types and all bundles. If it finds sth. worth fixing, it will fix it automatically.

(!)
Make sure you backup your files and database. No guarantees.
It might kill your cat and I don't just mean you cannot print files afterwards. ;-)
(!)

Can't create any new article after an upgrade to Drupal 9.x. Just to update: tried to upgrade from a cleaned dev website, with no modules. From 8.9.11 to 9.10, the same error referring to the core/modules/Node.php. Cleaned all caches manually in the admin.php, like cache_entity, cache_config, etc, nothing changed.

I have fixed 2 sites with advice #10.

Both sites are upgraded from Drupal pre 8.5 to D9.1 and converted to composer-managed sites.

I had to fix manually all my content types config records as suggested in #10. If you have 10 content types... 10 records need fixing.

@devad, I begin to understand this, I've navigated to core.base_field_override.node.page.uid in the myPhp admin via Cpanel, is there any way to edit it manually? There are no 'default value' records in the sql tables, just tech data, via cpanel (I don't use drush or anything likthat). Would appreciate your advice!

Deleting my post since @Berdir answer below is the correct one.

You should not manually change the serialized data in the config table, that is risky. You can easily do this in the UI, in configuration management under configuration > development. Either do a bulk export, change all the uid files you find manually and then re-upload it, or do it one by one, export a single config file, copy it, paste it into the single import, change the value and save.

@Berdir, so you mean I need to install the 'Configuration Manager' module and do it, in order to affect the table? I understand it is nested physically in the sql table and not in any files in the core.

@droodpal #52

Configuration Manager is a Drupal Core module.

You can install it, do what you need it for and then uninstall it.

Yes, the process explained by Berdir will fix your config sql table data.

If you need... you can read more detailed steps in post #10.

@devad that worked, it only had 2 uid.yml file types, thank you all.

#10 works for me!

I just edited all the core.base_field_override.node.MY-CONTENT-TYPE.uid.yml from my conf replacing the getCurrentUserId by getDefaultEntityOwner on default_value_callback

Thank you PhilippJC! I did #10 and the issue is fixed. would prefer if these entries did not have code that would break on updates.
Previously did the PHP patch suggested in another post, but I reversed the patch and did this fix.

In my case, I was able to resolve this by editing my config override files, and then re-importing them. I guess the method name changed somewhere along the way, but not in a way that updated my site's config. Updating those config overrides was a much simpler and more elegant solution than patching Drupal's codebase to accommodate this disconnect.

Example 1:
'Drupal\node\Entity\Node::getCurrentUserId' needed to become 'Drupal\node\Entity\Node::getDefaultEntityOwner'

Example 2:
'Drupal\media\Entity\Media::getCurrentUserId' needed to become 'Drupal\media\Entity\Media::getDefaultEntityOwner'

In My case, it was showing same error. i replaced all my config files that was suggested in #10. My multisite architecture works as expected now, thanks for the suggestion. Really saved my day after upgrading all sites to d9 with the help of this.

I also tried patch #36 wondering if it is okay to add removed functions again core or not.

I upgraded from 8.9.16 to 9.1.9 and the 'Authored by' config for each content type looks correct: default_value_callback: 'Drupal\Entity\Node::getDefaultEntityOwner'. But, when I try to add a new node I still get:

Error: Call to a member function getAccountName() on null in Drupal\node\NodeForm->form() (line 155 of core/modules/node/src/NodeForm.php).

We solved this by using what @Berdir said in #33 but with a small change in that we just replaced it for every occurence. (Obvious but, test it before you use this in your own production site). You need a cache clear after this for it to work.

/**
 * Hot Fix old D8 uid callback in field overrides.
 */
function hook_update_9000() {
  $config_factory = \Drupal::configFactory();
  foreach ($config_factory->listAll('core.base_field_override.') as $config_name) {
    $base_field_override = $config_factory->getEditable($config_name);
    if ($base_field_override->get('field_name') !== 'uid') {
      continue;
    }
    $callback = $base_field_override->get('default_value_callback');
    if (preg_match('~(.*::)getCurrentUserId~', $callback, $matches)) {
      $base_field_override->set('default_value_callback', $matches[1] . 'getDefaultEntityOwner');
      $base_field_override->save(TRUE);
    }
  }
}

@chris-matthews the patch given on https://www.drupal.org/node/3161212 seems to fix that issue.
Me too, I don't have any "getCurrentUserId" in config table, and still have the error without that 3161212 patch.
It's seemly a tiny issue on the author field.

It seems that from at least Drupal 9.2 we need to specify explicitly the default_value_config config for the nodes uid property, instead of an empty string (as suggested in https://www.drupal.org/project/drupal/issues/3153455#comment-13769781), such as:

default_value_callback: '\Drupal\node\Entity\Node::getDefaultEntityOwner'

Else it will throw the "Error: Call to a member function getAccountName() on null" error.

Updated solution from #37:

Resolved by following steps:

There are config files in my "config/sync" folder for every node bundles.

core.base_field_override.node.{bundle}.uid.yml

Issue was on below line, in above config file.

default_value_callback: 'Drupal\node\Entity\Node::getCurrentUserId'

Or even:

default_value_callback: ''

Needs to be changed to:

default_value_callback: '\Drupal\node\Entity\Node::getDefaultEntityOwner'

Then import the config again

Comment #63 works after changed into yml.

#10 works :)

how to apply #10 can somebody please help???

I get these errors when trying to add content

The website encountered an unexpected error. Please try again later.
Error: Call to a member function getAccountName() on null in Drupal\node\NodeForm->form() (line 155 of core/modules/node/src/NodeForm.php).
Drupal\node\NodeForm->form(Array, Object) (Line: 106)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 532)
Drupal\Core\Form\FormBuilder->retrieveForm('node_page_form', Object) (Line: 278)
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: 578)
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: 158)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
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: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 716)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

can be #10 explained in more details please!!!

and why this has not been fixed in core???

I swear to god I would never upgrade to d9 if I knew Drupal migration was so buggy and useless.....everbody said d8 to d9 is so easy and bug free....

@rossidrup Comments like that one are inconsiderate and disrespectful. Comments like that are anti-contributions. Comments like that make everyone feel bad.

This time I urge you to read https://www.drupal.org/dcoc.

Consider the ways you or your organization supports the Drupal project. One way is by donating code. Another way is by supporting the Drupal Association: https://www.drupal.org/association

If you continue to write comments that may violate the code of conduct, a conflict resolution procedure may occur.

Why doesn't this code I get for free do exactly what I want and when I want it???? Also how dare people not respond immediately to my disrespectful comments!!!?! Maybe if I add more punctuation the point will get across!!!!!!!!!!!!!!!!!

This is how you sound, @rossidrup.

As @cilefen mentioned, it does not contribute at all and will probably make people who may have wanted to help you just nope out without giving it a second thought. Perhaps a different approach will yield better results.

honestly, I was just shocked that this happened to my site. I would never upgrade to d9 from d8 if I knew there was a bug.

This bug has been reported like 1 year ago. So I was asking why it has not been patched? Will this bug be squashed in the future?
Because is it safe to change config files like that? Can the site get broken in the future?
That is my concern....
We all love drupal but I was shocked because it was said that d8 to d9 was easy migration without stress....
Drupal is already super complicated, 8 and 9,
7 was easy, the iste was super stable, it never broke and I never came across any bugs....
Just my opinion.....I dont like to manually change any files cause who knows how can that affect the future of the site...will it break after a month or 2 months etc?

Okay, on a hopefully more productive note, because multiple repeating punctuation marks certainly won't lead us anywhere, I'd like to summarize a bit because there are already so many comments here:

* Why does it happen? *
There are some configuration variables which are stored in the Drupal configuration database that point to a specific method. This method exists under a different name in Drupal 9. If you do a new install of Drupal 9 these variables are correctly initialized with their new name. If you do a D8=>D9 upgrade though, these configuration variables are not rewritten automatically and still point to an old method name which doesn't exist anymore, subsequently causing the error.

* How to solve *
There are various methods how to solve this. Basically they all do the same thing: Changing these configuration variables to point to the correct method. No matter which solution you choose, I can highly recommend making a backup of your database, because we are manipulating Drupal's internals here and things can get messy pretty quickly.

Now, if you are on a Linux server and have access to Drush I'd like to shamelessly advertise my script on #45 which should fix this "magically". This is *one* solution. Another one is to do a configuration export as described in #51 to #53 and #10. Manipulating those variables in the exported YML file and then reimport everything back again. There's also an update script in #60 which nobody really reacted on AFAICT, but it looks good to me on a cursory glance. Perhaps we need some additionally info for people on where to actually include that snippet (patch?). Why again, isn't this suitable for integration into Drupal to fix this for good for future upgraders?

Ok I exported the file core.base_field_override.node.page.uid.yml because page is affected, and story and webform...but lets start with page first

I exported the file and changed the code to

---------------------------------------------------------------------------------------------------------------------

uuid: 3c0243ca-891e-47c1-ac60-3cef7595dd20
langcode: en
status: true
dependencies:
config:
- node.type.page
id: node.page.uid
field_name: uid
entity_type: node
bundle: page
label: 'Authored by'
description: 'The username of the content author.'
required: false
translatable: false
default_value: { }
default_value_callback: 'Drupal\node\Entity\Node::getDefaultEntityOwner'
settings:
handler: default
handler_settings: { }
field_type: entity_reference

---------------------------------------------------------------------------------------------------------------------

then I selected single imprort basefield override

and I got this error

---------------------------------------------------------------------------------------------------------------------

The configuration cannot be imported because it failed validation for the following reasons:
Configuration backup_migrate.backup_migrate_destination.private_files depends on the backup_migrate extension that will not be installed after import.
Configuration backup_migrate.backup_migrate_schedule.daily_schedule depends on the backup_migrate extension that will not be installed after import.
Configuration backup_migrate.backup_migrate_settings.backupgeneral depends on the backup_migrate extension that will not be installed after import.
Configuration backup_migrate.backup_migrate_source.default_db depends on the backup_migrate extension that will not be installed after import.
Configuration backup_migrate.backup_migrate_source.entire_site depends on the backup_migrate extension that will not be installed after import.
Configuration backup_migrate.backup_migrate_source.private_files depends on the backup_migrate extension that will not be installed after import.
Configuration backup_migrate.backup_migrate_source.public_files depends on the backup_migrate extension that will not be installed after import.
Configuration block.block.addtoanybuttons depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.animacija depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_addtoanybuttons depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_animacija depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_branding depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_breadcrumbs depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_content depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_footer depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_footer_2 depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_help depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_kajuporabljamozameritev depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_local_actions depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_local_tasks depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_logo depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_main_menu depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_messages depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_newsletterform depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_page_title depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_phone depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_search depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_socialbookmarks depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_socialmediaicons depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_addtoanybuttons depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_animacija depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_branding depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_breadcrumbs depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_content depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_footer depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_footer_2 depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_help depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_kajuporabljamozameritev depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_local_actions depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_local_tasks depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_logo depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_main_menu depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_messages depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_newsletterform depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_page_title depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_phone depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_search depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_socialbookmarks depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_socialmediaicons depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_views_block__content_recent_block_1 depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_zakajizbratinas depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_views_block__content_recent_block_1 depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_zakajizbratinas depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.footer depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.footer_2 depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.kajuporabljamozameritev depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.logo depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.newsletterform depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.phone depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.primaryadminactions depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_branding depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_breadcrumbs depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_content depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_footer depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_help depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_local_actions depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_local_tasks depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_main_menu depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_messages depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_page_title depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_search depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.showcase_lite_branding depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_breadcrumbs depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_content depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_help depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_main_menu depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_messages depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_page_title depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_powered depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_search depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.socialbookmarks depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.socialmediaicons depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.system depends on the garland theme that will not be installed after import.
Configuration block.block.system_1 depends on the blueprint theme that will not be installed after import.
Configuration block.block.system_2 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.system_3 depends on the chameleon theme that will not be installed after import.
Configuration block.block.tabs depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.tools depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.user depends on the garland theme that will not be installed after import.
Configuration block.block.useraccountmenu depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.user_1 depends on the garland theme that will not be installed after import.
Configuration block.block.user_10 depends on the fusion_core theme that will not be installed after import.
Configuration block.block.user_11 depends on the fusion_core theme that will not be installed after import.
Configuration block.block.user_2 depends on the blueprint theme that will not be installed after import.
Configuration block.block.user_3 depends on the blueprint theme that will not be installed after import.
Configuration block.block.user_4 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.user_5 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.user_6 depends on the chameleon theme that will not be installed after import.
Configuration block.block.user_7 depends on the chameleon theme that will not be installed after import.
Configuration block.block.user_8 depends on the fusion_starter theme that will not be installed after import.
Configuration block.block.user_9 depends on the fusion_starter theme that will not be installed after import.
Configuration block.block.views_block__content_recent_block_1 depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.zakajizbratinas depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration bootstrap_barrio.settings depends on the bootstrap_barrio extension that will not be installed after import.
Configuration bootstrap_barrio_subtheme.settings depends on the bootstrap_barrio_subtheme extension that will not be installed after import.
Configuration bootstrap_library.settings depends on the bootstrap_library extension that will not be installed after import.
Configuration core.entity_form_display.node.story.default depends on the Imce File Manager module that will not be installed after import.
Configuration htaccess.settings depends on the htaccess extension that will not be installed after import.
Configuration imce.profile.admin depends on the Imce File Manager module that will not be installed after import.
Configuration imce.profile.member depends on the Imce File Manager module that will not be installed after import.
Configuration imce.settings depends on the Imce File Manager module that will not be installed after import.
Configuration radiestezija_adaptive_theme.settings depends on the radiestezija_adaptive_theme extension that will not be installed after import.
Configuration showcase_lite.settings depends on the showcase_lite extension that will not be installed after import.

I tried again import single and got errors

---------------------------------------------------------------------

The configuration cannot be imported because it failed validation for the following reasons:
Configuration block.block.addtoanybuttons depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.animacija depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_addtoanybuttons depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_animacija depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_branding depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_breadcrumbs depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_content depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_footer depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_footer_2 depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_help depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_kajuporabljamozameritev depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_local_actions depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_local_tasks depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_logo depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_main_menu depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_messages depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_newsletterform depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_page_title depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_phone depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_search depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_socialbookmarks depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_socialmediaicons depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_addtoanybuttons depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_animacija depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_branding depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_breadcrumbs depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_content depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_footer depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_footer_2 depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_help depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_kajuporabljamozameritev depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_local_actions depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_local_tasks depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_logo depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_main_menu depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_messages depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_newsletterform depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_page_title depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_phone depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_search depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_socialbookmarks depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_socialmediaicons depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_views_block__content_recent_block_1 depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_subtheme_zakajizbratinas depends on the bootstrap_barrio_subtheme theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_views_block__content_recent_block_1 depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.bootstrap_barrio_zakajizbratinas depends on the bootstrap_barrio theme that will not be installed after import.
Configuration block.block.footer depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.footer_2 depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.kajuporabljamozameritev depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.logo depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.newsletterform depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.phone depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.primaryadminactions depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_branding depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_breadcrumbs depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_content depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_footer depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_help depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_local_actions depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_local_tasks depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_main_menu depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_messages depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_page_title depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.radiestezija_adaptive_theme_search depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.showcase_lite_branding depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_breadcrumbs depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_content depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_help depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_main_menu depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_messages depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_page_title depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_powered depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.showcase_lite_search depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.socialbookmarks depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.socialmediaicons depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.system depends on the garland theme that will not be installed after import.
Configuration block.block.system_1 depends on the blueprint theme that will not be installed after import.
Configuration block.block.system_2 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.system_3 depends on the chameleon theme that will not be installed after import.
Configuration block.block.tabs depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.tools depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.user depends on the garland theme that will not be installed after import.
Configuration block.block.useraccountmenu depends on the showcase_lite theme that will not be installed after import.
Configuration block.block.user_1 depends on the garland theme that will not be installed after import.
Configuration block.block.user_10 depends on the fusion_core theme that will not be installed after import.
Configuration block.block.user_11 depends on the fusion_core theme that will not be installed after import.
Configuration block.block.user_2 depends on the blueprint theme that will not be installed after import.
Configuration block.block.user_3 depends on the blueprint theme that will not be installed after import.
Configuration block.block.user_4 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.user_5 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.user_6 depends on the chameleon theme that will not be installed after import.
Configuration block.block.user_7 depends on the chameleon theme that will not be installed after import.
Configuration block.block.user_8 depends on the fusion_starter theme that will not be installed after import.
Configuration block.block.user_9 depends on the fusion_starter theme that will not be installed after import.
Configuration block.block.views_block__content_recent_block_1 depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration block.block.zakajizbratinas depends on the radiestezija_adaptive_theme theme that will not be installed after import.
Configuration bootstrap_barrio.settings depends on the bootstrap_barrio extension that will not be installed after import.
Configuration bootstrap_barrio_subtheme.settings depends on the bootstrap_barrio_subtheme extension that will not be installed after import.
Configuration core.entity_form_display.node.story.default depends on the Imce File Manager module that will not be installed after import.
Configuration imce.profile.admin depends on the Imce File Manager module that will not be installed after import.
Configuration imce.profile.member depends on the Imce File Manager module that will not be installed after import.
Configuration imce.settings depends on the Imce File Manager module that will not be installed after import.
Configuration radiestezija_adaptive_theme.settings depends on the radiestezija_adaptive_theme extension that will not be installed after import.
Configuration showcase_lite.settings depends on the showcase_lite extension that will not be installed after import.

---------------------------------------------------------------------------------------------------------------------------------------------

Should I go back to drupal 8 and just stay there indifinately? BEcause clearly this is not working and I dont know what to do....
seems like Drupal became super advanced for regular users.....I have been here from drupal 6 but these errors I dont know.....seems like it is out of my reach....

This is a critical bug, which indicates that we as a community see this as the highest priority.
It's just that no-one has seen it through to completion because there are ways to workaround it.

So folks hit this error, end up here, apply the workaround for their site and move on

Until someone takes ownership and says, yep my site is fixed but I want to help others who come after me, we'll be left in this state

Given we've got only a few months left on d8, it may be this never gets fixed

so I will be left with non working drupal 9 site? Where I cant add content? I am clueless why I get so many errors when import single yaml fiel back.....and then people here are surprised why I shocked at this....

my last resort is to run #45 with gitbash....can somebody tell me how to do it properly?

also shouldnt I just delete all the tables from config in DB?

Again, as others have said, slow down, there is no reason to be so dramatic :) People are already trying to help you, looks like your site is a special case as you seem to have a weird state with your configuration, possibly you deleted modules/themes in the past without properly uninstalling them, so you have conflicts there.

The issue queue isn't the best place to get help with something like this, every time you comment you notify the 44 people that are currently following here. So please don't do that, you'll just annoy a lot of people.

Instead, see https://www.drupal.org/support. You could also try #drupal-support in Slack.

You could try the patch in #16 or #36 as a temporary solution until this issue is properly resolved.

ok I will not ask here again....but I am in a kind of hurry because I cant add CONTENT anymore.... #16 and #36 patch...one is red one is green....I am learning....I dont even know which patch to select and seems like nobody understands this.....

#10 helped me a lot.
single export & import was not too hard.

thanks for the info!

Hi, thanks for patch #36. It solved the problem on my case (creating a new node after updating from D8 to D9).

This expands on #36 to include the same fix for Media entity.

thanks for the patch #36, saved me hours of re-implementation time.

Updated the issue summary and documented the workaround steps mentioned in the comments so that it's easier for others affected by this. Thank you @PhilippJC and others who contributed to finding the root cause and providing the workaround!

Thanks @sleepingmonk! #84 works!

Edit: Quick question. Can I remove the patch out of my composer.json file after I'm done installing it?

This is a reroll of #16. Recent patches are only a bandaid and not a proper fix.

I changed the update function to use an entity query against base field overrides directly, then we can put all the relevant conditions directly into that. I also checked all core entity types that were converted, beside node and media, only workspaces was also affected, the others did not have a default value callback. No test coverage for media/workspaces, maybe this is sufficient?

We could have a helper function for the update, the only thing that varies is the entity type, class and method name. But in theory, other entity types might have different methods or field names, so we can't do this generically.

Also addressed #22:

1. Changed to verify raw config instead, that should be OK?
2. Only fetched once now, so no longer a problem.
3. See above.
4. Not sure, but that would require a post update function that creates new entities, that doesn't really seem like a common use case? AFAIK none of the existing reports mentioned anything about update errors.

PHPCBF voilations fixed. Interdiff attached for 88-89 as well. Please review.

+++ b/core/modules/node/tests/src/Functional/Update/NodeContentTranslationUpdateTest.php
@@ -34,7 +34,7 @@ public function testContentTranslationDefaultValueBaseFieldOverrideUpdates() {
     $entity_field_manager = \Drupal::service('entity_field.manager');
-    //$entity_field_manager->clearCachedFieldDefinitions();
+    // $entity_field_manager->clearCachedFieldDefinitions();
     $fields = $entity_field_manager->getFieldDefinitions('node', 'article');
     $author = $fields['uid'];

ah, I actually forgot to remove that line, instead of adding the space you can just remove it.

Hi All,

There is a peculiar problem to updating imported configs which have remnants of improperly uninstalled themes in the past i.e. way back to early 8.x versions. In such cases, config exports would run clean but the imports of the same would be ugly failures. In my case, remnant blocks from improperly uninstalled theme from the past, newsplus lite theme spoiled the broth. To circumvent this, I followed the following procedure and succeeded.

1. run drush cex from site root
2. run drush cim and collect all the errors in a text file from terminal(copy all to clipboard and paste elsewhere)
3. Search for improperly_removed_theme.settings.yml and delete this from 'sync' folder without any mercy.
4. Search for all *.yml entries which prevented clean import in your text file and delete these *.yml entries from the sync folder without any further thought.
5. run drush cim again and you should see clean import. If not, repeat this process until your import is clean.
6. run drush cex for the last time to collect clean configs without remnants.
7. Make changes to content types *.uid.yml(s) now as detailed in the 'Workaround' at the top of this discussion.
8. run drush cim and the import this time will implement the changes failed before
9. run drush cr and you should be able to create content in drupal 9.x

Hope this helps those struggling at this crucial bottle neck.

Rgds,

Dr. Srinivas

The "workaround" described (very succinctly) at the beginning of this issue worked beautifully in our case. Thank you for that!

1. As we are not able to fix the problem for all contrib and custom modules out there, we need a change record with how to fix the problem for siteowners and module maintainers.

   The how to fix it for siteowners should be understandable for siteowners ranging from expert ones who own multiple sites to not so expert ones that have a single or a couple of sites.

   For module maintainers how to create the post update with a code example.

2. We have the test Drupal\Tests\node\Functional\Update\NodeContentTranslationUpdateTest for the function node_post_update_modify_base_field_author_override(). Only for the functions media_post_update_modify_base_field_author_override() and workspaces_post_update_modify_base_field_author_override() there is no testing. Can we add that.

3. +++ b/core/modules/node/tests/src/Functional/Update/NodeContentTranslationUpdateTest.php
   @@ -0,0 +1,43 @@
   +    // $entity_field_manager->clearCachedFieldDefinitions();
   

   This line can be removed.

1. The problem might be less widespread then you think for other entity types, I hope at least. this did _not_ automatically affect contrib modules. You could only be affected if you switch your entity type(s) to the new owner trait and remove/deprecate the old owner callback. I know that group.module was affected and already did its own update function. So far we haven't seen any reports here that more modules are affected, I think. I do agree with a change record, I just hope it's not quite as important as you fear :)

2. Yeah, I was hoping we don't need to test them all explicitly with a dedicated update function, creating those is quite tedious and we would need new database dumps that have those modules enabled :-/. But I know it technically goes against the rules. But it's a critical bug that causes lot of frustration for people, especially if they have messed up config structure, like #91. Might be easier to argue for that if we have a helper function so we just have a single line with a bunch of arguments that we could carefully manually review?

For #94.2: Ok, lets do the manual review of those 2 functions then. I know that is a lot of work to create testing for it.

Thanks for the step-by-step description how to solve this manually. It worked.

Using the workaround steps got it fixed for me. Thanks

Hi,

Is there a workaround that doesn't involve export and reimporting the config? That's not something I have ever done. And for this simple (yet broken) site Drush isn't installed. Manual edit to the DB?

It would be helpful for site builders like me to have a single use module like the Missing Module Message Fixer for D7: https://www.drupal.org/project/module_missing_message_fixer

Thanks for the feedback.

I successfully tested patch #89 on a test system.

Just for the best strategy on a productive website:
With patch the configuration is cleaned on next export. But is it OK to just leave the patch it in productive code? Or it's currently better to just clean the config and fix prod website with config import?

Config import is something we try to avoid when possible because it can end overriding confguration which was changed productive. So it needs more time to role out.

these are post updates, so they don't have the same problems as patches with regular update functions and number conflicts. So it would be quite safe to deploy the patches to production and run the updates there. After that, you could even remove the patches again so you don't have to carry them around.

To people testing, it would be nice to set this to RTBC, so we can get this in 9.3.

RTBC +1 from me.

@berdir Many thanks for your fast reply and
many thanks to @all who helped fixing this issue.

This was very helpful to reduce the work of some D9 upgrade tasks I need to finish the next days.

I was getting the warning "call_user_func() expects parameter 1 to be a valid callback, class 'Drupal\media\Entity\Media' does not have a method 'getCurrentUserId'". The base field config entities for the uid fields were referencing the default_value_callback of "Drupal\media\Entity\Media::getCurrentUserId". Applying the patch from #89 and running the update script resolved the error, and the default_value_callback in the config entities were changed to the expected value of "Drupal\media\Entity\Media::getDefaultEntityOwner" on the next config export.

Sorry folks this still needs a change record and the fix asked for in #90 and repeated in #93.3 need to be addressed.

I removed that line.

As mentioned, I think this is likely very rare in contrib, I've yet to see a single instance, as not that many have actually converted to this trait *and* removed their old callback. Instead of a new change record, I added something to the existing EntityOwnerTrait change record, which seems like the most likely place people will find it when converting an existing entity type to use that trait. Acceptable?

we just got bit by this one (upgrading from D8 to D9.2.7)

patch 104 fixes it for us. had to rebuild cache, updb

We still need a change record for this, I'm low on cycles at the moment.

This patch is good, but it's not idiotproof.

I added the patch to our build but without exporting the fixed configuration yml, the same bug can be re-introduced simply by re-importing the getCurrentUserId yml config, here's the diff before and after fix, but must also export the config. There should maybe be an optional fix deprecated yml config post upgrade button or drush command, so if you have to re-run this code it should be able to rerun the fix?

diff --git a/config/default/core.base_field_override.media.remote_video.uid.yml b/config/default/core.base_field_override.media.remote_video.uid.yml
index 46fdf710e9..c85df34954 100644
--- a/config/default/core.base_field_override.media.remote_video.uid.yml
+++ b/config/default/core.base_field_override.media.remote_video.uid.yml
@@ -13,7 +13,7 @@ description: 'L''identifiant (ID) de l''auteur.'
 required: false
 translatable: false
 default_value: {  }
-default_value_callback: 'Drupal\media\Entity\Media::getCurrentUserId'
+default_value_callback: 'Drupal\media\Entity\Media::getDefaultEntityOwner'
 settings:
   handler: default
   handler_settings: {  }

so I guess anyone can manually fix this by editing the yml files, search replace getCurrentUserId with getDefaultEntityOwner

So once I updated the configuration yml, imported it, I backed off the patch, (removed it) and the bug is gone.

We are having this issue too. What is the recommended way (easiest) way to fix this? Do you have to each of our sites (test, stage,prod) and fix the config on all environments?

We are having this issue too. What is the recommended way (easiest) way to fix this? Do you have to each of our sites (test, stage,prod) and fix the config on all environments?

We are having this issue too. What is the recommended way (easiest) way to fix this? Do you have to each of our sites (test, stage,prod) and fix the config on all environments?

We are having this issue too. What is the recommended way (easiest) way to fix this? Do you have to each of our sites (test, stage,prod) and fix the config on all environments?

We are having this issue too. What is the recommended way (easiest) way to fix this? Do you have to do this process on each site (test, stage, prod) and go through the steps on each environment?

@emb03

if you are using some sort of *nix derivative you can use this command to fix it
first:
cd /path/to/drupal/config/sync
(wherever that is)

then:
find . -name *.yml -type f -exec sed -i 's/getCurrentUserId/getDefaultEntityOwner/g' {} +

then once you have done that, drush cim -y;

this should fix the 'glitch'

I'm coming up to this
As an enduser only UI user. I'm quite blocked. I cannot append new nodes.
I'm am sure that the problem hast to do with the change of entities created before a certain 8.x.x version
after changing to 9.0.0
I'm up to 9.2.7 but the error still exists.

in my logmessagse
Warning: call_user_func() expects parameter 1 to be a valid callback, class 'Drupal\node\Entity\Node' does not have a method 'getCurrentUserId' in Drupal\Core\Field\FieldConfigBase->getDefaultValue() (Zeile 398 in /home/xxxxxxxxx/www/xxx.xxx.ch/core/lib/Drupal/Core/Field/FieldConfigBase.php)

Error: Call to a member function getAccountName() on null in Drupal\node\NodeForm->form() (Zeile 155 in /home/xxxxxxxxx/www/xxx.xxx.ch/core/modules/node/src/NodeForm.php)

apears.

Will there be a suitable fix in the next Drupal release. Or which of all these proposals has to be done to be safe on a production site.

I just installed Drupal 9.2.8 - but no change to the problem.

Thanks for your answer

To me it's clear the problem occurred, with the change from Drupal 8.X.X to 9, where the

getCurrentUserId -changed to- getDefaultEntityOwner

Our Workaround on the Database was

select * from config where name = "core.base_field_override.node.[entity_machinename].uid";

update config set data = REPLACE(data, 'getCurrentUserId', 'getDefaultEntityOwner') where name = 'core.base_field_override.node.entity_machinename.uid';

and the error was gone.

Hope this helps for people that are willing to make the change directly in the database.

I can confirm the problem for sites created on older 8.x versions.

Special thanks to @lomale@bluewin.ch for the quick db workaround for live sites, which immediately brings content creation functionality back. (After cache reset.)

Actually I checked for entries with SELECT * FROM `config` WHERE data LIKE '%getCurrentUserId%';. In our case all content types were affected.

The provided workaround, specifically the steps in #10 worked for me. Same as #13 - our culprit was indeed the Content Translation module. Thanks so much!

I tried the "shortcut" of using an SQL query similar to #116 . It fixed the problem but it introduced another problem: after that, the configuration export command showed a list of notice messages:

 [notice] Missing required data for configuration: core.base_field_override.node.page.uid
etc...

for every content type affected.

I tried configuration import to fix that but the command failed with a PHP error.
I then re-installed Base Field Override UI and re-set the settings for the UID field for those content types. After that I could do configuration import and export again.

My advice then is to NOT use an SQL query, try first to change the yaml files of the saved configuration and to import it, as explained in #10.
If this fails, use the Base Field Override UI module.
In my case too this may be caused by translation modules, although it's hard to tell as I tried to remove all translation stuff from the site long time ago, so I may be in the situation where I still have some settings.

Thanks #114 did the trick for me.

This query consolidates and streamlines the solutions presented in #116 and #117. It also updates the string serialization length, which the other update queries were missing.

UPDATE config
  SET data = REPLACE(data, 's:41:"Drupal\\node\\Entity\\Node::getCurrentUserId"', 's:46:"Drupal\\node\\Entity\\Node::getDefaultEntityOwner"')
  WHERE data LIKE '%getCurrentUserId%';

> I added the patch to our build but without exporting the fixed configuration yml, the same bug can be re-introduced simply by re-importing the getCurrentUserId

Never, ever re-import config after running updates. Update functions can always change config and you must always export config after an update and keep that. Even running the same update on multiple environments is tricky because new config often has different UUID's, which can result in deleting and re-creating things which is not always without side effects (for example fields can be deleted and content lost).

We've done such layers in the past, but as part of BC in the same version, I don't see us doing that again here.

Also, to other recents comments please, do _not_ manually updated serialized strings in the database by hand, the chance of messing that up is quite high. Export the config, use a bash command or search and replace with any other tool and then import it again. You don't even need to have SSH/drush access. You can export and re-import from a zip file through the UI, or you can do single export/import and change it within the textfield.

Patch #104 worked for me. Thanks

Patch #104 works for me too.

The base config override import/update was not successful, did a try on #122 and it worked! Thanks

I apply the initial workaround :

- drush config:export
- grep -r "getCurrentUserId" *
- Edit the 8 files and replace by "getDefaultEntityOwner"
- drush config:import

I only have 8 content types to edit.
And ALL is OK now !

Thanks !

Sorry, I don't test the patch.

I just tested the patch in #104 and it worked like a charm. Was migrating a web site (that originated in 8.2.6) from 8.9.16 to 9.3.0.
This patch should be committed to core - it's so much cleaner and easier than mucking with exported configs.

Committed and pushed 5c92c24178f to 10.0.x and 45b4d536128 to 9.4.x. Thanks!

The existing CR https://www.drupal.org/node/2998929 already has upgrade path details - I think that that is enough - this issue does not need its own CR.

I have the same issue, it occurs with node type provided from the Webform Node module. Calling the node add form I get:

The website encountered an unexpected error. Please try again later.
Error: Call to a member function getAccountName() on null in Drupal\node\NodeForm->form() (line 155 of core/modules/node/src/NodeForm.php).

Drupal\node\NodeForm->form() (Line: 106)
Drupal\Core\Entity\EntityForm->buildForm()
call_user_func_array() (Line: 531)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 278)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 158)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 80)
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: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 23)
Stack\StackedHttpKernel->handle() (Line: 708)
Drupal\Core\DrupalKernel->handle() (Line: 19)

An the logs say:

Warning: call_user_func() expects parameter 1 to be a valid callback, class 'Drupal\node\Entity\Node' does not have a method 'getCurrentUserId' in Drupal\Core\Field\FieldConfigBase->getDefaultValue() (line 398 of core/lib/Drupal/Core/Field/FieldConfigBase.php).

Drupal\Core\Field\FieldConfigBase->getDefaultValue(Object) (Line: 169)
Drupal\Core\Field\FieldItemList->applyDefaultValue() (Line: 270)
Drupal\Core\Entity\ContentEntityStorageBase->initFieldValues(Object, Array) (Line: 128)
Drupal\Core\Entity\ContentEntityStorageBase->doCreate(Array) (Line: 93)
Drupal\Core\Entity\ContentEntityStorageBase->create(Array) (Line: 370)
Drupal\Core\Entity\EntityForm->getEntityFromRouteMatch(Object, 'node') (Line: 73)
Drupal\Core\Entity\HtmlEntityFormController->getFormObject(Object, 'node.default.default') (Line: 58)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 564)
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: 158)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
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: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I tried to fix it with the patch in #104:

git apply 3153455-104.patch              
3153455-104.patch:134: trailing whitespace.                                                               
{Ϧqv                                                                                                      
3153455-104.patch:171: trailing whitespace.                                                               
E                                                                                                         
 u2Cq-/:l                                                                                                 
                                                                                                          
warning: 2 lines add whitespace errors.

The patch applies but gives me two white space warnings and does not solve the problem for me.

What to do, trying manually update the conf files as described above?

Hi I have been using Drupal since v8.0 before that hand cut LAMPs I work for NFP as a volunteer. I have had this issue of the default_value_callback: 'Drupal\node\Entity\Node::getCurrentUserId' since v9.0 and I can not solve it myself using these methods. I do not have enough experience with Drush, Composer or Drupal on this level. Localhost I have tried to correct this problem and failed. I do not have access on the live production to do any of this. Is there a dummy work around or do I have to rewrite the site? In the past you guys (community) have been great so I do appreciate all of your efforts over the years. Macka

@alexpott: Is there any way to get this into a 9.3.x release? The point is that 9.4.x will be released June 15, 2022, and I think this issue mostly hits people upgrading from Drupal 8. Who hasn't done that yet, will hopefully not wait until June... ;)

So I think it is already very late, but a 9.3.x integration would still help many people, while 9.4.x is nearly a year after it would have helped most. Just from a user perspective, meant constructive.

See the previous comment. "Regular" Drupal users are more and more frustrated and left behind as you need to be a Developer, know patching and git to use Drupal > 7... (not your fault, just as an argument...)

Thank you :)

Re-opening for backport discussion.

We usually avoid putting updates in a patch release, however there's a good argument for committing the post updates that fix a previous update.

I've gone ahead and backported this to 9.3.x.

Thank you very very very much @catch. That's very nice and many Drupal 8 > 9 upgraders will love it (without knowing) :)
THANKS!

This is great! Working for me on a site I upgraded from D8 to D9.

The patch in #104 failed to apply on Drupal 10.2 branch while the patch in #84 still working.