Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When running cron on my site, I got the following error:
The website encountered an unexpected error. Please try again later.
Error: Call to a member function getTargetEntityTypeId() on array in field_purge_batch() (line 82 of core/modules/field/field.purge.inc).
field_purge_batch(50) (Line: 167)
field_cron()
This is due to the fact that in field_purge_batch $deleted_fields_repository->getFieldDefinitions($field_storage_unique_id)
is producing an array of array and not an array of objects that woul fit with the last line in the below extract $field->getTargetEntityTypeId();
function field_purge_batch($batch_size, $field_storage_unique_id = NULL) {
/** @var \Drupal\Core\Field\DeletedFieldsRepositoryInterface $deleted_fields_repository */
$deleted_fields_repository = \Drupal::service('entity_field.deleted_fields_repository');
$fields = $deleted_fields_repository->getFieldDefinitions($field_storage_unique_id);
$info = \Drupal::entityManager()->getDefinitions();
foreach ($fields as $field) {
$entity_type = $field->getTargetEntityTypeId();
....
}
}
Same problem with getFieldStorageDefinitions
occurs few lines after
foreach ($deleted_fields_repository->getFieldStorageDefinitions() as $field_storage) {
if ($field_storage_unique_id && $field_storage->getUniqueStorageIdentifier() != $field_storage_unique_id) {
// If a specific UUID is provided, only purge the corresponding field.
continue;
}
Comment | File | Size | Author |
---|---|---|---|
#20 | 2931436-20.patch | 16.87 KB | amateescu |
#20 | 2931436-20-test-only.patch | 15.26 KB | amateescu |
#18 | interdiff-18.txt | 1.26 KB | amateescu |
#18 | 2931436-18.patch | 1.6 KB | amateescu |
#16 | 2931436.patch | 1.61 KB | amateescu |
Comments
Comment #2
dillix CreditAttribution: dillix commentedI also have this issue after upgrade to 8.5.0-dev
Comment #3
dillix CreditAttribution: dillix commentedComment #4
dillix CreditAttribution: dillix commentedComment #5
BerdirAnd what exactly are those array that you're seeing there? Can you do an var_dump() of that above the failing line? what other modules do you have installed?
Comment #6
BerdirComment #7
dillix CreditAttribution: dillix commentedI started to develop fresh site from Drupal 8.2->8.3->8.4 and all worked fine. But when I upgraded Drupal to 8.5.0-dev cron stopped work. My site have 2 languages: Russian (Default) and English
Here is list of my modules:
Also I have custom entity modules created with drupal console.
And here is var_dump($fields):
I think that that I've got problems with cron after this issue was resolved: #2282119: Make the Entity Field API handle field purging
Comment #8
BerdirYes, that issue is probably related and there seems to be a problem there. We need to either add an update function to convert the existing state entries or convert them into objects when loading them.
But first, please be aware that 8.5.x is not even in alpha yet and 8.5.x -> 8.5.x updates are *not* yet officially supported and it is possible that going from alpha1 to alpha2 or so will *not* work. You should not yet switch to 8.5.x, it is too early. If you just did a test to make sure you're prepared for 8.5.x once it comes out, great.
As a workaround, you can run field_cron() until all deleted fields have been cleaned up. Does that actually work? If not, due to a missing tables or so, then that's where your real problem is.
Comment #9
dillix CreditAttribution: dillix commentedNo, it didn't help. field_cron() fails to run with same error. Is there a way to manually do it? And what should I do if I already moved prod site to 8.5.x-dev? Don't upgrade current 8.5.x-dev till 8.5.x-alpha-2?
Comment #10
BerdirWell, I mean running field_cron() on 8.4.x.
I honestly don't know what you should do, the safest option would be to restore a backup and go back to stable 8.4. With any other option, you're basically on your own to figure things out and at least wait until those bugs are fixed. There are also still some other known regressions in 8.5.x.
Comment #11
dillix CreditAttribution: dillix commentedBerdir, I can't move back to backup because there is new users & forum topics on our site. Can I downgrade site to 8.4 with composer? And will this issue be fixed there or there is another related issue?
Comment #13
dillix CreditAttribution: dillix commentedComment #14
cilefen CreditAttribution: cilefen at Institute for Advanced Study commentedComment #15
xjmComment #16
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThis patch should fix it.
@dillix, can you make a backup copy of your site (files + database), apply this patch, run the updates and then run cron?
Comment #18
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedOops, copy/pasta error :)
Comment #19
plachNice, we also need a test for this.
Comment #20
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThere we go.
Comment #21
BerdirLooks great, nice work.
In regards to the release notes tag, this is only relevant if we don't commit it in time I guess.
Comment #22
plachThis needs to go in 8.6.x first.
Comment #24
dillix CreditAttribution: dillix commentedGreat news! Yes now cron works on D8.5.0-a1.
Comment #27
Gábor HojtsyYay, this was important to get fixed on time! Thanks all! Leaving release notes tag in case we believe we want to mention it still.
Comment #28
tannerg CreditAttribution: tannerg commentedwoot!
Comment #30
Musa.thomaswrong comment
Comment #31
0Sarah0Al CreditAttribution: 0Sarah0Al commentedI am having the exact same error after I updated to 8.5.1 from 8.4.5
Now, I am stuck. can not run update.php
I got this, when I tried to run update.php:
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /drupal/update.php/start?id=311&op=do_nojs&op=do
StatusText: OK
ResponseText: {"status":true,"percentage":"4","message":"Completed 1 of 23.","label":"Updating webform"}Error: Call to a member function getTargetEntityTypeId() on array in field_purge_batch() (line 82 of /media/sf_sandbox/drupal/core/modules/field/field.purge.inc).
Comment #32
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@Sarahphp1, one easy way out of this problem is to run cron a few times before doing the upgrade, which should remove the deleted fields from the database.
You can also do a database query to find out if there are still any fields to purge with this query:
When there are no remaining fields that need to be purged, the
value
column returned by that query should be:a:0:{}
.Comment #33
0Sarah0Al CreditAttribution: 0Sarah0Al commentedThanks for your reply @amateescu
I can't access the UI because of the error. I tried "drush cron" and then I got the same error ..
I am gonna try using code, and will let you know!
Thanks again ,,
Comment #34
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@Sarahphp1, if you are using drush, then there's also a quick fix by running:
After this you should be able to run update.php normally :)
Comment #35
0Sarah0Al CreditAttribution: 0Sarah0Al commented@amateescu
Thank you so so very much ,,
You are a life saver...
That drush command fixed it ,,
Comment #36
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedNo problem, I'm glad I could help :)
Comment #37
bajah1701 CreditAttribution: bajah1701 commentedIs there a way to fix this issue if I don't have access to the UI or Drush? I checked the database and the value column for name="field.storage.deleted" has stuff inside but the other one has a:{0}, which is what needs to be there.