WordPress 7.0: какво се чупи, какво си струва да включите и кога да обновите
WordPress 7.0 „Armstrong“ излезе на 20 май 2026 г. и това е първото издание от години, за което честният съвет към собственик на бизнес не е „обновете веднага“. Не защото е лошо, а защото променя административните екрани, които плъгините разширяват от петнадесет години — и не всички плъгини са настигнали.
Три месеца по-късно картината е по-ясна, отколкото при пускането. По-долу е какво точно се промени, какво се чупи и при кого, какво си струва да се включи и как да решите кога да обновите точно вашия сайт.
Какво се промени, по тежест
В издание 7.0 доминират три промени и едно вдигнато изискване.
- DataViews заменя класическите таблици със списъци в „Публикации“, „Страници“ и „Медия“. Това са екрани на React, които филтрират и сортират без презареждане. Персонализираните типове съдържание не са засегнати в 7.0 и още ползват старите таблици — затова много сайтове виждат промяната на едно място и не я виждат на друго.
- Основа за ИИ в ядрото: AI Client, Abilities API и конектори с поддръжка на модели на OpenAI, Anthropic и Google, плюс MCP адаптер. Ядрото доставя инфраструктура, а не функция, която можете да посочите; полезните приложения ще дойдат от плъгини, построени върху нея.
- Подобрения в редактора и дизайна, включително нови блокове и преработена командна палитра.
- Минималната версия на PHP вече е 7.4, с край на поддръжката за 7.2 и 7.3 и препоръка 8.3 за всичко, което ползва ИИ функциите.
Едно забележимо премахване: съвместното редактиране в реално време беше извадено от изданието в началото на май заради проблеми с едновременния достъп и стабилността. Ако някакъв план е стъпвал на него, този план има нужда от нова дата.
Какво наистина се чупи
Почти всички съобщения за счупвания водят до една промяна: административните екрани, които плъгините разширяваха, вече не съществуват във формата, която тези плъгини очакват.
| Какво имахте | Какво става в 7.0 | Колко е видимо |
|---|---|---|
| Персонализирани колони в списъка с публикации | Често липсват; старите куки за колони не са напълно интегрирани с DataViews | Веднага, за редакторите |
| Персонализирани групови действия | Може да изчезнат от новите екрани | Когато някой опита да ги ползва |
| Промени в бързото редактиране | Често се губят | При обичайна работа |
| Настройки от „Опции на екрана“ | Не важат за новия интерфейс | Дребно, козметично |
| Административен CSS за стария код | Визуални счупвания; DOM-ът е различен | Веднага и изглежда счупено |
| Плъгини-теми за администрацията | Частично стилизиране, смесен вид | Веднага |
| Сайтове на PHP 7.2 или 7.3 | Не могат да обновят, докато хостът не ги премести | Блокиращо |
Обърнете внимание кого засяга: удря по редакционни екипи и всеки, чийто процес зависи от персонализирани колони — наличност, статус, име на клиент в списъка. Публичните страници не са засегнати. Сайт визитка с няколко плъгина няма да усети почти нищо; сайт, в който администрацията е работен инструмент, ще усети в първия ден.
Разграничението, което определя риска ви: 7.0 променя административния интерфейс, не публичната част. Ако стойността на сайта е в това, което виждат посетителите, обновяването е нискорисково и може да мине след обичайно тестване. Ако стойността включва хора, работещи всеки ден в администрацията — магазин, редакция, система за записване — третирайте това като промяна на работния процес, изискваща репетиция, а не като рутинна кръпка.
Струва ли си да включите ИИ функциите?
В повечето случаи още не, и обосновката е по-важна от отговора.
Доставена е инфраструктура: стандартен начин плъгин да извика модел, да опише възможности и да се свърже с доставчик. Това е наистина ценно, защото заменя дузина несъвместими интеграции в отделни плъгини с един механизъм. Но самото ядро не прави с това нищо, което бизнесът би забелязал, а свързването на доставчик означава да добавите към сайта API ключ, разходна експозиция и въпрос за потока на данни.
Три въпроса преди да включите каквото и да е. Кой доставчик получава съдържанието и приемливо ли е това за конкретния материал? Кой държи API ключа и какъв е лимитът на разходи? И какво точно прави плъгинът, който го ползва, което човек вече не е правил по-добре? Това са същите управленски въпроси, чието място е в писана политика, а не в екран с настройки — изложени са в материала за правилата за ИИ, които си струва да напишете сега.
Защитимата позиция за повечето бизнеси през 2026 г.: обновете до 7.0 заради самото издание, оставете ИИ конекторите неконфигурирани и се върнете към тях, когато конкретен плъгин решава конкретен ваш проблем.
Какво означава това за сайтове на конструктори
Отделна рискова категория са сайтовете, сглобени с тежки конструктори на страници. Тук положението е парадоксално: самият редактор на конструктора в повечето случаи не е засегнат, защото той и без това замества редактора на WordPress и живее в собствен интерфейс. Чупи се периферията: добавките към списъците с публикации, панелите с настройки, персонализираните екрани, които конструкторът или неговите разширения слагат в администрацията.
Практическото следствие е, че за проверка подлежи не конструкторът, а наборът му от разширения, който обикновено никой не е описвал. Точно там живеят дребните плъгини от външни автори, купени някога за петнадесет долара, и точно те първи остават без обновявания. Това е продължение на същата цена на притежаване, описана в материала за конструкторите вътре в WordPress и сметката, която идва по-късно: всяка голяма версия на ядрото превръща натрупаните разширения в списък с решения.
Кога да обновите
Четири ситуации, четири различни отговора.
- Прости сайтове с масови плъгини. Обновете след тест върху копие. Към август 2026 г. големите плъгини са пуснали съвместими версии; рискът е съсредоточен в дребните или изоставените.
- Магазини и сайтове с интензивна работа в администрацията. Репетирайте на staging с хората, които реално работят там, а не само с разработчик. Заложете половин ден за преобучение, защото екраните изглеждат различно дори там, където нищо не е счупено.
- Сайтове с персонални плъгини или собствени разширения на администрацията. Проверете кода за старите куки на таблиците и за административен CSS, преди да пипате продукция. Това е разработка с реална оценка, а не бутон за обновяване.
- Сайтове на PHP 7.2 или 7.3. Първо оправете хостинга. Да сте на неподдържана версия на PHP и без това беше по-големият проблем, по причините от материала за избора на хостинг и къде да не се пести.
Във всеки случай последователността е същата, която прави обновяванията безинтересни: копие на staging, обновяване, преминаване през реалните работни сценарии, после повторение в продукция в прозорец, когато някой е на разположение — дисциплината, описана в материала за обновяване на жив сайт без счупвания.
Одитът преди обновяване, конкретно
Един час проверки предотвратява повечето неприятни изходи.
Направете списък на всички плъгини с датата на последно обновяване и вижте дали авторът е заявил съвместимост със 7.0. Всичко, недокоснато от година, е кандидат за замяна, а не въпрос на съвместимост. Това е и моментът да забележите, че изоставените плъгини са основният път, по който сайтовете биват компрометирани, както е показано в материала за това колко бързо се експлоатират уязвимости в плъгини.
После отворете екраните „Публикации“ и „Медия“ и запишете всяка промяна, която виждате: допълнителни колони, филтри, групови действия, оцветени редове. Този списък е тестовият ви сценарий след обновяването.
Проверете версията на PHP в „Инструменти → Здраве на сайта“ и уточнете с хоста какво включва преминаването. Направете резервно копие, което поне веднъж наистина сте възстановявали, и го пазете, докато обновяването не преживее седмица нормална работа.
Накрая решете кой е на разположение. Обновяване, направено в петък следобед от човек, който после тръгва за уикенда, е най-надеждният начин малък проблем да стане дълъг.
Какво подсказва това издание за следващите две години
Три следствия си струва да се планират, защото променят цената на притежаване на сайт, а не само как изглежда той този месец.
Преустройството на администрацията не е завършено. Персонализираните типове съдържание запазиха класическите екрани в 7.0 и това е отсрочка, не политика. Всичко, което строите сега с разширяване на административни списъци, трябва да е писано така, че да може да се премести, а плъгин, купен заради административната си интеграция, е плъгин, към който ще се върнете.
Екосистемата от плъгини ще оредее. Адаптацията към DataViews е реална работа, а за безплатен плъгин с няколко хиляди инсталации и без доход за поддръжника тази работа няма да се случи. Очаквайте вълна от тихи изоставяния през следващата година. Това е аргумент да проверите зависимостите сега, докато заместник може да се избере спокойно.
PHP ще продължи да се движи. Прагът се вдигна до 7.4 след години застой, а препоръката вече е 8.3. Хостинг, който не може да предложи актуална версия при поискване, ще блокира и следващото ви обновяване — а това е въпрос на доставчик, не на техника.
Ако още не можете да обновите
Оставането на 6.x за известно време е легитимно решение, стига да е решение, а не пропуск.
Продължавайте да получавате обновявания по сигурността: предишният клон още ги получава за някакъв период, но този период е краен и не зависи от вас. Определете дата за преглед вместо безсрочно отлагане и използвайте времето, за да замените плъгина, който ви блокира, а не да чакате поправка от някого, който е спрял да отговаря.
Не изключвайте автоматичните дребни обновявания, докато чакате. Дребните издания са издания по сигурността; вие отлагате голямата версия, а смесването на двете е начинът сайтовете да изостанат с две години.
Накратко
- WordPress 7.0 „Armstrong“ излезе на 20 май 2026 г., вдигайки минималния PHP до 7.4 и препоръчвайки 8.3 за ИИ функциите.
- DataViews заменя таблиците в „Публикации“, „Страници“ и „Медия“. Персонализираните типове съдържание запазват класическите екрани в това издание.
- Счупванията са административни, не публични. Жертви са персонализираните колони, груповите действия, промените в бързото редактиране и административният CSS; посетителите не виждат нищо.
- Съвместното редактиране в реално време беше премахнато от изданието през май 2026 г. заради проблеми със стабилността.
- ИИ функциите са инфраструктура, не продукт. Обновете заради самото издание и оставете конекторите неконфигурирани, докато конкретен плъгин не ги оправдае.
- Одит преди обновяване: дати на последно обновяване на плъгините, промените, видими на екрана с публикации, версията на PHP, възстановено резервно копие и посочен човек на разположение.
