3

I'm getting a "Fields pending deletion" error when trying to uninstall the Dynamic Entity Reference module. I also cannot disable the module as the tick is greyed out (unless I'm missing how to disable modules in Drupal 8).

I've run cron and cleared the caches many, many times and have checked /admin/reports/fields but there is no mention there of any fields using this module.

I have found suggestions for Drupal 7 saying to delete the fields from the field_config database table but this table does not exist in Drupal 8. Is there any way to get rid of these zombie fields? They must be stored somewhere!

Please don't tell me to use Drush, I wish I could, believe you me, but I don't have shell access, just sftp and phpmyadmin.

|improve this question
6

It turns out that deleted fields in Drupal 8 are stored in the key_value table.

To find them:

select * from key_value where name = "field.field.deleted" or name = "field.storage.deleted"

The values are stored as a blob, but can be viewed (e.g. in phpmyadmin you can click on it to download, and view in vim or similar). The value does not make much sense to a human, but having gone through the code printing and error-logging various things it was clear to me that these entries were what was holding up the uninstall. I backed up the table and deleted the entries, and then was able to uninstall the module.

The same suggestion is made here in answer to a related issue:

https://drupal.stackexchange.com/a/230199/25792

|improve this answer
  • After 2.5 years i found your solution. Thank you! Minor thing: if you have a prefix, put it in front of key_value, like mysite_key_value. – MatthijsG Mar 23 '19 at 11:46
3

The fields are deleted by cron runs. But only a fixed batch size. You can configure a higher value. If you can't use drush you can do this in UI. Go to the page /admin/config/development/configuration/single/import and add in field.settings a higher batch size:

purge_batch_size: 1000

and run cron again.

enter image description here

|improve this answer
  • Thanks, but there were only ever one or two fields that used the module - if any. I just tried it out and realised it wasn't what I wanted. So I don't see how this could help – naomi Aug 21 '17 at 15:48
  • I did it anyway, and ran cron another few times, but it did not help. – naomi Aug 21 '17 at 16:01
  • I've seen you filed an issue. Yes, I agree with this, installing an alpha version which does changes to the database is not a good idea, at least you should have a snapshot or a backup. – 4k4 Aug 21 '17 at 16:57
  • I must have installed the alpha by mistake, since there are releases for Drupal 8. D'oh – naomi Aug 21 '17 at 17:13
  • In any case I don't think this is really a problem with the specific module. It could happen with any module. I think the problem is that one cannot manipulate things in the database as much in Drupal 8.. One shouldn't have to, in a sense, but things don't always go to plan, and one should have recourse to the DB, I think. I miss Drupal 7. /rant – naomi Aug 22 '17 at 12:08
3

I encountered the same issue with a field which was used in 7000+ entities, while the purge_batch_size: 1000 is not work, increase the number to over 7000 works.

So

purge_batch_size: 10000

works for my instance.

I solved this problem just by execute the following command:

drush php-eval 'field_purge_batch(10000);'

based on

https://drupal.stackexchange.com/a/261669/90460

then run

drush cron

then I can uninstall the module which was prevented.

|improve this answer
0

I ended up having to empty the field_collection_item table in order to uninstall field_collection module on my system. In case anyone else is still having problems after trying the other suggestions here.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.