- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Переехал на новый VPS. Сам сайт работает, но в Админке Вордпресса проблемы.
Стоят стандартные и распространенные плагины Yoast SEO и BackWPup
1. Если в Админке зайти в плагин BackWPup и перейти в настройки конкретного задания по созданию бэкапа, то там можно увидеть отображенные старые пути к папкам, которые соответствуют старому хостингу, типа: /var/www/u45465445/data/www/мойсайт/wp-content В самих настройках плагина эти пути изменить на новые нельзя. Переустановить плагин конечно можно, но сайтов штук десять и в каждом по 5 настроенных вариантов бэкапа. Очень лень заново их настраивать.
2. С плагином Yoast SEO вообще плохо. При попытке зайти в меню Админки в "Записи" и "Страницы" открывает пустую страницу с ошибкой в тексте которой видна ссылка на плагин и опять же строчка с путем к папкам на старом хостинге. Если первый плагин еще как-то можно переустановить, потратив время на настройку, то при переустановке (хотя правда я только при деактивации смотрел... может при переустановке и нормально будет, но сейчас не могу проверить) этого плагина слетают все прописанные руками description и тайтлы (которые вводились в специальные поля плагина)
Подскажите где хранятся настройки этих плагинов? В самой базе по поиску "u45465445" (имя пользователя на старом хостинге) записей нет. Видимо где-то в файлах плагинов или еще где?
Не посоветуете куда копать? И вообще странно - плагины очень распространенные, переезжает с места на место фигова туча криворукого народу, а нагуглить ничего не удалось.
Сделать бэкап БД средствами хостера. Сделать бэкап файлов сайта. Скачать на комп. Разархивировать и то и другое в новые пустые папки. Открыть файл БД и Notepad++ найти искомую фразу и заменить на нужную. Открыть NotePad++ и пакетным поиском с автозаменой найти во всех текстовых файлах сайта искомую фразу и заменить ее на нужную. Учесть, что текстовые файлы - это не только .txt? но и html, js, xml и т. д. Запаковать БД и экспортировать ее на место старой. Залить файлы сайта на сервер с автозаменой старых на отредактированные.
Проверить не побились ли файлы при заливке. Проверить права на папки и файлы. Проверить все ли работает как надо.
Всё.
Открыть NotePad++ и пакетным поиском с автозаменой найти во всех текстовых файлах
В базе не было этих строк, а что в NotePad можно пакетным поиском сразу в нескольких файлах искать - не знал. Учту на будущее. Спасибо.
А по проблеме - проще решилось. Удалил плагины, а не просто деактивировал и установил заново. Старые пути заменились на новые. Вроде все работает.
можно пакетным поиском сразу в нескольких файлах искать - не знал. Учту на будущее. Спасибо.
Можно:
Поиск - Найти - Найти в файлах:
Фильтры - Ваш фильтр.
Бэкапы скачанные на комп - сделайте их копии на случай форс-мажора. И сохраните в другом месте.
И еще скажу такую вещь: при пакетной автозамене вообще чего-то - откатить\вернуть потомпрежние значения нельзя никак. Если неправильно выставите фильтр - он может заменить к примеру что-то и в тех файлах, которые не нужно трогать. Например в графических - как итог покорежит все изображения в папке где лежат редактируемые файлы разных расширений.
Бэкапы скачанные на комп - сделайте их копии на случай форс-мажора. И сохраните в другом месте.
Ага. Я на Dropbox террабайтный тариф взял и настроил со всех сайтов еджедневное автоматическое архивирование и ручное на Dropbox и на сервер еще. Чуть позже еще на одно облако настрою на всякий случай автоматическое. BackWPup - удобный плагин для этого. Перед каждым чихом бэкап делаю.
Пару лет назад был какой-то плагин, который исправляет это все на автомате, нужно было запустить только секретную ссылку. Не вспомню, к сожалению да и не знаю есть ли такой сейчас.
А вот еще вопрос, раз пошла такая пьянка с утра пораньше:
Плагин WP Super Cache, если выбрать вариант доставки кэша "Эксперт" (с использованием функции mod_rewrite), делает вставку в файл .htaccess:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
#If you serve pages from behind a proxy you may want to change 'RewriteCond %{HTTPS} on' to something more sensible
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz" [L]
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz" [L]
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html" [L]
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html" [L]
</IfModule>
# END WPSuperCache
Но в в файле .htaccess уже есть <IfModule mod_rewrite.c>, который там был со времен царя Гороха:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Они не конфликтуют? И не отменяет старый кусок кода, тот который сформировал плагин? Может старый почикать? Или меня опять не туда понесло?
Этих модулей может быть несколько штук и каждый выполняет свою функцию, потому они и прописываются в модульной оболочке. Чем меньше будете "химичить" с htaccess , тем меньше создадите себе проблем. Не мешайте сайту работать :)
war357159, чем выше стоит в хтаксесс блок условий - тем выше его приоритет выполнения.
И если что вы можете провести эксперимент закомментировав кусок кода в хтаксесс, который хотите проверить. Заглючит - откатите изменения.