Як сказати, чи плагін сумісний із багатоповерховим сайтом?

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

Я оновив п'ять різних встановлень WordPress з 4.1.3 до 4.2.

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

На кожному з веб-сайтів я використовую такі плагіни:

• Акісмет;
• Google Analytics від Yoast;
• Google Adsense;
• Google XML Sitemap та
• Jetpack від WordPress.com.

Для того, щоб впорядкувати подальше адміністрування, я розглядаю можливість об'єднання всіх п’яти встановлень в одну багатомісну установку.

Поки що мені досить важко знайти остаточні відповіді щодо сумісності кожного з цих плагінів із багатосайтовою установкою на веб-сайтах плагіна.

Чи потрібна сторінка плагіна для пошуку цього?

Чи є центральне місце, де можна знайти цю інформацію?

Існує два типи сумісності на різних сайтах:

1. Пасивна сумісність: робити нічого багатоцільового конкретного, просто працює, нічого не порушуючи.
2. Активна сумісність: зміна або розширення конкретної поведінки на багатосайтових сайтах.

Я здогадуюсь, що вам подобається 1. Дивіться мої слайди з WordCamp Prague 2015 для другої частини.

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

На жаль, більшість плагінів не перевіряють їх тип активації, тому вони дозволяють зробити неправильну активацію.

пов'язані з проблемами UX, такими як покажчики адміністратора або спеціальні сторінки "Про", про які вам доведеться клацати, коли-небудь підключаються в несумісних плагінах. WAP SEO Yoast - один із прикладів . Я думаю, це скоро буде виправлено у цьому плагіні. :)

Інші питання залежать від того, що ви робите з цим багатосайтовим сайтом. Якщо ви будуєте багатомовний веб-сайт, де кожен сайт написаний однією мовою, а сайти пов’язані між собою, ви хочете синхронізувати публікації під час написання вмісту. Це означає, що ви зателефонуєте switch_to_blog()на гачок save_postі збережіть також пов’язані пости. save_postбуде викликано кілька разів протягом одного запиту зараз. Багато плагінів не знають про таку ситуацію, тому вони просто перезаписують метаінформацію для підключених постів, думаючи, що вони все ще на першому дописі.

Слідкуйте за плагінами, які мають справу з постмета і не мають чека на зразок цього:

if ( is_multisite() && ms_is_switched() )
    return FALSE;

Ці плагіни не сумісні.

Подібні, хоч і складніші, такі проблеми, коли плагіни торкаються метаполя користувачів або переписують правила.

Деякі плагіни намагаються записати вміст у файли, не включаючи ідентифікатор сайту у ім'я файлу. Вони, ймовірно, також зламані.

Як сказав Том: Створіть тестову установку, запустіть кожен випадок використання, який ви можете собі уявити. Ви не можете довіряти сторінці плагіна, і, як правило, недостатньо інформації.

Якщо плагін не говорить про сумісність, єдиний надійний спосіб дізнатися це - створити локальну багатосайтову установку та протестувати її.

Іноді є ознаки, на які можна шукати, але це завжди симптом поганого коду, наприклад, назви таблиць бази даних жорсткого кодування, а не використання префікса від $wpdb, і в такому випадку я б рекомендував вимкнути плагін, навіть якщо ви не використовуєте мультисайт