Відповіді:
Записи в field_configі field_config_instance, ймовірно, мали б значення 1у deletedстовпці.
Це означає, що вони позначені для видалення, але насправді їх не буде видалено, доки ви не запустите cron (дані видалених полів не введені field_cron()).
за допомогою барабану:
$ drush eval "field_purge_batch(500)"вам, можливо, доведеться запустити кілька разів або збільшити розмір $ batch_size, то, можливо, все ще існують таблиці field_deleted і field_deleted_revision, навіть після запуску cron
запит
SELECT * FROM `field_config` WHERE `deleted` = 1
SELECT * FROM `field_config_instance` WHERE `deleted` = 1якщо ви з'явилися порожніми, можете безпечно видалити ці залишені таблиці
Як альтернатива запуску cron для видалення видалених даних, ви можете вручну запустити field_purge_batch ($ batch_size) .
Щоб вручну запустити функцію, ви можете:
Використовуваний $ batch_size буде змінюватися в залежності від середовища та потреб вашого сервера. Я використовував значення від 5 до 10000.
Для цих користувачів Drupal 8,
Я це також пережив, викопайте код. Я знайшов, що це все, чому поля, які ви не видаляли після вас,:
Поля зберігається, щоб вони не відходили, це пояснюється частиною логіки тут, у 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;
}Модулі, які є залежними, видаляються. саме тому поля не видаляються.
Як це вирішити? Рекомендується підходити до перевстановлення модуля спочатку та очищення цих полів та видалення назад. Щоб дізнатися, який модуль потрібно перевстановити:
$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"У випадку, якщо ви не хочете перейти на такий підхід перевстановити модуль, ви можете також відразу ж видалити, я не впевнений, що таке поведінка, але він повинен зробити роботу.
Резервне копіювання перше !!!
Так, не лінуйся, це врятує твою дупу, якщо щось піде не так.
$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);
}
}Робіть крон востаннє. Сподіваюся, це вирішить проблему :)
Не можу знайти рішення. Тому я видалив їх із цих двох таблиць вручну.
Якщо ви кілька разів запустите drupal cron, drupal видалить таблиці полів та його вміст. Ви можете легко виконати наступні кроки для запуску декількох кронів, але ці кроки можуть заблокувати вашу систему, веб-сайти чи хостинг, але ви можете це зробити, якщо керуєте своєю системою.
Напишіть наступну команду bash:
поки правда; зробіть curl [помістіть сюди скопійоване посилання, видаливши дужки]; зроблено;
Натисніть Enter. Команда буде виконуватися необмежену кількість разів.
Як я вже коментував, це не найкраще рішення, але це просто, воно працює, ви нічого поганого не зробите, тому що ви запускаєте лише drupal cron, тож ви можете зламати що завгодно з неправильним PHP-кодом. В іншому випадку ви можете наситити сервер, систему, хостинг чи будь-що інше у вашій мережі, тому що ці кроки виконуються багато разів за крон, і це змушує споживання веб-ресурсів, але якщо у вас є контроль над ресурсами, їх не дуже багато таблиці чи рядки для чищення, або ви знаєте, що це безпечно зробити для вас, ви можете це зробити.
І я знаю, це не найкраще рішення. Але це працює. Можливо, це просте і найкраще рішення для вашої ситуації.