Intereting Posts
Получить все wp_users сортировать по metakey Опубликовать данные в отдельных div с добавочным классом с помощью WP_Query WP_Query внутри существующего wp_query останавливает следующую запись, показывающую Вы должны войти в систему или зарегистрироваться. добавление id в the_post_thumbnail Случайный 404 на любой странице Страница не найдена таксономия пользовательский тип сообщения Все липкие сообщения возвращаются в пользовательском запросе Использование различной wp_nav_menu theme_location на основе идентификатора страницы (или родительского идентификатора) Как я могу просто получить контент внутри короткого кода или просто снаружи Фильтр пользовательских плагинов Ошибка 404 ошибок с многоязычными страницами постоянной ссылки Ограничить регистрацию определенных ролей по домену пользовательский класс walker для собственного меню? Как сделать аутентификацию WordPress с родительского сайта

wp_posts – обновление руководства

Привет, пожалуйста, извините, если об этом ответили раньше, но нам действительно нужно убедиться.

Мы создали веб-сайт под своим доменом, а затем переместили его на сайт клиента. Мы выполнили несколько sql-запросов в db, чтобы обновить новый URL-адрес, но когда мы ищем наше доменное имя в базе данных, получаем: 600+ совпадений внутри таблицы wp_posts (в основном, изменения, но есть вложения и сообщения) ,

Мы читаем в кодексе WP, что мы не должны обновлять этот столбец, но мы не совсем уверены, как это повлияет на сайт, если мы это сделаем. Файлы все еще находятся в нашем домене, и нам нужно их удалить, но мы думаем, что, поскольку в базе данных, которые называют наш домен, все еще есть экземпляры, что-то может сломаться, если мы это сделаем.

Если кто-то может предоставить больше информации об использовании руководства и любых предложениях в вышеуказанной ситуации, мы будем благодарны.

заранее спасибо

GUID не должен использоваться для создания каких-либо URL-адресов для сайта (см. Ниже), поэтому не должно быть вреда, чтобы оставить их такими, какие они есть … если только какой-то плохо разработанный плагин не решает, что GUID – отличный ярлык для получения URL-адреса.

Что такое GUID, является глобально уникальным идентификатором – глобальным, как в «во всем пространстве и времени». Читатели каналов используют его для отслеживания того, был ли элемент отображаемым или нет. Если вы измените GUID, все будет выглядеть лучше, чем читатель, и все ваши подписчики будут затоплены, потенциально. Я хочу, чтобы WordPress заменил какой-то другой формат для этого поля – может быть, хэш – избежать этого: «Это URL?» спутанность сознания. Это не URL-адрес … ну, кроме файлов вложений, которые … o_0

Одним из исключений является среда для вложений: вложенные медиа-места хранятся в URL-адресе в GUID. Если необходимо изменить папку загрузки по умолчанию в другое место, то URL-адрес медиафайла необходимо будет изменить в столбцах post_content и guid столбцов.

Это все в коде WordPress . Я не знаю, изменилось ли в недавних выпусках что-либо, что Codex не догнал.

Вы должны, как описано, изменить GUID вложений вложений.

Теперь, если ваш сайт до сих пор находился на сервере разработки и никогда публично не публиковал свои фиды, не должно быть никаких проблем с изменением всех GUID. Никакие читатели кормов не видели контент, и, следовательно, ни один из них не должен отслеживать что-либо. Я бы сказал, что Codex должен указать, что не изменение GUID применяется для перехода из одного живого домена в другой и не является проблемой при переходе с частного сервера (localhost) на общедоступный.

Если это был клиентский сайт на моем dev-сервере, который я переместил в живой домен, я бы сменил GUID. Это должно помочь избежать недоумения в будущем, если кто-то начнет копаться в базе данных.