After upgrading from Drupal 8.9 to Drupal 9.0 I get the two following error/warning messages when trying to create new content using some (not all) of my content types, among them the native “page”-type:
Error message:
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).
Warning message:
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 397 of core/lib/Drupal/Core/Field/FieldConfigBase.php).
Does anyone know what causes this?
Root cause
- This issue may affect sites that were originally built with an earlier Drupal 8 version than 8.6.x and which were upgraded to Drupal 9.
- The reason is that
Node::getCurrentUserId
method was deprecated in 8.6.x and was removed in 9.0.0. The replacing method in Drupal 9 isNode::getDefaultEntityOwner
- Configuration entities that are still having a reference to the removed method will trigger this bug.
- Note that other entity types than Nodes (e.g. Media) can also be affected.
Workaround
The following workaround steps are for Node entities but should be quite well applicable for other Entity types as well.
1. You want to identify those Node content types that are affected by this issue.
2. You can either a) do this by trial and error i.e. try to create new nodes for each content type on your site and see which content types are affected OR b) you can export your configuration and search for 'getCurrentUserId' to get a list of configuration files that are affected. The following steps use approach b) using Drush command line tool on Linux.
3. Export all configuration from command line using drush config:export
4. Navigate to your config/sync directory.
5. Identify the affected configuration files using
grep -R "getCurrentUserId" *
. The files matching this search will be like core.base_field_override.node.CONTENT_TYPE.uid.yml
, for example core.base_field_override.node.page.uid.yml
. As mentioned above, other entity types than nodes might also be affected.
6. For each affected configuration file, first take a backup of the configuration file. Then, use your favorite text editor and replace default_value_callback: 'Drupal\node\Entity\Node::getCurrentUserId'
with default_value_callback: 'Drupal\node\Entity\Node::getDefaultEntityOwner'
in each affected configuration file. If your site is affected by some other Entity type than Node, you will need to modify this find / replace according to your entity type.
7. Once you have edited all affected configuration you can double check with grep -R "getCurrentUserId" *
that you did not miss any affected configuration file.
8. Once you have fixed all affected configuration files, you will need to import these configurations from your config/sync directory back to your database. This can be done with drush config:import
9. After you have imported the configurations, you will need to rebuild your caches. This can be done with drush cache:rebuild
10. Test and verify that you are now able to create new nodes of the affected content types.
Comment | File | Size | Author |
---|---|---|---|
#104 | 3153455-104-interdiff.txt | 876 bytes | Berdir |
#104 | 3153455-104.patch | 59.39 KB | Berdir |
#89 | interdiff-3153455-88_89.txt | 1.39 KB | Gauravvvv |
#89 | 3153455-89.patch | 59.44 KB | Gauravvvv |
Comments
Comment #2
cilefen CreditAttribution: cilefen commentedComment #3
larowlanDoes your status report show any outdated field definitions?
Comment #4
PhilippJC CreditAttribution: PhilippJC commentedThe status report doesn't but you're right the Referrer mentions a different Error: Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found.Comment #5
PhilippJC CreditAttribution: PhilippJC commentedUsing a backup without the field missing does show the same problem, so that seems to be unrelated. Here are the full logs:
Comment #6
larowlanCan 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
Comment #7
PhilippJC CreditAttribution: PhilippJC commentedI have not found any such command as none of the modules seem to use it.
Uninstalling all non-core modules didn't solve the Error either.
Viewing and edititing existent content of the affected content-types works fine.
I appreciate your help and effort, thank you very much.
Comment #8
larowlanOk, can you search for the wider term
Node::getCurrentUserId
in your code-base?Thanks
Comment #9
PhilippJC CreditAttribution: PhilippJC commentedI only found the term in NodeOwnerTest.php in my Drupal 8.9 version. It doesn't exist anymore in Drupal 9.
The only modules using “getCurrentUserId” without the Node bit are Paragraphs and Redirect. Uninstalling those (even before updating) hasn't helped though.
Comment #10
PhilippJC CreditAttribution: PhilippJC commentedI have solved this on my website for now:
Looking through my database I found the value “GetCurrentUserId” in the config table in core.base_field_override.node.page.uid in the context of default_value_callback (in both 8.9 and 9).
I then did a single export of Base field override of the field “Authored by” of the affected content type and replaced
default_value_callback: 'Drupal\node\Entity\Node::getCurrentUserId'
with
default_value_callback: 'Drupal\node\Entity\Node::getDefaultEntityOwner'
and imported the new configuration.
Comment #11
larowlanThen 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?
Comment #12
xjmComment #13
PhilippJC CreditAttribution: PhilippJC commentedIt looks like the base field override was created by the content translation module.
Comment #14
larowlanWorking 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
Comment #15
catchComment #16
larowlanHoping 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!
Comment #18
larowlanNew title taken from a similar report that I closed as a duplicate of this.
Comment #19
jibranCan you please explain the change is DB dump?
Comment #20
larowlanThe DB dump was created as follows:
Comment #21
jibranThanks, for adding the steps.
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?
Comment #22
alexpottWe're lucky this works. I'm not sure that we could continue to trust this.
We should load a fresh object from the container as the container will be rebuilt during the update.
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.
Comment #23
larowlanBut 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
Comment #24
alexpottRe #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.
Comment #25
huzookaThis happens with other entity types as well: media entities, paragraphs, and so on. Basically, all entities
arecan 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
).Comment #26
huzookaSetting back to NW because of #25.
Comment #27
BerdirMore 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.
Comment #28
huzooka#27 is right, @Berdir, thanks for pointing this out.
Comment #29
catch#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.
Comment #30
alexpott@catch I'm not sure I agree with
I think a post update for a site could easily have a node creation or something like that thatcould result in this error - no?
Comment #31
catch@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).
Comment #32
alexpott@catch good point. I guess post update is okay here.
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?
Comment #33
BerdirEntityOwnerTrait 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?
Comment #34
BerdirThat 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.
Comment #35
Eduardo Morales AlbertiI added a patch to resolve it based on other contrib modules.
Comment #36
Eduardo Morales AlbertiSorry, wrong Class
Comment #37
mukeshkanzariya CreditAttribution: mukeshkanzariya as a volunteer commentedI 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 thendrush cr
and Problem Solved. Hope this may help someone!
Comment #38
geomax CreditAttribution: geomax commentedI'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.
Every site that pre-dates 8.6.x and use content translation, core media will hit this issue.
Hope the above helps.
Comment #39
BerdirThe 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.
Comment #40
geomax CreditAttribution: geomax commentedI appreciate your note—Thanks!
In our case it was fine.
../config/sync/example/
only had
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.
Comment #41
al.iv CreditAttribution: al.iv commentedi also have these errors after update to 9.0.3 from 8.9.
is there any progress on fixing this bug?
Comment #42
Skymen CreditAttribution: Skymen commentedAlso 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.
Comment #43
BerdirThis needs work to handle other entity types and address the other reviews.
Comment #44
droodpal CreditAttribution: droodpal as a volunteer commentedHi, 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.
Comment #45
rgpublicUpdated 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. ;-)
(!)
Comment #46
droodpal CreditAttribution: droodpal as a volunteer commentedCan'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.
Comment #48
devad CreditAttribution: devad as a volunteer commentedI 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.
Comment #49
droodpal CreditAttribution: droodpal as a volunteer commented@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!
Comment #50
devad CreditAttribution: devad as a volunteer commentedDeleting my post since @Berdir answer below is the correct one.
Comment #51
BerdirYou 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.
Comment #52
droodpal CreditAttribution: droodpal as a volunteer commented@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.
Comment #53
devad CreditAttribution: devad as a volunteer commented@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.
Comment #54
droodpal CreditAttribution: droodpal as a volunteer commented@devad that worked, it only had 2 uid.yml file types, thank you all.
Comment #55
developer-rocha CreditAttribution: developer-rocha commented#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
Comment #56
dsp1 CreditAttribution: dsp1 commentedThank 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.
Comment #57
Steven McCoy CreditAttribution: Steven McCoy commentedIn 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'
Comment #58
abhaypai CreditAttribution: abhaypai as a volunteer commentedIn 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.
Comment #59
Chris Matthews CreditAttribution: Chris Matthews commentedI 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).
Comment #60
kriboogh CreditAttribution: kriboogh at Calibrate commentedWe 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.
Comment #61
cutesquirrel CreditAttribution: cutesquirrel commented@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.
Comment #62
b2f CreditAttribution: b2f at Axess Open Web Services commentedIt 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.
Comment #63
b2f CreditAttribution: b2f at Axess Open Web Services commentedUpdated 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 #64
Nicolas S. CreditAttribution: Nicolas S. commentedComment #63 works after changed into yml.
Comment #65
niral098#10 works :)
Comment #66
rossidrup CreditAttribution: rossidrup commentedhow to apply #10 can somebody please help???
Comment #67
rossidrup CreditAttribution: rossidrup commentedI 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)
Comment #68
rossidrup CreditAttribution: rossidrup commentedcan be #10 explained in more details please!!!
Comment #69
rossidrup CreditAttribution: rossidrup commentedand why this has not been fixed in core???
Comment #70
rossidrup CreditAttribution: rossidrup commentedI 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....
Comment #71
cilefen CreditAttribution: cilefen commented@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.
Comment #72
kristiaanvandeneyndeThis 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.
Comment #73
rossidrup CreditAttribution: rossidrup commentedhonestly, 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?
Comment #74
rgpublicOkay, 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?
Comment #75
rossidrup CreditAttribution: rossidrup commentedOk 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.
Comment #76
rossidrup CreditAttribution: rossidrup commentedI 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....
Comment #77
larowlanThis 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
Comment #78
rossidrup CreditAttribution: rossidrup commentedso 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....
Comment #79
rossidrup CreditAttribution: rossidrup commentedmy 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?
Comment #80
BerdirAgain, 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.
Comment #81
rossidrup CreditAttribution: rossidrup commentedok 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.....
Comment #82
Yazzbe CreditAttribution: Yazzbe as a volunteer and commented#10 helped me a lot.
single export & import was not too hard.
thanks for the info!
Comment #83
FiNeX CreditAttribution: FiNeX as a volunteer commentedHi, thanks for patch #36. It solved the problem on my case (creating a new node after updating from D8 to D9).
Comment #84
sleepingmonkThis expands on #36 to include the same fix for Media entity.
Comment #85
danrodthanks for the patch #36, saved me hours of re-implementation time.
Comment #86
masipila CreditAttribution: masipila as a volunteer commentedUpdated 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!
Comment #87
Sseto CreditAttribution: Sseto commentedThanks @sleepingmonk! #84 works!
Edit: Quick question. Can I remove the patch out of my composer.json file after I'm done installing it?
Comment #88
BerdirThis 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.
Comment #89
Gauravvvv CreditAttribution: Gauravvvv at OpenSense Labs for Drupal India Association commentedPHPCBF voilations fixed. Interdiff attached for 88-89 as well. Please review.
Comment #90
Berdirah, I actually forgot to remove that line, instead of adding the space you can just remove it.
Comment #91
mandavya CreditAttribution: mandavya commentedHi 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
Comment #92
TMWagner CreditAttribution: TMWagner at Tableau commentedThe "workaround" described (very succinctly) at the beginning of this issue worked beautifully in our case. Thank you for that!
Comment #93
daffie CreditAttribution: daffie commentedThe 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.
Drupal\Tests\node\Functional\Update\NodeContentTranslationUpdateTest
for the functionnode_post_update_modify_base_field_author_override()
. Only for the functionsmedia_post_update_modify_base_field_author_override()
andworkspaces_post_update_modify_base_field_author_override()
there is no testing. Can we add that.This line can be removed.
Comment #94
Berdir1. 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?
Comment #95
daffie CreditAttribution: daffie commentedFor #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.
Comment #96
ifrikThanks for the step-by-step description how to solve this manually. It worked.
Comment #97
gwvoigtUsing the workaround steps got it fixed for me. Thanks
Comment #98
mlecha CreditAttribution: mlecha commentedHi,
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.
Comment #99
C-LogemannI 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.
Comment #100
Berdirthese 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.
Comment #101
C-LogemannRTBC +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.
Comment #102
evilehk CreditAttribution: evilehk at Breakthrough Technologies, LLC for Breakthrough Technologies, LLC commentedI 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.
Comment #103
quietone CreditAttribution: quietone as a volunteer commentedSorry folks this still needs a change record and the fix asked for in #90 and repeated in #93.3 need to be addressed.
Comment #104
BerdirI 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?
Comment #105
joseph.olstadwe just got bit by this one (upgrading from D8 to D9.2.7)
Comment #106
joseph.olstadpatch 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.
Comment #107
joseph.olstadThis 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?
so I guess anyone can manually fix this by editing the yml files, search replace getCurrentUserId with getDefaultEntityOwner
Comment #108
joseph.olstadSo once I updated the configuration yml, imported it, I backed off the patch, (removed it) and the bug is gone.
Comment #109
emb03 CreditAttribution: emb03 commentedWe 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?
Comment #110
emb03 CreditAttribution: emb03 commentedWe 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?
Comment #111
emb03 CreditAttribution: emb03 commentedWe 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?
Comment #112
emb03 CreditAttribution: emb03 commentedWe 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?
Comment #113
emb03 CreditAttribution: emb03 commentedWe 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?
Comment #114
joseph.olstad@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'
Comment #115
lomale@bluewin.ch CreditAttribution: lomale@bluewin.ch as a volunteer and commentedI'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
Comment #116
lomale@bluewin.ch CreditAttribution: lomale@bluewin.ch as a volunteer and commentedTo 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.
Comment #117
indigoxela CreditAttribution: indigoxela commentedI 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.Comment #118
gallegosj CreditAttribution: gallegosj as a volunteer commentedThe provided workaround, specifically the steps in #10 worked for me. Same as #13 - our culprit was indeed the Content Translation module. Thanks so much!
Comment #120
pbattino CreditAttribution: pbattino commentedI 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:
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.
Comment #121
AporieThanks #114 did the trick for me.
Comment #122
amanire CreditAttribution: amanire at Environmental Defense Fund commentedThis 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.
Comment #123
Berdir> 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.
Comment #124
hoporr CreditAttribution: hoporr commentedPatch #104 worked for me. Thanks
Comment #125
joaopauloscho CreditAttribution: joaopauloscho at Zoocha commentedPatch #104 works for me too.
Comment #126
tsotoodeh CreditAttribution: tsotoodeh commentedThe base config override import/update was not successful, did a try on #122 and it worked! Thanks
Comment #127
Didier Misson CreditAttribution: Didier Misson as a volunteer commentedI 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.
Comment #128
marassa CreditAttribution: marassa commentedI 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.
Comment #129
alexpottCommitted and pushed 5c92c24178f to 10.0.x and 45b4d536128 to 9.4.x. Thanks!
Comment #132
alexpottThe 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.
Comment #133
gunwald CreditAttribution: gunwald commentedI have the same issue, it occurs with node type provided from the Webform Node module. Calling the node add form I get:
An the logs say:
I tried to fix it with the patch in #104:
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?
Comment #134
erikmckitrick CreditAttribution: erikmckitrick as a volunteer commentedHi 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
Comment #135
Anybody@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 :)
Comment #136
catchRe-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.
Comment #138
catchI've gone ahead and backported this to 9.3.x.
Comment #139
AnybodyThank you very very very much @catch. That's very nice and many Drupal 8 > 9 upgraders will love it (without knowing) :)
THANKS!
Comment #140
joelsteidl CreditAttribution: joelsteidl at Aten Design Group commentedThis is great! Working for me on a site I upgraded from D8 to D9.
Comment #142
alfattal CreditAttribution: alfattal as a volunteer commentedThe patch in #104 failed to apply on Drupal 10.2 branch while the patch in #84 still working.