- Вопрос или проблема
- Вопрос
- Резюме
- Шаги для воспроизведения
- Подробный анализ
- Что мы пробовали
- Ответ или решение
- Почему WordPress переписывает абсолютные URL-адреса на тестовом сайте, добавляя префикс «staging», когда мы вручную указываем их на живом сайте?
- Введение
- Причины переписывания URL-адресов
- Рекомендации по решению проблемы
- Заключение
Вопрос или проблема
Отредактировано для ясности и для отображения шагов, которые мы предпринимаем для воспроизведения проблемы.
Вопрос
Что может привести к тому, что абсолютные URL на нашем тестовом сайте будут добавлять поддомен тестового сайта к ним при сохранении в редакторе?
Резюме
Мы вручную пишем страницы на HTML и CSS на тестовом сайте, размещенном на SiteGround, сохраняем наши изменения, а затем тестируем их. Однако когда мы сохраняем нашу работу в редакторе, все они добавляют поддомен тестового сайта, на котором мы пишем, ко всем абсолютным URL, которые мы написали.
Шаги для воспроизведения
- Создайте тестовую копию живого сайта.
- Отключите все плагины.
- Установите и активируйте тему по умолчанию «двадцатилетие девятнадцать» из WordPress.
- Создайте новую страницу, дайте ей любое имя.
- На этой странице создайте четыре ссылки:
a. http://example.com
b. http://www.example.com
c. https://example.com
d. https://www.example.com - Сохраните страницу.
- Просмотрите страницу – все ссылки ведут на https://stagingX.example.com
- Отредактируйте страницу – все ссылки будут иметь «stagingX.» перед ними, что показывает, что они были перезаписаны.
Подробный анализ
Мы пишем адрес ссылки как абсолютный URL на страницу, например:
«Нажмите здесь для наших <a href="https://example.com/daily-specials">Ежедневных предложений</a>!»
Затем мы сохраняем нашу работу в редакторе.
Если мы сразу проверим ссылку на тестовом сайте, она уже будет указывать на <a href="https://staging.example.com/daily-specials"></a> и будет отображаться как таковая, если мы снова запустим редактор.
Хотя это не влияет на любые относительные URL (т.е. <a href="https://wordpress.stackexchange.com/daily-specials"></a>), это влияет на каждую вариант префикса абсолютных URL.
На сайте есть тысячи абсолютных URL, затронутых этим.
Что мы пробовали
Мы должны что-то упустить, так что, пожалуйста, не стесняйтесь предложить любые советы или точки зрения, независимо от того, кажутся ли они избыточными или нет.
Мы пытались проверить сервер, тему и файлы .htaccess и functions.php дочерней темы в cPanel на наличие кода, который мог бы вызывать это (возможно, мы упустили или неправильно поняли это?).
Мы также проверили, что URL сайта и т.д. в разделе “Настройки > Общие” панели управления WordPress указывают на живой сайт без префикса тестирования.
Мы отключили все плагины и переключились на тему Twenty Nineteen и испытываем те же проблемы.
URL главной страницы и URL сайта в настройках и в базе данных установлены на основной сайт, но в разделе помощи плагина «Лучший поиск и замена» показываются оба URL с префиксом поддомена тестирования.
Вы проверили два URL в таблице wp_options? Именно там WP получает базовый URL для сайта.
Если вы перенесли базу данных сайта с тестирования на живой, вы могли забыть изменить эти значения в таблице wp_options.
Вы должны использовать относительные ссылки (/path/here) вместо абсолютных URI, включая схему, это снизит вероятность возникновения проблем с небезопасными активами. Тогда все, что вам нужно сделать, это установить параметры home и siteurl в таблице wp_options на правильные URL.
Если они жестко закодированы в постах/страницах, вы можете использовать wp-cli или лучший поиск и замену, чтобы заменить URL контента на относительные ссылки или правильно префиксированный URL, хотя настоятельно рекомендуется использовать относительные URI.
Похоже, это связано с конфликтом между процессом тестирования SiteGround и процессом хранения базы данных плагина, который мы используем, TagDiv Composer, который является частью темы от тех же разработчиков.
Все сводится к тому, что настраиваемые блоки HTML плагина хранят все эти URL в закодированном формате вместе со всем остальным, а правила перезаписи, используемые нашим сервером в тестировании, ищут URL в базе данных (которые он не может прочитать в проприетарном коде). Спасибо всем за помощь в нахождении настоящей проблемы!
Ответ или решение
Почему WordPress переписывает абсолютные URL-адреса на тестовом сайте, добавляя префикс «staging», когда мы вручную указываем их на живом сайте?
Введение
Ваша проблема с переписыванием абсолютных URL-адресов на тестовом сайте WordPress — это распространённая ситуация, с которой сталкиваются разработчики и веб-мастера. Давайте проанализируем возможные причины этого поведения, рассмотрим детали, шаги для воспроизведения проблемы и возможные решения.
Причины переписывания URL-адресов
-
Настройки базы данных: Первоначальные URL-адреса для сайта WordPress хранятся в таблице
wp_options, в частности в поляхsiteurlиhome. Если после миграции с живого сайта на тестовый префикс этих URL-адресов не были обновлены, WordPress может автоматически переписывать URL-адреса на основании значений, содержащихся в этих полях. Необходимо проверить и изменить их, если они всё ещё указывают на тестовый домен. -
Проблемы с кешированием: Если тестовый сайт использует плагин кеширования или любит кэшировать данные, это может вызвать конфликты с сохранением обновленных URL-адресов. Убедитесь, что кэш отключен в процессе редактирования страниц.
-
Конфликт с плагинами и темами: Ваше упоминание о конфликте с плагином TagDiv Composer указывает на возможность того, что некоторые плагины или темы вносят изменения в содержание по умолчанию, что приводит к переписыванию ссылок. Несмотря на то, что вы отключили все плагины и переключились на тему Twenty Nineteen, стоит проверить наличие кастомного кода в файлах
functions.php, который может влиять на поведение ссылок. -
Хранение в базе данных: Как мы видели в вашем описании ситуации, некоторые плагины могут сохранять данные в кодированном формате. Это может затруднить доступ к URL во время рендеринга и привести к их автоматическому обновлению на основании хранимых значений. Если URL-адреса закодированы и не могут быть изменены стандартными средствами WordPress, потребуется использовать другие методы, такие как WP-CLI или специализированные плагины для массовой замены содержимого.
Рекомендации по решению проблемы
-
Проверьте
wp_options: Убедитесь, что значения полейsiteurlиhomeв вашей таблицеwp_optionsверно установлены на ваш живой адрес без префикса staging. Это можно сделать с помощью административной панели или напрямую через phpMyAdmin. -
Используйте относительные ссылки: Если возможно, рекомендуется использовать относительные пути вместо абсолютных URLs. Это уменьшает вероятность возникновения таких проблем, как у вас. Например, вместо
http://example.com/daily-specials, используйте/daily-specials. Это также поможет избежать потенциальных проблем с безопасностью. -
Проверка кода плагинов: Просмотрите код используемых вами плагинов и тем на наличие нестандартной обработки URL-адресов. Рассмотрите возможность поиска по документам плагинов для выявления конфигураций или фильтров, которые могут влиять на поведение ссылок.
-
Использование Better Search Replace: Если ссылки уже были сохранены с префиксом staging, рассмотрите использование плагина Better Search Replace для массовой замены URL-адресов в контенте страниц и постов.
Заключение
Ваша ситуация с переписыванием URL на тестовом сайте WordPress может быть сложной и иметь несколько аспектов. Однако, с учётом предложенных шагов по диагностике и решению, вы сможете исправить это поведение и восстановить корректные ссылки на страницах вашего сайта. Если проблема продолжается, возможно, стоит обратиться к специалисту по WordPress или технической поддержке хостинга для более глубокого анализа проблемы.