Поправете фаталната грешка на Polylang, свързана с Lingotek

by | WordPress

Ако някога сте виждали „фатална грешка на Polylang“ в лог файловете си със споменаване на превод на линготекВероятно сте имали бял екран, грешка 500 или недостъпен бек офис веднага след актуализация.

Ключовият момент: Polylang работи, но друг компонент (често Lingotek Translation) го извиква в неподходящ момент, с несъвместима версия или при частично инициализирана инсталация.

Проблемът

Точното съобщение варира в зависимост от версията, но фатални грешки от този тип са много често срещани (реалистични примери):

Fatal error: Uncaught Error: Call to undefined function pll_current_language()
in /wp-content/plugins/lingotek-translation/includes/class-lingotek.php:123
Stack trace:
#0 /wp-includes/class-wp-hook.php(324): Lingotek->bootstrap()
#1 /wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#2 /wp-includes/plugin.php(517): WP_Hook->do_action()
#3 /wp-settings.php(700): do_action('plugins_loaded')
thrown in /wp-content/plugins/lingotek-translation/includes/class-lingotek.php on line 123
Fatal error: Uncaught Error: Class "PLL_Model" not found
in /wp-content/plugins/lingotek-translation/vendor/somefile.php:77
thrown in /wp-content/plugins/lingotek-translation/vendor/somefile.php on line 77
Fatal error: Uncaught TypeError: strpos(): Argument #1 ($haystack) must be of type string, null given
in /wp-content/plugins/polylang/include/some-file.php:456
Stack trace: ...

Къде се появява:

  • Front-End грешка 500 / празна страница веднага щом заредите страница.
  • Admin „Възникна критична грешка на този сайт.“, понякога само на Pages / Cтатии / преводи.
  • Cron / WP-Cron грешки в лог файловете по време на планирана задача (синхронизация на Lingotek, импортиране/експортиране и др.).
  • REST API / AJAX : грешки при заявките към Elementor/Divi/Avada (преглед, зареждане на шаблони), тъй като тези конструктори използват интензивно REST API.

Типични обстоятелства:

  • След един актуализация от Polylang, Lingotek Translation или WordPress (вие сте на WordPress) 6.9.4 през април 2026 г.).
  • След активиране на Lingotek Translation на вече многоезичен сайт.
  • След миграция (подготовка → производство), където опции или таблици бяха частично копирани.
  • След добавяне на фрагмент (дъщерна тема / плъгин за фрагмент), който нарича Polylang „твърде рано“.

За кого е това ръководство? Ако сте начинаещ, ще се научите да възстановяване на повреден уебсайт Без паника, изолирайте конфликта, прочетете лог файловете и приложете безопасни корекции (без да променяте WordPress или плъгини). Ако сте потребител със средно ниво/професионален опит, ще си тръгнете с... mu-plugin protection и възпроизводим метод.

Бързо обобщение

  • Фатална грешка, като например „Polylang + Lingotek“, най-често произтича от извикване на Polylang преди зареждането му (закачете твърде рано) или несъвместимост на версиите.
  • Започнете с деактивиране на превода на Lingotek (или всички плъгини с изключение на Polylang), за да потвърдите конфликта.
  • Активиране на регистриране с WP_DEBUG_LOG и извличане точната линия (файл + номер на ред).
  • Ако фрагмент извика pll_current_language() в plugins_loaded или още по-лошо, когато зареждате файла, преместете го върху wp_loaded / init с предпазни мерки.
  • След това поправете низовете и изчистете кеша (плъгин за кеш, OPcache, конструктор на кешове), след което запазете отново постоянните връзки.
  • Ако сайтът остане нестабилен, използвайте Здравен преглед et Монитор на заявките за прецизно изолиране на дефектния компонент.

Симптомите

Ето какво най-често ще виждате на сайт с WordPress 6.9.4:

  • 500 грешка от страната на посетителя и/или бял екран.
  • „В този сайт възникна критична грешка“ в администраторския панел, понякога придружено от автоматичен имейл от WordPress.
  • Няма достъп преводи (менюта на Polylang) или към редактора (Gutenberg) за преведено съдържание.
  • Преглед на Elementor който е заседнал в цикъл или Divi 5 модули, които вече не се зареждат (REST заявки са грешни).
  • В конзолата на браузъра: 500 грешки на /wp-json/ или admin-ajax.php.
  • В PHP логовете: „Извикване на неопределена функция pll_*„Клас“ PLL_* „не е намерен“, „Не може да се декларира отново…“ или Тип грешка след надграждане до PHP 8.1+.

Бърза диагностична диаграма (много полезна, когато трябва да решите какво да тествате първо):

симптом Вероятна причина проверка Решение
Грешка 500 директно от началната страница Фатална грешка при зареждане на плъгин (Lingotek) Консултирайте wp-content/debug.log или сървърни логове Деактивирайте Lingotek, след което го активирайте отново след актуализиране/корекция (Решение 1)
Администраторът е ОК, но редакторът/предварителен преглед е нокаутиран REST API е прекъснат от кука Polylang/Lingotek тест /wp-json/конзола на браузъра Поправям куката „твърде рано“ (Решение 2)
„нулев“ език / непреведени низове Повредени низове на Polylang / постоянен кеш Polylang > Преводи на низове, изчистване на кеша Поправка на низове + почистване + постоянни връзки (Решение 3)
Работи локално, не в производство. OPcache / PHP версия / плъгин за кеширане Рестартирайте PHP-FPM, изчистете кеша, проверете PHP 8.1+ Почистване + подравняване на версиите + временно деактивиране на кеша

Защо се случва това?

Просто обяснение: Polylang предоставя функции (напр. pll_current_language()) и вътрешни класове. Ако друг плъгин (често Lingotek Translation) ги използва преди Polylang да е завършил зарежданетоPHP не може да ги намери и сайтът ви се срива.

Ето какво се случва зад кулисите (техническа версия):

  • WordPress зарежда плъгините, след което ги задейства мерки („Кука“ за действие е точка на прикрепване, където се изпълнява код.) Пример: plugins_loaded, init, wp_loaded.
  • Polylang не предоставя всички свои функции/класове в първата милисекунда. Някои неща се инициализират чрез куките (hooks).
  • Ако Lingotek (или фрагмент) се закачи за plugins_loaded и се обажда веднага pll_current_language()Може да срещнете „неопределена функция“.
  • С PHP 8.1+, грешките, които са били „предупреждения“, стават Тип грешка (строги типове). Едно null Неочакваното може да стане фатално.

Причините са изброени от най-честите към най-редките:

  • Несъвместимост на версиите Преводът на Lingotek не е актуален по отношение на Polylang (или обратното).
  • Зареждане на реда / закачане твърде рано : извикване на Polylang API преди инициализация.
  • Счупен фрагмент в плъгина за дъщерна тема / snippets, който приема, че Polylang е все още активен.
  • Постоянен кеш (OPcache, кеш на страници, кеш на обекти), който поддържа „смесено“ състояние след актуализация.
  • Частична миграция Непоследователни опции на Polylang/Lingotek, дублиращи се низове, липсващи таблици.
  • Конфликт със строител Elementor/Divi/Avada задействат REST/AJAX маршрути, които преминават през непроверен път на код.

Предварителни изисквания преди започване

Преди всяка манипулация:

  • Запазване Файлове + база данни. Никога не тествайте „на случаен принцип“ в продукция.
  • Ако е възможно, работете върху постановка (копие на вашия сайт).
  • Проверете версиите си: WordPress 6.9.4Препоръчва се PHP 8.1 + (8.2/8.3 често са ОК, в зависимост от доставчика на хостинг услуги).

Полезни (безплатни) инструменти:

Активиране на лог файлове на WordPress (препоръчително за това отстраняване на неизправности):

  • отворено wp-config.php (в основата) и добавете/коригирайте константите по-долу.
  • Не позволявайте показване на грешки в производствения режим (Риск от изтичане на данни). Влезте, не показвайте.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
/* Sécurité : on évite d'afficher les erreurs aux visiteurs */
define('WP_DEBUG_DISPLAY', false);

Официална документация: Отстраняване на грешки в WordPress.

Решение 1: Изолирайте Lingotek (и проверете съвместимостта с Polylang)

Когато попадна на „Фатална грешка на Polylang, може би с lingotek-translation“, почти винаги започвам с това: потвърдете, че Lingotek наистина е причината за грешката, след което подравнете версиите.

Стъпка A — Потвърждаване на конфликта (без да се нарушава работата на сайта)

Ако все още имате достъп до администраторския панел:

  1. отивам Разширения> Инсталирани разширения.
  2. Деактивирайте Превод на Линготек.
  3. Тествайте предния край и администраторския панел.

Ако вече нямате достъп до администраторския панел (критична грешка):

  1. Свържете се чрез FTP/SFTP или чрез файловия мениджър на доставчика на хостинг услуги.
  2. отивам wp-content/plugins/.
  3. Преименуване на папката lingotek-translation en lingotek-translation.off.

WordPress автоматично ще деактивира плъгина при следващото зареждане.

Стъпка Б — Актуализирайте правилно (Polylang + Lingotek)

След като сайтът е отново онлайн:

  • Актуализирайте превода на Polylang и Lingotek от Табло> Актуализации.
  • Ако актуализацията е неуспешна, преинсталирайте плъгина чисто (изтрийте го и след това го инсталирайте отново). На многоезичен сайт, направете това първо в секцията за подготовка.

Официални източници:

код ПРЕДИ (счупен) — непроверена зависимост

Класическият случай: Lingotek (или друг плъгин/фрагмент) приема, че Polylang е активен и извиква функция на Polylang без никакви предпазни мерки.

<?php
// Exemple typique : appel direct sans vérifier si Polylang est chargé.
$lang = pll_current_language(); // Fatal si Polylang n'est pas prêt (ou désactivé)
update_option('my_last_lang', $lang);

AFTER код (коригиран) — предпазни мерки + време

Не променяте Lingotek директно. Вместо това можете да добавите „предпазна мярка“ от страната на сайта, за да предотвратите фатални последици, ако е замесен персонализиран фрагмент.

Къде да поставите този код: в идеалния случай в mu-плъгин (плъгинът „задължителен за употреба“, зарежда се автоматично). Създайте файла:

  • wp-content/mu-plugins/bpcab-polylang-guards.php
<?php
/**
 * Plugin Name: BPCAB - Garde-fous Polylang
 * Description: Évite des fatals si du code appelle Polylang trop tôt ou si Polylang est désactivé.
 * Author: Votre équipe
 * Version: 1.0.0
 */

if (!defined('ABSPATH')) {
	exit;
}

/**
 * On attend que WordPress ait chargé les plugins, puis on exécute plus tard si nécessaire.
 * wp_loaded arrive après init et après la mise en place de l'environnement WordPress.
 */
add_action('wp_loaded', function () {

	// Polylang expose des fonctions globales pll_* quand il est actif et initialisé.
	if (!function_exists('pll_current_language')) {
		// Polylang n'est pas actif ou pas prêt : on sort sans casser le site.
		return;
	}

	$lang = pll_current_language();

	// Exemple d'utilisation sûre.
	if (is_string($lang) && $lang !== '') {
		update_option('my_last_lang', $lang, false);
	}
}, 20);

Защо се коригира:

  • function_exists() избягва фаталното извикване, ако Polylang липсва/не е зареден.
  • wp_loaded намалява риска от извикване на Polylang по време на фазата му на инициализация.
  • Le mu-плъгин е по-надежден от фрагмент в тема (темата може да бъде променена, конструкторът може да презапише шаблони и т.н.).

Забележка: ако настъпи фаталният uniquement От гледна точка на Lingotek, тази предпазна мярка няма да поправи вътрешния им код. Основната ѝ цел е да елиминира „скрити“ фрагменти (дъщерни теми, плъгини за фрагменти), които влошават ситуацията. За Lingotek дългосрочното решение обикновено е: актуализация ou деактивиране (вижте раздела „Вариант / алтернатива“).

Решение 2: Поправете код, който извиква Polylang твърде рано (hooks)

Често съм виждал този бъг в сайтове, където някой е копирал част от „многоезичен“ код в functions.php (дъщерна тема) или в плъгин за фрагменти. Работи... до деня, в който някоя актуализация промени времето за инициализация.

Бързо определение:

  • Un кука е кука в WordPress.
  • Une действие изпълнява код в даден момент (напр. init).
  • Un Филтър променя стойност (напр. the_content).

Официална справка: Куки (действия и филтри).

Често срещан сценарий: подкана за зареждане на файл (най-лош сценарий)

ПРЕДИ код (счупен). Виждаме го в functions.php или плъгин за фрагменти:

<?php
// Mauvaise pratique : ce code s'exécute dès l'inclusion du fichier.
$current = pll_current_language(); // Fatal si Polylang n'est pas encore prêt
$GLOBALS['my_lang'] = $current;

Код СЛЕД (коригиран). Къде да се постави: в functions.php d'ООН детска тема (Divi/Avada/Hello Elementor) или, още по-добре, в малък персонализиран плъгин.

<?php
/**
 * Initialise une variable globale de langue de façon sûre.
 * À coller dans functions.php du thème enfant, ou dans un plugin custom.
 */

add_action('wp_loaded', function () {

	if (!function_exists('pll_current_language')) {
		// Polylang absent ou désactivé : on définit une valeur par défaut.
		$GLOBALS['my_lang'] = get_locale();
		return;
	}

	$lang = pll_current_language();

	$GLOBALS['my_lang'] = (is_string($lang) && $lang !== '') ? $lang : get_locale();
}, 20);

Случай с Builder (Divi 5 / Elementor / Avada): REST/AJAX изпълнен без "front" контекст

Конструкторите задействат заявки, които не приличат на тези на нормална страница. Ако вашият код приема, че „ние сме на предния край“, можете да повредите редактора.

Код ПРЕДИ (счупен): изпълнение на всички заявки, включително REST/AJAX.

<?php
add_action('init', function () {
	// Exemple : redirection selon langue, mais déclenchée partout.
	if (function_exists('pll_current_language') && pll_current_language() === 'en') {
		wp_redirect(home_url('/en/'));
		exit;
	}
});

Код СЛЕД (коригиран): избягваме REST/AJAX/admin и го ограничаваме до началните страници.

<?php
add_action('template_redirect', function () {

	// Sécurité : pas de redirection en admin.
	if (is_admin()) {
		return;
	}

	// Évite de casser l'éditeur Elementor/Divi/Avada (REST/AJAX).
	if (wp_doing_ajax() || (defined('REST_REQUEST') && REST_REQUEST)) {
		return;
	}

	if (!function_exists('pll_current_language')) {
		return;
	}

	$lang = pll_current_language();
	if ($lang !== 'en') {
		return;
	}

	// Exemple : redirection contrôlée.
	$target = home_url('/en/');

	// Évite les boucles de redirection.
	if (home_url(add_query_arg([], $GLOBALS['wp']->request)) === $target) {
		return;
	}

	wp_safe_redirect($target, 302);
	exit;
}, 20);

Защо се коригира:

  • template_redirect „предната“ кука е по-подходяща за пренасочване, отколкото init.
  • Защитните мерки wp_doing_ajax() et REST_REQUEST избягвайте нарушаване на техническите изисквания на строителите.
  • wp_safe_redirect() ограничава риска от пренасочване към неоторизиран домейн (сигурност).

Официални справки:

Решение 3: Поправете низовете, нулирайте кешовете и генерирайте отново правилата

Когато фаталната грешка е изчезнала, но все още имате странно поведение (нулев език, непреведени низове, нестабилни REST маршрути), проблемът често е непоследователно състояние: кеш + опции + правила за пренаписване.

Стъпка A — Изчистване на кеша (в правилния ред)

Редът, който прилагам на практика (иначе може да „повярвате“, че не работи):

  1. Изчистване на кеша на плъгини (WP Rocket, LiteSpeed ​​​​Cache, W3TC и др.).
  2. Ако имате кеш на сървъра (LiteSpeed, Nginx FastCGI, Varnish), изчистете го от страната на хостинга.
  3. Рестартирайте PHP-FPM / изчистете OPcache, ако хостинг доставчикът го позволява (в противен случай изчакайте няколко минути).
  4. Обновете браузъра (Ctrl+F5) или го тествайте в режим на частно сърфиране.

С Elementor/Divi/Avada, помислете също:

  • Elementor: „Регенериране на CSS и данни“ (в зависимост от версията) и изчистване на вътрешния кеш.
  • Divi 5: изчистване на статичния/производителния кеш, ако е активиран.
  • Avada: изчистете кеша на „Fusion“, ако има такъв.

Стъпка Б — Пререгистрирайте постоянните връзки (пренапишете правилата)

Когато преведените маршрути се променят (слугове, езици, директории), WordPress може да запази стари правила за пренаписване.

  1. отивам Настройки> Постоянни връзки.
  2. Без да променяте нищо, щракнете Запазване на промените.

Официална справка: flush_rewrite_rules() (да не се извиква на всяка страница, само когато има промяна).

Стъпка C — Поправяне на „низове“ в Polylang (в случай на преводи на низове)

Polylang управлява „низове“, за да превежда текстове, които не идват от статия (напр. слогани, джаджи, опции за теми). След срив или миграция съм виждал дублирани или непълни низове.

Не се изисква код (препоръчително за начинаещи):

  • отивам Езици> Преводи на низове.
  • Потърсете проблемни низове и ги запишете отново, ако е необходимо.

С код (ако имате тема/плъгин, който запазва низове): грешката често идва от твърде ранното запазване.

Код ПРЕДИ (счупен): запис на низ при зареждане на файл (или при твърде ранно зареждане на hook).

<?php
// Mauvais timing : Polylang peut ne pas être prêt.
pll_register_string('Mon slogan', get_option('blogdescription'), 'Theme');

Код СЛЕД (коригиран): запис на init с предпазни мерки.

Къде да се постави: functions.php на дъщерната тема или персонализиран плъгин.

<?php
add_action('init', function () {

	// pll_register_string() n'existe que si Polylang est actif.
	if (!function_exists('pll_register_string')) {
		return;
	}

	$desc = get_option('blogdescription');
	if (!is_string($desc)) {
		$desc = '';
	}

	// On enregistre une chaîne stable (clé + groupe) pour éviter les doublons.
	pll_register_string('site_tagline', $desc, 'Theme');
}, 20);

Защо се коригира:

  • Избягвате фаталното повикване, ако Polylang е деактивиран.
  • Използвате стабилен ключ (site_tagline) вместо етикет на променлива, което ограничава дубликатите.
  • Куката init е добър компромис: WordPress е инициализиран и Polylang е като цяло готов да запазва низове.

Проверки след корекция

След като разтворът е приложен, винаги го тествайте:

  • Предна част: начална страница + преведена страница + непреведена страница.
  • Администратор: редактиране на по една статия на всеки език и отваряне на екраните Polylang.
  • REST API: отворено https://votre-site.tld/wp-json/ (трябва да получите JSON, а не 500).
  • Строители:
    • Elementor: Преглед на преведена страница.
    • Divi 5: Зареждане на Visual Builder на преведена страница.
    • Avada: Зареждане на Fusion builder на преведена страница.
  • Дневници: wp-content/debug.log трябва да спре да добавя смъртни случаи към всеки удар.

Ако бяхте активирали WP_DEBUGпазя WP_DEBUG_LOG След процеса на валидиране, деактивирайте публичното показване на грешки.

Ако това все още не работи

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

1) Извлечете точната грешка

  • чета wp-content/debug.log (ако е активирано).
  • В противен случай проверете PHP лог файловете на хостинг доставчика (често „error_log“).
  • Копие: съобщение + файл + редБез това можем да гадаем.

2) Режим „Отстраняване на неизправности“ (Проверка на състоянието)

Активирайте проверката на състоянието, след което:

  • Активирайте режима за отстраняване на неизправности.
  • Деактивирайте всички плъгини с изключение на Polylang.
  • Тествайте го. Ако е наред, активирайте отново Lingotek Translation самостоятелно, а след това и останалите един по един.

Това избягва класическия капан: „Деактивирам плъгин и счупвам сайта за всички“.

3) Проверете версията на PHP и паметта

  • PHP: препоръчителна минимална версия 8.1. Под тази версия се увеличава броят на съвременните несъвместимости.
  • Памет: Ако видите грешки като „Разрешеният размер на паметта е изчерпан“, увеличете WP паметта.

Официална препратка (дипломна работа): Увеличаване на паметта, разпределена за PHP.

4) Монитор на заявки: идентифициране на дефектния hook/компонент

  • Инсталирайте монитора на заявките.
  • Отворете страницата, която се прекъсва.
  • Разгледайте „PHP грешки“ и „Hooks & Actions“, за да видите какво се изпълнява точно преди срива.

5) Конфликт на кеша/OP-кеша

Ако сте поправили някакъв код, но фаталната грешка продължава „сякаш нищо не се е променило“, имам два заподозрени:

  • OPcache (PHP) съхранява компилирана версия на файл.
  • Кеширащият плъгин обслужва „стара“ HTML страница или кеширан REST отговор.

Опитайте временно да деактивирате кеша и ако е възможно, рестартирайте PHP от страната на хостинга.

6) Последна мярка: деактивирайте Polylang, след което го активирайте отново

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

Често срещани капани и грешки

симптом Вероятна причина Препоръчително решение
Фатална „неопределена функция pll_current_language()“ Кодът е изпълнен твърде рано / Polylang е деактивиран Продължи напред wp_loaded + function_exists() (Решение 2)
Поставяте кода „на грешното място“ Фрагмент, поставен във файл на плъгин, но извън PHP тагове или в родителската тема Използвайте дъщерна тема или mu-plugin; проверете <?php и местоположението
Грешка след модификация: „Грешка при синтактичен анализ“ Липсва точка и запетая, забравена скоба Връщане през FTP, corriger синтаксиса, използвайте редактор с подсветка на синтаксиса
Редакторът Elementor/Divi вече не се зарежда Пренасочване / езикова логика, изпълнявана върху REST/AJAX Защитни мерки REST_REQUEST et wp_doing_ajax() (Решение 2)
Работи след деактивиране, след което се поврежда отново след повторно активиране. Несъвместимост между версиите на Polylang/Lingotek Актуализирайте, в противен случай заменете Lingotek (Решение 1 + Вариант)
Грешката се „връща“ въпреки поправката Кешът на сървъра/OPcache не е изчистен Изчистете кеша и рестартирайте PHP-FPM, ако е възможно (Решение 3)
Постоянните връзки са преведени на 404 Пренапишете остарелите правила Пререгистриране на постоянни връзки (Решение 3)

Две грешки, които виждам постоянно:

  • Тестване директно в продукцията Без резервно копие. Една проста „грешка при синтактичен анализ“ може да ви блокира като администратор.
  • Използване на неподходяща кука : init за пренасочване или код при зареждане на файла. Той „работи“ до деня, в който спре да работи.

Вариант / алтернатива

Алтернатива без код: заменете Lingotek Translation

Ако имате нужда от „превод и управление на езици“, но Lingotek е източникът на нестабилност, най-простото решение понякога е да:

  • Запазете Polylang за многоезичната структура.
  • Използвайте друг канал за превод (ръчен или съвместима услуга) вместо Lingotek.

Нека бъда откровен: когато външен плъгин за интеграция на превод вече не е съобразен с последните версии, можете да прекарате часове в „кърпене“, когато истинската полза е опростяването.

Алтернативен подход за разработчици: капсулиране на достъпа до Polylang чрез „безопасна“ функция

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

Къде да се постави: mu-plugin (препоръчително) или персонализиран плъгин.

<?php
/**
 * Retourne une langue courante de façon robuste.
 * - Si Polylang est disponible : on l'utilise.
 * - Sinon : fallback sur la locale WordPress.
 */
function bpcab_get_current_language_code(): string
{
	if (function_exists('pll_current_language')) {
		$lang = pll_current_language();
		if (is_string($lang) && $lang !== '') {
			return $lang;
		}
	}

	// Fallback : ex "fr_FR" - à adapter si vous voulez "fr".
	return (string) get_locale();
}

След това, заменете навсякъде pll_current_language() равенство bpcab_get_current_language_code().

Избягвайте този проблем в бъдеще

  • Никога не модифицирайте ядрото (WordPress), нито директно плъгин. Всяка актуализация ще презапише промените ви.
  • Избягвайте да поставяте критични фрагменти в родителската тема. Използвайте детска тема където mu-плъгин.
  • Когато използвате Polylang в кода:
    • Винаги проверявайте function_exists('pll_current_language') / function_exists('pll_register_string').
    • Изберете постоянна кука: init да записвам неща, wp_loaded да прочете крайното състояние, template_redirect за пренасочвания от предния край.
  • След голяма актуализация:
    • Плъгин за почистване на кеша + сървър.
    • Запазете отново постоянните връзки, ако сте променили езиците/слуговете.
  • Поддържайте известно време за подготовка. В многоезични сайтове това е практически задължително, ако имате външни интеграции.

Справка за PHP (поведение на TypeError): Грешки в PHP (PHP 7+ и съвременни версии)Въпреки че на страницата се споменава „PHP 7+“, идеята е същата: грешките в типа са по-строги, а PHP 8.1+ ги прави по-видими.

ресурси

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

Как можем да разберем дали Polylang или Lingotek нарушава работата на сайта?

Вижте файла във фаталната грешка (в debug.logАко пътят сочи към /plugins/lingotek-translation/Линготек тригери грешкатаАко сочи към вашата дъщерна тема или плъгин за фрагменти, вашият код извиква Polylang в неподходящ момент.

Нямам никакви debug.logТова нормално ли е?

Да, ако WP_DEBUG_LOG не е активиран или ако сървърът няма права за запис на wp-content/Активирайте константите и проверете разрешенията.

Ще изтрие ли деактивирането на Lingotek преводите ми?

Обикновено преведеното ви съдържание остава в WordPress (като публикации/страници). Възможно е функциите за синхронизация с Lingotek да изчезнат. Тествайте това на вашия тестов сайт, ако разчитате основно на този фийд.

Защо възниква грешката „след актуализация“, когато не съм променил нищо?

Тъй като плъгинът може да промени времето си за инициализация или да стане по-строг (PHP 8.1+), кодът, който преди това е бил преминал „случайно“, може да стане фатален за една нощ.

Мога ли да поправя това, като директно модифицирам плъгина Lingotek?

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

Коя кука е най-безопасна за четене на ежедневен език?

На повечето сайтове, wp_loaded е добра „късна“ точка за четене. За да промените външния вид на съдържанието, използвайте филтри. the_content (проверка на съвместимостта с REST/AJAX, ако е необходимо).

Съвместими ли са Elementor/Divi/Avada с Polylang?

Да, в повечето случаи, но конструкторите задействат много REST/AJAX заявки. Проблемът често идва от пренасочванията или езиковите условия, които се изпълняват при тези технически заявки. Защитните мерки в Решение 2 предотвратяват точно това.

Коригирах кода, но грешката продължава. Защо?

Кеш. Изчистете кеша на плъгина и сървъра, и ако е възможно, OPcache. Виждал съм доставчици на хостинг услуги да пазят „стар“ PHP файл в продължение на няколко минути.

Трябва ли да пререгистрирам постоянните връзки след промяна на езиците?

Да, веднага щом промените структурата на URL адреса (език в директории, преведени пълзящи кодове и т.н.). Това е бързо и поправя много 404 грешки.

Изисква ли се PHP 8.1?

В WordPress 6.9.4, PHP 8.1+ е минималната препоръчителна версия, за да се запази съвместимостта с текущата екосистема. Всичко под тази версия значително увеличава риска от грешки и неподдържани плъгини.

Статии

Коментирай

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани *

Този сайт използва Akismet за намаляване на спама. Научете как се обработват вашите коментарни данни.