Как да използвате класическия редактор в WordPress: Инсталация, конфигурация и кога всъщност има смисъл

Класическият редактор на WordPress Classic Editor е базиран на TinyMCE WYSIWYG редактор за съдържание, който предхожда системата с блокове Gutenberg, въведена в WordPress 5.0. Той представя единно, линейно платно за редактиране — визуално подобно на Microsoft Word — където текст, медия и HTML съществуват съвместно в едно непрекъснато поле, а не в отделни, наслагващи се блокове. За потребители, които трябва да го инсталират днес, краткият отговор е: инсталирайте официалния плъгин Classic Editor plugin от хранилището за плъгини на WordPress, активирайте го и конфигурирайте редактора по подразбиране в Settings > Writing.

Този двуизреченчен отговор обхваща основния въпрос. Останалата част от това ръководство обхваща архитектурните разлики между двата редактора, легитимните технически причини за избор на единия пред другия, крайни случаи при конфигурацията и сценариите, при които принудителното използване на Classic Editor всъщност създава повече проблеми, отколкото решава.

Classic Editor срещу Gutenberg Block Editor: Техническо сравнение

Преди да докоснете каквито и да е настройки, струва си да разберете между какво всъщност превключвате. Решението не е чисто козметично.

Най-оперативно значимата разлика е съхранението на съдържание. Classic Editor записва чист HTML. Gutenberg обвива всяка единица съдържание в HTML коментарни анотации, които действат като разделители на блокове. Ако някога мигрирате съдържание между системи — към headless CMS, генератор на статични сайтове или платформа, различна от WordPress — изходът на Classic Editor е много по-лесен за парсване и пренасяне. Граматиката на блоковете на Gutenberg е собствена за парсера на WordPress.

Защо разработчиците и собствениците на сайтове все още избират Classic Editor

Съвместимост с наследени плъгини и теми

Много търговски плъгини — особено по-стари конструктори на форми, разширения за електронна търговия и плъгини за персонализирани типове публикации — регистрират meta box-ове, които инжектират полета директно в екрана за редактиране на публикации. В Gutenberg тези meta box-ове са преместени в сгъваем страничен панел, рендиран вътре в iframe shim за съвместимост. Този shim не винаги се държи правилно: възникват JavaScript конфликти, условната логика се нарушава и някои UI рамки за meta box (например jQuery UI диалози) не успяват да се инициализират правилно в контекста на вложения документ.

Ако вашият сайт разчита на плъгини, използващи add_meta_box() с комплексни UI-та, зависими от JavaScript, Classic Editor елиминира целия този клас проблеми.

Ограничения на REST API

Редакторът на Gutenberg прави непрекъснати фонови заявки към WordPress REST API — за извличане на блокови шаблони, автоматично запазване на чернови, извличане на статуса на заключване на публикации и валидиране на потребителски права. В защитени сървърни среди, където REST API е умишлено ограничен (чрез add_filter('rest_authentication_errors', ...) или правила на ниво сървър, блокиращи /wp-json/), Gutenberg ще се зареди частично или изобщо няма да се зареди. Classic Editor няма такава зависимост и ще функционира нормално при тези ограничения.

Контрол на редактора за Multisite и базиран на роли

При инсталации на WordPress Multisite, мрежовите администратори понякога трябва да наложат последователно изживяване при редактиране в целия сайт — особено когато са включени нетехнически редактори. Плъгинът Classic Editor поддържа опция Settings > Writing за забрана на превключване на редактора за отделни потребители, заключвайки всички потребители в Classic Editor независимо от техните индивидуални предпочитания. Gutenberg не предлага еквивалентен механизъм за налагане на ниво мрежа без персонализиран код.

Скорост на работния процес за текстово-интензивно съдържание

За издатели, произвеждащи големи обеми текстово съдържание — новинарски статии, документация, правни документи — моделът с едно платно на Classic Editor е наистина по-бърз. Няма нужда да вмъквате нов блок, да избирате тип блок или да навигирате между панели с настройки на блокове. Натискате Enter и продължавате да пишете. За редактори, които работят с клавиатурата и използват преки пътища в раздела HTML, това има значение.

Как да инсталирате плъгина Classic Editor

Classic Editor не е включен в WordPress core. Той се поддържа като официален плъгин от екипа на WordPress Contributors и е достъпен от хранилището за плъгини на WordPress.org.

Метод 1: Инсталиране чрез таблото за управление на WordPress

1. Влезте в административния панел на WordPress (/wp-admin).
2. Навигирайте до Plugins > Add New Plugin.
3. В полето за търсене въведете Classic Editor.
4. Намерете плъгина, създаден от WordPress Contributors — проверете автора, тъй като има имитиращи плъгини с подобни имена.
5. Кликнете Install Now, след това Activate.

Метод 2: Инсталиране чрез WP-CLI

Ако управлявате WordPress от командния ред — което е стандартна практика при всяка среда за VPS Хостинг — WP-CLI е значително по-бърз от UI на таблото:

wp plugin install classic-editor --activate

За инсталиране в цялата мрежа при инсталация на Multisite:

wp plugin install classic-editor --activate-network

Метод 3: Ръчно качване

Изтеглете ZIP файла на плъгина от wordpress.org/plugins/classic-editor, след което го качете чрез Plugins > Add New Plugin > Upload Plugin, или го разархивирайте директно на вашия сървър:

cd /var/www/html/wp-content/plugins/
unzip classic-editor.zip

След разархивиране, активирайте чрез WP-CLI или таблото за управление.

Конфигуриране на настройките на Classic Editor

След активиране, плъгинът предоставя две опции за конфигурация в Settings > Writing.

Редактор по подразбиране за всички потребители

Първата опция задава стандартната настройка за целия сайт. Можете да избирате между Classic Editor и Block Editor. Задаването на Classic Editor означава, че всяка нова публикация и страница се отваря в TinyMCE по подразбиране.

Разрешаване на потребителите да превключват редактори

Втората опция контролира дали отделните потребители могат да заменят стандартната настройка на сайта за всяка публикация поотделно. Когато е активирана, задържането на курсора върху публикация в списъка Posts > All Posts разкрива два линка за действие: Edit (отваря се в стандартния за сайта редактор) и Edit (Classic Editor) или Edit (Block Editor) в зависимост от текущата настройка по подразбиране.

Препоръчителна конфигурация за повечето наследени сайтове:

• Редактор по подразбиране: Classic Editor
• Разрешаване на потребителите да превключват: Не

Това предотвратява случайното отваряне на съдържание в Gutenberg от редакторите и непреднамереното инжектиране на коментарни анотации за граматика на блокове в публикации, създадени в Classic Editor — смесица, която може да причини аномалии при рендиране в някои теми.

Използване на интерфейса на Classic Editor

Разделът Visual (WYSIWYG режим)

Разделът Visual рендира вашето съдържание чрез базирания на iframe преглед на TinyMCE. Лентата с инструменти предоставя:

• Форматиране на текст: Bold (Ctrl+B), Italic (Ctrl+I), Strikethrough, Underline
• Стилове на параграфи: Heading 1 до Heading 6, Preformatted, Blockquote
• Списъци: Наредени и ненаредени, с контроли за отстъп/намаляване на отстъп
• Връзки: Вмъкване/редактиране на хипервръзки с атрибути за цел и заглавие
• Вмъкване на медия: Отваря медийната библиотека на WordPress за изображения, видео, аудио и документи
• Поставяне от Word: Премахва собствения HTML маркъп на Microsoft Word при поставяне
• Режим на писане без разсейване: Превключване на цял екран, което скрива целия административен UI

Лентата с инструменти има два реда. Ако виждате само един ред, кликнете бутона Toolbar Toggle (последната икона в първия ред), за да разкриете втория ред, който включва селектора за стил на параграф, цвят на текста, карта на символите и отмяна/повторение.

Разделът Text (режим на чист HTML)

Разделът Text излага чистия HTML, съхранен в post_content. Това не е пълноценен редактор на код — липсва му оцветяване на синтаксиса и номериране на редовете — но ви дава директен достъп до маркъпа. Полезни сценарии:

• Вмъкване на вградени <iframe>, които TinyMCE би изрязал или екранирал
• Добавяне на персонализирани HTML атрибути, които UI на раздела Visual не излага
• Отстраняване на проблеми с рендирането, причинени от автоматичното почистване на тагове от TinyMCE

Критично поведение за разбиране: TinyMCE извършва HTML санитизация, когато превключите от раздела Text обратно към Visual. Той ще затвори незатворени тагове, ще изрязва определени елементи (като <script> в някои конфигурации) и ще нормализира белите пространства. Ако пишете чист HTML в раздела Text, винаги проверявайте дали оцелява при обратно превключване към Visual преди публикуване.

Meta box-овете Excerpt, Custom Fields и Discussion

Под основното платно на редактора, Classic Editor показва пълния набор от нативни meta box-ове на WordPress в оригиналното им оформление:

• Excerpt: Обобщение в обикновен текст, използвано от теми и SEO плъгини за мета описания
• Custom Fields: Двойки ключ-стойност, съхранени в wp_postmeta — достъпни директно без превключване към страничен панел
• Discussion: Настройки за коментари и trackback за всяка публикация
• Slug: Редактируемо поле за URL slug (също в кутията Publish)
• Author: Преназначаване на авторство на публикация без навигиране другаде

Тези meta box-ове са винаги видими и на пълна ширина в Classic Editor. В Gutenberg те са или скрити в страничната лента, или рендирани в iframe за съвместимост — значима разлика в UX за работни процеси, разчитащи силно на персонализирани полета.

Превключване между редактори за всяка публикация

Ако сте активирали опцията „Allow users to switch”, превключването на редактора за всяка публикация работи по следния начин:

От списъка с публикации:

1. Отидете на Posts > All Posts.
2. Задръжте курсора върху заглавието на публикацията.
3. Кликнете Edit (Classic Editor) или Edit (Block Editor) според нуждите.

От вътрешността на редактора:

В Gutenberg, линк с надпис Switch to Classic Editor се появява в менюто с три точки (горе вдясно). В Classic Editor, линк с надпис Switch to Block Editor се появява близо до горната част на екрана.

Предупреждение: Превключването на публикация, създадена в Gutenberg, към Classic Editor — и след това запазването й — ще запази коментарните анотации за граматика на блокове в чистия HTML. Тези коментари са безвредни за рендирането на предния край, но ще се появят като буквален текст в раздела Text на Classic Editor, което може да бъде объркващо. Превключването обратно към Gutenberg ще ги парсне правилно. Обратният сценарий (съдържание от Classic Editor, отворено в Gutenberg) е чист, тъй като Gutenberg автоматично обвива неразпознатия HTML в Classic блок.

Деактивиране на Classic Editor без плъгина

Ако искате да принудите Gutenberg и да предотвратите използването на Classic Editor — или ако искате да деактивирате Gutenberg без инсталиране на плъгин — WordPress предоставя filter hook:

// In functions.php or a site-specific plugin — disable Gutenberg for all post types
add_filter( 'use_block_editor_for_post', '__return_false' );

Това постига същия ефект като плъгина Classic Editor за редактиране на публикации, но не засяга Site Editor (Full Site Editing). За пълно деактивиране на Gutenberg, включително FSE:

add_filter( 'use_block_editor_for_post', '__return_false' );
add_filter( 'use_widgets_block_editor', '__return_false' );
remove_theme_support( 'widgets-block-editor' );

Този подход е за предпочитане в среди, където инсталирането на допълнителни плъгини е ограничено по политика, или където искате логиката за деактивиране да бъде контролирана от версии във вашата тема или плъгин, а не зависима от състоянието на активиране на плъгин на трета страна.

Classic Editor и среди за WordPress хостинг

Самият плъгин Classic Editor е лек и не налага значими изисквания от страна на сървъра. Въпреки това, по-широкият контекст на вашата хостинг среда влияе на изживяването при редактиране по начини, заслужаващи внимание.

При планове за споделен хостинг, административният панел на WordPress може да се усеща бавен, защото изпълнението на PHP и заявките към базата данни се конкурират с другите наематели на същия сървър. Classic Editor е измеримо по-лек от Gutenberg в този контекст — по-малко REST API извиквания, без React overhead при рендиране и по-малък JavaScript товар означават по-бързо зареждане на страниците в администрацията. Ако сте на план за Споделен Уеб Хостинг и намирате блоковия редактор за бавен, Classic Editor е практична оптимизация.

На VPS с cPanel, имате пълен контрол върху лимитите на PHP паметта, конфигурацията на OPcache и кеширането на MySQL заявки. В тази среда и двата редактора работят добре, и изборът се превръща в чисто предпочитание за работния процес, а не в необходимост за производителност.

За WordPress инсталации с голям трафик на Dedicated Сървъри, изборът на редактор практически няма влияние върху производителността на предния край — интерфейсът за редактиране се зарежда само от удостоверени административни потребители, а публикуваният HTML изход е това, което има значение за скоростта на страницата.

Чести проблеми и крайни случаи

TinyMCE изрязва валиден HTML: Конфигурацията valid_elements и extended_valid_elements на TinyMCE контролира кои HTML тагове и атрибути са разрешени във Visual редактора. По подразбиране той изрязва тагове като <article>, <section>, <figure> (в по-стари конфигурации) и всякакви персонализирани data атрибути. Ако вашето съдържание изисква тях, трябва да разширите разрешените елементи на TinyMCE чрез филтъра tiny_mce_before_init:

add_filter( 'tiny_mce_before_init', function( $init ) {
    $init['extended_valid_elements'] = 'span[*],div[*],section[*],article[*]';
    return $init;
} );

Конфликти при автоматично запазване: Classic Editor използва по-старата JavaScript функция wp_autosave(), която изпраща POST заявки към wp-admin/post.php с action=autosave. Ако вашият сървър има агресивно ограничаване на скоростта или WAF правило, блокиращо повтарящи се POST заявки към wp-admin, автоматичните запазвания ще се провалят безшумно. Наблюдавайте логовете за грешки на сървъра, ако настъпи загуба на съдържание.

Classic Editor и теми за Full Site Editing (FSE): Ако активната ви тема е FSE тема (такава, която декларира "blockTemplates": true в theme.json), Classic Editor ще работи за съдържанието на публикации и страници, но Site Editor (/wp-admin/site-editor.php) е изцяло базиран на Gutenberg и не се влияе от плъгина Classic Editor. Не можете да използвате Classic Editor за редактиране на шаблони на FSE теми.

Поведение при деактивиране на плъгина: Деактивирането на плъгина Classic Editor не конвертира вашето съдържание. Публикациите, създадени в Classic Editor, остават като чист HTML. Публикациите, създадени в Gutenberg, запазват граматиката на блоковете си. Gutenberg ще парсне правилно и двете. Деактивирането на плъгина не носи риск от загуба на данни.

Матрица за решения: Кой редактор да използвате?

Използвайте Classic Editor ако:

• Вашият сайт използва плъгини с комплексни UI-та за meta box, които се нарушават в слоя за съвместимост на Gutenberg
• Вашият сървър ограничава WordPress REST API
• Мигрирате съдържание към платформа, различна от WordPress, и се нуждаете от чист, преносим HTML
• Вашият редакторски екип е голям, нетехнически и обучен на работния процес на Classic Editor
• Изпълнявате WordPress в среда за споделен хостинг с ограничени ресурси

Използвайте Gutenberg ако:

• Изграждате нови сайтове без зависимости от наследени плъгини
• Вашата тема е базирана на блокове или съвместима с FSE
• Нуждаете се от многократно използваеми блокове, блокови шаблони или комплексни многоколонни оформления без конструктор на страници
• Изграждате персонализирани блокове с register_block_type() за клиентски проекти
• Искате да използвате Site Editor за пълна персонализация на темата

Използвайте и двата (с активирано превключване за всеки потребител) ако:

• Имате смесен екип, в който някои редактори предпочитат Classic, а други предпочитат Gutenberg
• Намирате се в преходен период на мигриране на наследен сайт към базирана на блокове архитектура
• Различните типове публикации на вашия сайт имат различни изисквания за сложност

Практически технически контролен списък

Преди да превключите производствения си сайт към Classic Editor, проверете следното:

• ] Потвърдете, че версията на плъгина Classic Editor е актуална (проверете [wordpress.org/plugins/classic-editor за последното издание)
• [ ] Тествайте UI-тата на meta box-овете на всички активни плъгини в Classic Editor в staging среда преди внедряване в производство
• [ ] Прегледайте вашите филтри tiny_mce_before_init, ако имате персонализирани TinyMCE конфигурации, които може да конфликтуват с настройките по подразбиране на плъгина
• [ ] Вземете решение относно политиката за „разрешаване на превключване” и я документирайте за вашия редакторски екип
• [ ] Ако използвате WP-CLI, потвърдете, че плъгинът е активиран с wp plugin list --status=active
• [ ] Проверете дали вашата тема не разчита на специфични за Gutenberg стилове на блокове (CSS класове wp-block-*) за рендиране на предния край
• [ ] Архивирайте базата данни преди да правите промени в превключването на редактора на сайт със съществуващо Gutenberg съдържание
• [ ] Ако сте в мрежа Multisite, решете дали да активирате в цялата мрежа или за всеки сайт поотделно и наложете чрез Settings > Writing на ниво мрежа

Съчетайте вашата WordPress настройка с правилно защитен домейн, като се уверите, че вашите SSL Сертификати са валидни и се подновяват автоматично — административният панел на WordPress предава бисквитки за удостоверяване, които трябва да бъдат защитени от HTTPS независимо от това кой редактор използвате.

За екипи, управляващи редакторски работни процеси, включващи имейл известия, комуникации с автори или интеграции с бюлетини, специализирана настройка на Имейл Хостинг гарантира, че транзакционните имейли на WordPress (нулиране на пароли, известия за коментари, промени в статуса на публикации) се доставят надеждно, а не се маршрутизират през стандартния sendmail на споделен сървър.

ЧЗВ

Влияе ли плъгинът Classic Editor на рендирането на предния край или производителността на сайта?

Не. Плъгинът Classic Editor само модифицира интерфейса за редактиране от страна на администрацията. Той няма никакво влияние върху начина, по който WordPress рендира страниците за посетителите. Производителността на предния край се определя от вашата тема, слоя за кеширане и конфигурацията на сървъра — не от това кой редактор е използван за написване на съдържанието.

Ще повреди ли превключването от Gutenberg към Classic Editor съществуващото ми базирано на блокове съдържание?

Не. Gutenberg съхранява анотациите на блоковете като HTML коментари вътре в post_content. Classic Editor ще покаже този чист HTML в раздела Text и ще се опита да го рендира в раздела Visual. Съдържанието не се изтрива или поврежда. Ако запазите публикация от Gutenberg в Classic Editor без да я редактирате, анотациите на блоковете се запазват. Ако редактирате и запазите, TinyMCE може да нормализира някои бели пространства, но няма да изрязва коментарните анотации.

Мога ли да използвам Classic Editor за някои типове публикации и Gutenberg за други?

Да, но не чрез UI на настройките на плъгина Classic Editor. Трябва да използвате филтъра use_block_editor_for_post_type в код:

add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
    if ( $post_type === 'product' ) {
        return false; // Use Classic Editor for WooCommerce products
    }
    return $use_block_editor;
}, 10, 2 );

Ще бъде ли плъгинът Classic Editor поддържан постоянно?

WordPress.org се е ангажирал да поддържа плъгина Classic Editor с актуализации за сигурност и съвместимост поне до 2024 г., и той продължава да получава актуализации след този ангажимент. Въпреки това, той не получава нови функции — намира се в режим на поддръжка. За дългосрочни нови проекти, Gutenberg е стратегическата посока на WordPress core.

Работи ли Classic Editor с WooCommerce?

Да. Редакторът на продукти на WooCommerce исторически е изграден върху meta box-овете на Classic Editor. Последните версии на WooCommerce (8.x+) въведоха нов редактор на продукти, изграден върху блокове, но наследената форма за редактиране на продукти, базирана на Classic Editor, остава налична и е стандартна за повечето инсталации. Плъгинът Classic Editor не пречи на екраните за редактиране на продукти на WooCommerce.