в настройках сайта домен как прописан?
То есть нужно убрать редирект? Сайт просто переехал с 1 домена на 2-й?
Если так, то делали в БД такие SQL-запросы?
UPDATE wp_options SET option_value = REPLACE(option_value, ‘http://olddomain.ru’, ‘http://newdomain.ru’) WHERE option_name = ‘home’ OR option_name = ‘siteurl’;
UPDATE wp_posts SET guid = REPLACE(guid, ‘http://olddomain.ru’,’http://newdomain.ru’);
UPDATE wp_posts SET post_content = REPLACE(post_content, ‘http://olddomain.ru’, ‘http://newdomain.ru’);
Большинство случаев здесь описана — https://web-optimizator.com/301-redirekt-htaccess/ если ваш случай уникальный напишите что не получается?
Модератор
Yui
(@fierevere)
永子
altkmv
(@altkmv)
возможно не зря даже акисмету не нравистся ваш далеко не полезный совет
замену в БД лучше производить плагином https://ru.wordpress.org/plugins/better-search-replace/
или его аналогом (без вордпресс) https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
То есть по Вашему мнению плагин будет использовать другие команды для работы с БД?) Вы серьезно? Если по итогу в базе данных будет происходить замена данных, то человеку дается выбор: либо навешивать +1 плагин, либо применить 3 элементарных запроса, которые не могут поломать сайт (если Вы их смотрели, то, думаю, понимаете о чем я) и произведут нужные замены.
То есть по Вашему мнению плагин будет использовать другие команды для работы с БД?) Вы серьезно?
Серьёзно. Узнайте про сериализованные данные.
Для простоты понимания почитайте хотя бы описание скрипта. Можно через гуглопереводчика. Вполне доступно.
Модератор
Yuri
(@yube)
3 элементарных запроса, которые не могут поломать сайт
Еще как могут. Почитайте про php serialize.
Да, я вижу, что в запросах меняются только две опции, но на самом деле содержащих домен опций может быть гораздо больше.
-
Ответ изменён 6 лет, 8 месяцев назад пользователем
Yuri.
справедливости ради — именно эти запросы ничего не поломают. нет тут сериализованных данных.
справедливости ради — именно эти запросы ничего не поломают. нет тут сериализованных данных.
А если найду? 🙂
Но даже если бы «тут» и не было — они повредят уже тем. что не исправят там где нужно исправить и они есть.
Но даже если бы «тут» и не было — они повредят уже тем. что не исправят там где нужно исправить и они есть.
если это исправление вообще требуется. вы же не знаете, что там у ТС на сайте.
вообще, раз доступ к админке есть, то самое простое исправить там урлы в настройках и без всяких sql-запросов.
то самое простое исправить там урлы в настройках
Абсолютно согласен.
Но с оговоркой, что это ошибка в настройках, а не процедура по смене домена. И тем более смене хостинга.
вы же не знаете, что там у ТС на сайте.
И это ещё одна причина использовать правильные средства, а не 3 SQL запроса.
Вот с одного из тестовых сайтов где встречается домен:
А вот обратите внимание не только на таблицу, но и на экранирование символов.
Вот вам и 3 «универсальных» и «безопасных» запроса.
Вот вам и 3 «универсальных» и «безопасных» запроса.
а каким образом это касается ‘home’ и ‘siteurl’ в wp-options?
так это не полное лечение, а часть его.
при переезде на новым домен я экспортирую базу данных, потом импортирую ее на новом хосте — меняю sql-запросом ‘home’ и ‘siteurl’ — банально ради того, чтобы зайти в админку. захожу в админку — ставлю better search and replace — и уже им меняю старый домен на новый.
конечно, можно прописать новые урлы в wp-config.php или воспользоваться тошнотворным по качеству ui скриптом для замены урлов в дампе базы данных — но мне так быстрее и удобнее.
замена sql-запросом ‘home’ и ‘siteurl’ решает главную задачу — возможность зайти в админку. поэтому говорить, что это плохое решение не стоит — для многих случаев это идеальное решение. как, например, ошибочная смена домена админом в настройках сайта.
замена sql-запросом ‘home’ и ‘siteurl’ решает главную задачу — возможность зайти в админку.
Вам опять поспорить неймётся или же может не нужно вводить в людей заблуждение, а предлагать решать задачи правильно?
Разрушить стену тоже решает задачу «попасть в дом» если ключи потеряны. Но правильнее воспользоваться изготовлением ключей.
И для замены 2х полей не зачем и строить SQL-запросы. Можно просто поменять в базе через ПМА или ещё проще — через конфиг одним из 2х способов.
НО!!! Мы не знаем причин изменения адреса мы даже не знаем может ли войти ТС в админку (судя по всему да, раз об этом не сказано) и уже поэтому не зачем советовать опасные решения.
