Като всички системи и WordPress непрекъснато се обновява, за да се поддържат сигурни дистрибуции на приложението. Всяко техническо лице, което работи с платформата, се сблъсква неизбежно с грешките, които възникват при процеса на обновяване.
В WordPress общността и форумите често се коментира защо обновяването на плъгин, тема или на самото приложение завършва неуспешно и генерира грешки.
В тази статия ще Ви запознаем с най-често срещаните timeout грешки при обновяване в WordPress и ще Ви предложим решения, които да Ви помогнат при анализа работата на приложението.
1. Какво представлява WordPress timeout при обновяване.
Процесът на обновяване на платформата WordPress (Вашият сайт) често отнема повече време, отколкото е планирано и това води до генериране на timeout.
Тази грешка може да се генерира при обновяване на различни елементи на платформата – темите, плъгините или самото ядро на системата.
Причините за това може да са комплексни – от достигане на зададените лимити на сървъра или друг тип засегнат ресурс, до необходимост от повече време за изпълнение на даден процес на обновяване, отколкото сървъра позволява.
Когато се генерира timeout грешка, сървърът прекъсва изпълнението на ъпдейта заради достигане на определеното от сървъра максимално време за изпълнение.
Ако стартираните ъпдейти не преминат, това би застрашило работата на сайта, като съответно би довело и до конфликти между самите елементи, тъй като обновяването е непълно и недовършено.
Често за решаване на този казус се налага настройка на сървърните параметри, оптимизация на самият сайт, както и създаване на приоритет при обновяването.
Например, ако е необходимо обновяване на плъгини, но ядрото на платформата е старо, препоръчително е да се започне от обновяване на ядрото, темата и след това да се обновят самите плъгини. Важно е да се извършват в този ред, тъй като плъгините често променят файловете на ядрото.
2. Какво предизвиква timeout грешката?
Няколко са основните фактори, които могат да предизвикат timeout грешка по време на обновяването на плъгини, темата или ядрото. Грешката, която се появява е следната:
There has been a critical error on your website.
Ще разгледаме най-често срещаните фактори, които предизвикват timeout:
Недостатъчно време за изпълнение на PHP процеса
Най-често timeout грешка възниква, когато стойността на лимита за времето за изпълнение на PHP процеса е недостатъчен, за да се осъществи обновяването.
Този параметър касае времето за изпълнение на процеса преди да бъде прекъснат и в повечето случаи неговата стойност е 30 секунди. Ако това време не е достатъчно, за да премине целият процес по обновяването, той ще прекъсне без да завърши.
Други основни параметри, които могат да попречат на този процес са:
Лимит на PHP паметта
Този лимит също е изключително важен за изпълнението на скрипта за обновяване, тъй като по подразбиране е 64М, но обикновено зависи от хостинг плановете и варира в различни граници.
Ако тази стойност е недостатъчна за изпълнение на обновяването, то недостигът на памет ще предизвика отново спиране на процеса и генериране на грешка.
Лимити на сървъра
Всяка хостинг компания залага такива ограничения и на сървърно ниво, като лимит на процесорното време, брой на едновременно активни процеси, връзки с базата данни и време за изпълнение на скриптовете. Обновления, които използват тези ресурси също могат да генерират timeout грешка.
Ограничение на сървърните ресурси
Всеки сървър има лимитирани процесорна мощност и памет, които не подлежат на увеличение. Тези параметри определят мощността на сървъра. Ако той няма достатъчно мощност, това може да доведе до забавяне изпълнението на обновяването и от там да се предизвика timeout.
Слаба и непостоянна интернет връзка
Ако мрежовата свързаност между сайта Ви и сървърите за обновяване на WordPress е бавна или непостоянна, това може също да генерира timeout грешки.
Голям размер на файловете за обновяване
В случай, че файловете за обновяване са с по-голям размер, това също може да генерира грешката.
Неоптимизиран код
Обновления на плъгини и теми, които са с неоптимизиран код също могат да доведе до забавяне на процеса по обновяване, което увеличава и предпоставките за генериране на timeouts.
Недостиг на ресурсите на базата данни
При процеса на обновяване се натоварва и MySQL сървъра, тъй като заявките към базата са по-бавни и по-обемисти. Ако ресурсите на сървъра не са предвидени за такова натоварване, процесът отново може да бъде прекъснат с timeout съобщение.
Load на сървъра
Прекъсването може да бъде породено и при увеличен трафик, който ангажира изцяло ресурсите на сървъра.
Големи по размер бази данни
Колкото по-голяма е една база данни, толкова по-тежки са заявките за нея и времето за обработка на заявката се увеличава пропорционално. Това води до неизбежно генериране на timeout грешка.
Права на файлове
В много редки ситуации е възможно потребителят да е променил правата на файловете и при обновяване поради тази причина да възникне грешка.
Ще се опитаме да обхванем всички възможни решения, които биха помогнали с изброените казуси - от настройката на параметрите на сървъра, до проверката дали сървърът има достатъчно ресурси, както и дали кодът на самото приложение е оптимизиран.
3. Решаване на казуси в следствие на timeout грешка
3.1. Настройка на сървърните лимити
Промяната на сървърните настройки е един от ключовете към решаване на timeout казусите. Тези настройки могат да спомогнат за гладкото преминаване на ъпдейтите на WordPress.
Един от основните и важни лимити на сървъра е времето за изпълнение на PHP процесите. Той указва максималното време за изпълнение на един процес. Когато скриптът за обновяване продължи повече, отколкото е зададеният параметър, винаги се стига до timeout грешката.
За да се настрои този параметър, е необходимо да се направи промяна в php.ini файла за дадената версия, като се заложи следният параметър:
ini_set( 'max_execution_time', '300' );Този параметър е достъпен на плановете на споделен хостинг, WordPress хостинг или eShop хостинг през cPanel, в полето PHP Selector на таб-а Options за съответната версия на PHP:
Другите възможности за настройка на този параметър са опция чрез директива в .htaccess файла:
След </IfModule> се добавя max execution 300 точно преди #END WordPress.Алтернатива на посоченият метод е добавяне директно в конфигурацията на приложението - wp-config.php
set_time_limit(300);Всяка по-висока стойност гарантира, че сървърът ще обработи докрай изпълнението на скрипта и обновяването ще премине гладко и без грешки.
3.2. Увеличаване лимита на паметта за изпълнение на обновяванията.
Лимитът на заделената памет за изпълнение на скрипта също има съществено значение, както и посочения по-горе лимит.
Ако заделената памет, по подразбиране тя е 64 МБ, е прекалено малко, а процесът за обновяване изисква повече, то това неминуемо ще се генерира timeout грешка.
Този параметър също може да бъде променен от cPanel, PHP Selector полето.
Пределната стойност на това ограничение също може да бъде добавена през конфигурационния файл на приложението wp-config.php със следната директива:
define('WP_MEMORY_LIMIT', '64M');като стойността по подразбиране бъде сменена - например с 256М или 512М. Такъв лимит е достатъчен за изпълнение на повечето обновявания.
Важно е да знаем, че посоченото количество памет се резервира при отварянето на всеки процес, затова не препоръчваме стойностите да са много големи, а да са достатъчни за изпълнението.
3.3. Оптимизиране на сървърните ресурси
Оптимизацията на сървърните ресурси е радикален начин за разрешаване на казусите с timeout при обновяване.
Ако използвате самостоятелна услуга (виртуален сървър - VPS) можете да изберет план с повече процесорно време и RAM памет. Tака ще улесните целият процес по обновяването на WordPress платформата.
За споделения хостинг е важно ресурсите да са максимално големи, за да могат да минават дългите и тежки скриптове за обновяване.
В повечето случай ние ще Ви предложим консултация кои планове бихте могли да използвате с цел максимално улеснение на преминаване процесите по обновяване.
Не забравяйте, че можете да конфигурирате двата параметъра, посочените по-горе.
3.4. Разделяне на обновяването на отделни по-малки части
Винаги е по-добре обновяването да се извършва на няколко етапа, като се пускат по-малки обновявания последователно. Така сървърните ресурси няма да са постоянно натоварени и няма да има отворени едновременно няколко тежки процеса, които да изразходват сървърната мощност.
Нашата препоръка е да разделите обновяването на три етапа, за да избегнете timeout грешките:
- Обновяване на ядрото на WordPress
- Обновяване на темата
- Обновяване на плъгините, като там можем да ги разделим на тежки плъгини (Elementor + WooCommerce) и по-леки плъгини.
При този подход на сегментиране на обновяването се постигат следните ефекти:
- намалява значително консумацията на сървърна мощ;
- процесът на обновяване се осъществява много по-бързо , отколкото ако всички ъпдейти се стартират едновременно
- по-лесно може да се открие кой елемент генерира съответната грешка.
3.5. Проверка на връзката с базата данни
Качеството на връзката с базата данни е една от основните причини за генериране на timeout грешката. Когато тя е бавна и нестабилна и изпълнението на обновяванията на WordPress може да се забави и да натовари MySQL сървъра.
Тук основният параметър е броят на едновременните заявки към базата данни. За плановете на споделен хостинг той е фиксиран, но може да бъде променян за всяка услуга.
Дали връзката с базата е активна и стабилна можем да проверим, като извадим информация от wp-config.php за името на базата на приложението, потребителя и паролата, и осъществим директна връзка с базата.
На услугата споделен хостинг е зададено ограничение за базата данни да не надхвърля големи от 1GB, тъй като това води до много тежки заявки и нестабилна работата на самата база данни, заради лимитите, които се достигат като например 'max_allowed_packet' параметъра.
Този параметър оказва влияение колко бързо могат да се изпращат данните на обновлението към базата и може да се провери чрез PhPMyAdmin на cPanel, като се изпълни следната заявка:
SHOW VARIABLES LIKE 'max_allowed_packet';
Ще получим отговор от сървъра колко е големината на позволените пакети:
Когато базата данни е оптимизирана и се използват допълнително кеширащи инструменти, като Redis, то обновяването на приложението ще протича гладко и без генериране на timeout.
Разбира се, ако приложението Ви е на самостоятелна услуга (виртуален сървър - VPS), то разполагате с контрол над всички параметри на MySQL сървъра, и можете да конфигурираме всеки един от тях в конфигурационния файл /etc/mysql/my.cnf ( /etc/my.cnf ).
При споделен хостинг плановете тези параметри не подлежат на промяна и са валидни за всеки план.
3.6. Обновяване на темите и плъгините и тяхното деактивиране при грешка
Най-често timeout грешките възникват при обновяването на плъгини и теми, като е важно всички те да са обновени до последни версии.
За да премине обновяването гладко, е препоръчително да се деактивират всички плъгини и най-напред да се обнови темата. Можем да изключим плъгините от административния панел, като използваме функцията за масово прилагане:
След като сме ги деактивирали, оставяме активен само плъгина, който ще обновим. Така сме освободили ресурси за да премине гладко обновяването и да не се предизвика поредната грешка.
Желателно е плъгините да се спират, независимо дали обновяваме ядрото или темата на приложението.
Тук ще добавим и една команда, която можем да използваме от командния интерпретатор за спиране и обновяване на плъгините.
Спиране на всички плъгини:
wp plugin deactivate --allОбновяване на всички плъгини:
wp plugin update --all3.7. Проверка на сървърни логове.
За да определим от къде се генерира timeout грешката, е необходимо да се прегледа генерираната информация в логовете на сървъра.
Cpanel предлага достъп до тези логове от полето Metrics, като информацията за грешките в лога на уеб сървъра се генерират от полето Errors.
Допълнителна информация може да се открие в полето RAW Access ,което съдържа допълнителна извадка на полезни сървърни логове.
Разбира се, при обновяването и възможни timeout грешки е много важно да проверим PHP лога, който в нашите планове се генерира в работната папка на домейна под името error_log.
Важните файлове са на две места, като едното е - /home/cpaneluser/public_html/error_log. Това е логът за front end приложението или видимият сайт.
Когато възниква грешка при обновяване на административния панел, то информация ще има записана и в папка /home/cpaneluser/public_html/wp-admin/error_log.
Важно е да разполагаме с информация и от двата файла, за да можем най-пълно да анализираме причината за възникналият казус.
3.8. Промяна правата на файловете.
В много редки случай timeout грешките при обновяване могат да се генерират и при промяна на правата на файловете на сървърно ниво.
В този случай скриптът се опитва да обнови даден файл, но не получава разрешение да пише в него или да го променя и влиза в loop режим от опити докато се генерира timeout грешка.
За да сме сигурни, че обновяването ще мине гладко, можем да проверим правата на папките и файловете за WordPress инсталацията.
Всички папки трябва да са с права 755, а файловете с права 644 за да бъдат достъпни. Това можем да направим чрез FileManager полето на cPanel.
От таблицата с правата можем да зададем необходимите права, ако видим че не са коректни:
3.9. Проверка на интернет връзката
Интернет връзката също е значим фактор при генериране на timeout грешка при обновяването на WordPress.
Ако връзката е стабилна и бърза, Вашият обслужващ хостинг сървър ще се свърже безпроблемно със сървърите за обновяване на WordPress и процесът ще протече възможно най-гладко.
Най-бързият начин да проверим интернет връзката е като от командният ред през терминала на хостинга пуснем ping команда до например публичният DNS сървър на Google, който е най-лесно достъпен на адрес 8.8.8.8.
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=34.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=36.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=36.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=35.5 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=36.7 ms
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005 ms
rtt min/avg/max/mdev = 34.181/35.678/36.699/0.845 msТова ще ни даде информация дали имаме добра интернет свързаност, за да можем да осъществим обновяване на WordPress, без да се предизвика грешка.
4. Обобщение
В настоящата статия прегледахме най-често генерираните timeout грешки при обновяване на WordPress платформата и възможните причини, които ги предизвикват.
Посочихме и няколко важни акцента - как да съберете информация, да я анализирате и да разрешите дадения казус, свързан с грешката.
Разбира се, нашият професионален WordPress Съпорт екип винаги е на разположение, за да се погрижи Вашето приложение да работи оптимизирано и акуратно в нашата хостинг среда.
С атрактивните пакети за поддръжка ние Ви предлагаме да извършим за Вас описаните анализи, проверки и действия, които да подпомогнат решаването на казуса с Вашето приложение на базата на дългогодишният ни професионален опит в обслужването на WordPress платформата.
Все пак, ако за Вас е предизвикателство да потърсите сами решение, избрахме и селектирахме за Вас най-популярните и коментирани във WordPress обществото казуси, с които бихте могли да се сблъскате в ежедневната си работа с платформата.
В статията са използвани материали от WordPress обществото и интернет пространството.
