Réponses:
Les entrées dans field_config
et field_config_instance
auront probablement eu une valeur de 1
dans la deleted
colonne.
Cela signifie qu'ils sont marqués pour suppression, mais ne seront pas réellement supprimés jusqu'à ce que vous exécutiez cron (les données de champ supprimées sont purgées field_cron()
).
en utilisant drush:
$ drush eval "field_purge_batch(500)"
vous devrez peut-être exécuter plusieurs fois, ou augmenter la taille de $ batch_s alors il pourrait toujours y avoir des tables field_deleted et field_deleted_revision, même après avoir exécuté cron
requete
SELECT * FROM `field_config` WHERE `deleted` = 1
SELECT * FROM `field_config_instance` WHERE `deleted` = 1
si vous venez vide, vous pouvez supprimer en toute sécurité ces tables restantes
Au lieu d'exécuter cron pour supprimer les données supprimées, vous pouvez exécuter manuellement field_purge_batch ($ batch_size) .
Pour exécuter manuellement la fonction, vous pouvez soit:
La taille de lot à utiliser varie en fonction de l'environnement et des besoins de votre serveur. J'ai utilisé des valeurs aussi basses que 5 et aussi élevées que 10000.
Pour les utilisateurs de Drupal 8,
J'ai aussi vécu ça, fouillez le code. J'ai trouvé cela pour toutes les raisons pour lesquelles les champs n'étaient pas supprimés après vous, les éléments suivants:
Les champs persistent à ne pas disparaître, ceci en raison d'une logique ici, dans field_purge_batch
// We cannot purge anything if the entity type is unknown (e.g. the
// providing module was uninstalled).
// @todo Revisit after https://www.drupal.org/node/2080823.
if (!isset($info[$entity_type])) {
continue;
}
Les modules qui sont dépendants sont désinstallés. c'est la raison pour laquelle les champs ne sont pas supprimés.
Comment résoudre ça? Il est recommandé de réinstaller le module en premier et de purger ces champs et de le désinstaller à nouveau. Pour savoir quel module vous devez réinstaller:
$fields = entity_load_multiple_by_properties('field_config', array(
'deleted' => TRUE,
'include_deleted' => TRUE,
));
dpm($fields); // this is devel module of var_dump
// check the protected member called "dependencies"
Dans le cas où vous ne souhaitez pas adopter cette approche de réinstallation du module, vous pouvez également supprimer immédiatement, je ne sais pas quel est le comportement mais il devrait faire le travail.
Sauvegarde d'abord !!!
Oui, ne soyez pas paresseux, cela vous sauvera le cul, si quelque chose se passe mal.
$fields = entity_load_multiple_by_properties('field_config', array(
'deleted' => TRUE,
'include_deleted' => TRUE,
));
foreach ($fields as $field) {
$field->delete();
}
// Retrieve all deleted field storages. Any that have no fields can be purged.
$deleted_storages = \Drupal::state()->get('field.storage.deleted') ? : array();
foreach ($deleted_storages as $field_storage) {
$field_storage = new FieldStorageConfig($field_storage);
$fields = entity_load_multiple_by_properties('field_config', array('field_storage_uuid' => $field_storage->uuid(), 'include_deleted' => TRUE));
if (empty($fields)) {
field_purge_field_storage($field_storage);
}
}
Faites le cron pour la dernière fois. J'espère que cela résoudra le problème :)
Je n'arrive pas à trouver de solution. J'ai donc fini par les supprimer manuellement de ces deux tables.