Как да създадете тестова среда за WordPress: вградена в хостинга или с плъгин

Натискате Update на някой плъгин, презареждате началната страница и виждате празен бял екран. А в същото време клиенти се опитват да платят поръчките си.

Тестовата среда (staging) за WordPress предпазва точно от такива ситуации. Това е затворено копие на публичния ви сайт, в което тествате промени, от ъпдейти на плъгини до нови теми и собствен код, преди посетителите да ги видят. Ако нещо се счупи, то се чупи в копието.

Можете да създадете тестова среда по два начина: с инструмента, който хостингът ви е вградил в сървъра, или с плъгин, който клонира сайта от самия WordPress. И двата начина работят. Подхождат обаче за различни сайтове, а разликата личи най-много, когато дойде време да публикувате промените.

Какво е тестова среда за WordPress?

Тестовата среда за WordPress е точно копие на публичния ви сайт, с неговите файлове, база данни, теми и плъгини. То работи на отделен адрес, който посетителите не виждат. Разработчиците наричат публичния сайт продуктова среда (production), а копието тестова среда (staging).

Работният процес е прост.

Клонирате публичния сайт в тестовата среда, правите промените, тествате ги и публикувате одобрената версия обратно на публичния сайт.

Използвайте тестова среда за всичко, което може да свали сайта или да промени поведението му:

• Ъпдейти на ядрото на WordPress, плъгините и темите
• Обновяване до нова версия на PHP
• Нови плъгини, визуални редактори (page builders) и промени в дизайна
• Собствен код, кодови фрагменти (snippets) и редакции във functions.php
• Промени в количката и плащането в WooCommerce

Вградена тестова среда или плъгин: каква е разликата?

Основната разлика е къде се върши работата.

Вградената в хостинга тестова среда работи на ниво сървър. Контролният панел копира файловете и базата данни в отделна среда, обикновено на поддомейн. Плъгинът за тестова среда работи в самия WordPress и с помощта на PHP копира сайта в подпапка или на облачните сървъри на своя разработчик.

Тази разлика определя всичко останало. Ето как се сравняват двата подхода по най-важните показатели:

Плъгините все пак имат своето място.

Работят на всеки хостинг, лесно се пренасят, а някои създават временно тестово копие за секунди. Ако обаче хостингът ви включва тестова среда, тя обикновено е по-бързият и по-лекият вариант, защото в публичния сайт не работи нищо допълнително.

Как да създадете тестова среда за WordPress с WordPress Manager в SPanel

На управляван VPS в NS1 тестовата среда е вградена. WordPress Manager в SPanel, контролния панел, който разработваме и използваме, показва всички WordPress инсталации в акаунта ви и дава на всяка от тях действието Stage. До него са клонирането, автоматичните ъпдейти, WP-CLI и Security Lock. Не е нужно да инсталирате плъгин.

Процесът минава през пет стъпки и всички те се случват в един и същ панел.

Стъпка 1: Направете бекъп на публичния сайт

Самата тестова среда е безопасна, но публикуването замества публичния сайт. Започнете със свежа точка за възстановяване (restore point).

Планираните бекъпи в SPanel се правят на всеки час, ден, седмица и месец, така че обикновено вече имате скорошно копие. За чиста контролна точка направете ръчен бекъп на файловете и базите данни точно преди да клонирате сайта. След това заключете тази точка за възстановяване и ротацията на бекъпите няма да я изтрие.

Стъпка 2: Създайте тестовото копие

Създаването на копието отнема няколко клика:

1. Логнете се в SPanel. Отворете User Interface за акаунта, в който е сайтът ви.
2. Отворете WordPress Manager. Ще го намерите в раздела Software. Там са изброени всички ваши WordPress инсталации.
3. Изберете Stage. Кликнете Actions до сайта, който искате да копирате, и изберете Stage.
4. Изберете поддомейн. Запазете предложения поддомейн, например wordpress.primer.bg, или създайте нов, например staging.primer.bg.
5. Кликнете Stage. WordPress Manager създава копие на сайта ви на този поддомейн.

Стъпка 3: Тествайте промените в тестовата среда

Тестовата среда работи на същия сървър като публичния сайт, затова се държи като него. Отворете таблото ѝ директно от WordPress Manager и минете през промените: пуснете ъпдейтите, активирайте новия плъгин или сменете темата.

Три инструмента в SPanel правят тестването по-задълбочено:

• Версия на PHP за всеки поддомейн. SPanel задава версията на PHP поотделно за всяка основна директория (document root). Така можете да обновите само тестовия поддомейн до по-нова версия на PHP и да проверите съвместимостта, докато публичният сайт остава непроменен.
• Вградени тестове за скорост. WordPress Manager пуска тестове с Lighthouse и можете да сравните времето за зареждане преди и след промяната. Това е бърза проверка преди по-сериозна оптимизация на производителността на WordPress (на английски).
• WP-CLI и търсене и замяна. Изпълнявайте команди на WordPress или обновявайте записи в базата данни директно от панела, без да добавяте помощни плъгини в копието.

Съвет: ако Security Lock е включен за инсталацията, която тествате, WordPress не може да инсталира нови плъгини или теми. Изключете го, докато тествате, и след това го включете отново.

Стъпка 4: Публикувайте промените на публичния сайт

Отворете менюто Actions на тестовата инсталация и изберете Push Live. Тестваната версия замества публичния сайт без ръчно копиране на файлове, експорт на бази данни или търсене и замяна на URL адреси.

Има обаче един детайл, който лесно се пропуска.

Публикуването на тестовата база данни презаписва публичната, независимо от инструмента. Ако публичният сайт е получил нови поръчки в WooCommerce, коментари или регистрации, след като сте създали тестовото копие, тези записи липсват в копието. При натоварените магазини обновете копието точно преди последния кръг тестове и публикувайте в часовете с малко трафик.

Стъпка 5: Проверете публичния сайт

Заредете публичния домейн и проверете страниците, които носят приходи или запитвания: началната страница, формите, количката и страницата за плащане. Изчистете кеша на сървъра, на плъгините и на мрежата за доставка на съдържание (Content Delivery Network или CDN). Така посетителите ще виждат новата версия, а не кешираното копие на старата.

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

Тестването намалява риска от неуспешен ъпдейт, но не го премахва. Затова WordPress Manager работи върху няколко слоя на SPanel, които пазят публичния сайт, ако публикуването се обърка:

• Възстановяване на отделни файлове и бази данни. Възстановете само файла или базата данни, които публикуването е счупило, или възстановете базата под ново име, за да я сравните с публичната версия.
• Защита в реално време. SShield, системата за сигурност с изкуствен интелект, която разработваме, следи трафика на целия сървър. Така забравено тестово копие не се превръща в лесна мишена.

Как да създадете тестова среда за WordPress с плъгин

Ако хостингът ви не предлага тестова среда, плъгин може да запълни празнината. Процесът е почти еднакъв при повечето инструменти:

1. Инсталирайте и активирайте плъгина от таблото на WordPress.
2. Създайте ново тестово копие и изберете кои папки и таблици от базата данни да се копират.
3. Изчакайте клонирането да приключи и се логнете в тестовото копие.
4. Тествайте промените.
5. Публикувайте промените на публичния сайт, ако планът ви включва тази функция.

Няколко популярни WordPress плъгина за тестова среда покриват повечето нужди:

• WP Staging. Клонира сайта в подпапка на същия сървър. Публикуването на промените обратно на публичния сайт е част от Pro версията.
• Duplicator. Основно плъгин за миграция. Пакетира сайта, за да можете да изградите копие навсякъде, включително на тестов поддомейн.
• WPvivid. Съчетава бекъпи с функция за тестова среда, която създава копието в поддиректория на сървъра.
• InstaWP Connect. Създава тестовото копие на облачните сървъри на InstaWP. Така хостингът ви не се натоварва, но копие на данните ви остава при трета страна.

Имайте предвид и компромисите.

Някои плъгини клонират сайта при същите лимити за време и памет на PHP като публичния сайт, така че при големи бази данни копирането може да спре по средата. Копието в подпапка освен това споделя сървърните ресурси и правилата за кеширане на публичния сайт, а това може да направи резултатите от тестовете по-малко надеждни. И всеки нов плъгин е още нещо, което трябва да обновявате и защитавате.

Кой метод за тестова среда в WordPress да изберете?

За повечето собственици на сайтове всичко опира до един въпрос: включва ли хостингът ви тестова среда?

• Хостингът включва тестова среда. Използвайте нея. Тя е по-бърза, не натоварва публичния сайт и обикновено позволява публикуване на промените с един клик.
• Без тестова среда, малък сайт. Безплатен плъгин е разумно начало за блог или представителен сайт.
• Без тестова среда, голям сайт или натоварен магазин. Плъгинът е временно решение. Бавното клониране, общите ресурси и платените функции за синхронизация се натрупват, а уеб хостинг с вградена тестова среда обикновено ви спестява повече време, отколкото заобикалянето им.

Добри практики за тестовата среда в WordPress

Какъвто и метод да изберете, тези навици правят тестването полезно и безопасно:

• Пазете копието извън резултатите от търсене. Защитете директорията ѝ с парола (инструментите за сигурност в SPanel позволяват това) или блокирайте индексирането, за да не я приемат търсачките за дублирано съдържание.
• Обновявайте копието преди големи промени. Копие отпреди месец не отразява днешното съдържание, плъгини и поръчки.
• Тествайте по една промяна. Ако обновите пет плъгина наведнъж и сайтът се счупи, няма да разберете кой е виновен.
• Публикувайте в спокойните часове. При малко трафик по-малко нови записи са изложени на риск и по-малко посетители ще усетят, ако се наложи да върнете старата версия.
• Изтривайте тестовите копия, които не ви трябват. Забравените тестови сайтове работят със стари плъгини и подкопават всичко останало, което правите за сигурността на WordPress.

В заключение

Всеки WordPress сайт има нужда от безопасно място, където нещата могат да се чупят. Плъгинът може да ви даде такова място, но тестовата среда, вградена в сървъра, го прави с по-малко натоварване и с директен път обратно към публичния сайт.

С WordPress Manager на управляван VPS в NS1 този път е един клик, бекъпите са включени, а SShield постоянно следи сървъра за подозрителна активност.

Често задавани въпроси за тестовата среда в WordPress

В: Влияе ли тестовата среда на SEO?

О: Не, ако е затворена. Търсачките могат да индексират само копие, до което имат достъп, затова паролата или настройката noindex не му позволяват да се конкурира с публичните ви страници.

В: Каква е разликата между тестова и продукционна среда?

О: Продукционната среда е публичният сайт, който посетителите използват, а тестовата е затворено копие за тестване. Промените обикновено вървят в една посока: от тестовата към продукционната среда, след като минат проверка.

В: Тестовата среда същото ли е като локалната среда за разработка?

О: Не. Локалната среда пуска WordPress на вашия компютър и е удобна, когато изграждате сайт от нулата. Тестовата среда работи на истинския ви хостинг сървър, затова отразява версията на PHP, конфигурацията на сървъра и кеширането, които публичният сайт реално използва.

В: Колко често да обновявам тестовото копие?

О: Преди всяка по-сериозна серия от промени. Остаряло копие може да скрие конфликти със съдържание, плъгини или настройки, добавени в публичния сайт след последното клониране.

В: Нужен ли ми е плъгин за тестова среда, ако хостингът ми я предлага?

О: Обикновено не. Вградената тестова среда покрива клонирането, тестването и публикуването, без да добавя още един плъгин в публичния сайт. Плъгинът има смисъл само ако ви трябва нещо, което инструментът на хостинга не предлага, например временно копие на външен сървър.

В: Мога ли да създам тестова среда ръчно?

О: Можете, но в SPanel не е нужно. С вградения WordPress Manager създавате тестова среда за WordPress с едно кликване: отворете WordPress Manager, кликнете бутона Actions до сайта и изберете Stage.