Деактивація плагінів WordPress за допомогою SQL

Якщо ви успадкуєте кодову базу WordPress, незалежно від віку проекту, у вас може бути багато контексту, якого ви не маєте щодо того, чому були прийняті певні рішення або як речі були реалізовані.

Це може включати сервер, інфраструктуру, яка використовується для забезпечення роботи сайту чи програми, а також іншу контекстну інформацію про середовище, у якому він працював.

Цей тип інформації може бути інформацією про сервер, версією PHP, типом бази даних, інформацією, яка фактично зберігається в базі даних, особливо якщо ви виконуєте імпорт бази даних тощо.

В ідеалі все це передають, але це не завжди так. У будь-якому випадку, скажімо, ви намагаєтесь запустити його, а потім, коли ви намагаєтесь запустити програму, вона не тільки не працює, але й відображає білий екран або відображає повідомлення про технічні проблеми під час встановлення.

Хоча я рекомендую переконатися, що ваші налаштування налагодження завжди визначені на вашому локальному комп’ютері, я також рекомендую переконатися, що всі плагіни дезактивовано перед тим, як розпочати встановлення WordPress.

Але статус активації плагіна встановлюється на рівні бази даних, тож що ми можемо зробити? Після встановлення підключіться до бази даних за допомогою вашого улюбленого інтерфейсу бази даних (я фанат TablePlus ), а потім виконайте такі запити:

По-перше, якщо вам цікаво побачити всі наявні активні плагіни, виконайте наступне :

SELECT * FROM wp_options WHERE option_name = 'active_plugins';

Після цього ви можете оновити активні плагіни, по суті, встановивши значення параметра рівним порожньому серіалізованому масиву :

UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';

Цей вторинний запит відповідає за дезактивацію плагіна WordPress, щоб ви могли завантажити WordPress якомога ближче до ванільного. Він має мати ту саму тему та ресурси, а плагіни будуть встановлені, але деактивовані.