Подскажите, пожалуйста, как удобнее всего будет проверять что-то новое перед внедрением на «живом» сайте, чтобы не беспокоить юзеров?
На ум приходит только заливать его копию на другой сервер и вписывать себе в hosts ip, но может есть более правильные способы…
SeVlad
Junost : На ум приходит только заливать его копию на другой сервер и вписывать себе в hosts ip, но может есть более правильные способы…
Да, но на другой сервер несколько не правильно, если это касается технических фич. Лучше на том же, но на другом домене.
S_E_O
SeVlad #:
Да, но на другой сервер несколько не правильно, если это касается технических фич. Лучше на том же, но на другом домене.
Только от индексации лучше закрыть.
SeVlad
S_E_O #: Только от индексации лучше закрыть.
Само собой 🙂
Но мне показалось, что это ТСу не нужно объяснять, тк он умеет
Junost : вписывать себе в hosts ip,
и может тестить даже на фейковом домене.
Junost
Всем спасибо.
Да, на другом домене на том же сервере было бы попроще, но при простом копи-пасте слетает куча всякого, приходится долго править «ручками», чтобы нормально работало на новом домене.
Наверное, можно заказать скрипт, который в один клик будет удалять существующую копию на тестовом сервере и заливать актуальную…
SeVlad
Junost #: но при простом копи-пасте слетает куча всякого
Значит надо делать не «простой копипаст», а правильную миграцию.
(Если это ВП, то миграцию нужно делать спец. плагинами/скриптами/wpcli)
Junost
SeVlad #:
Значит надо делать не «простой копипаст», а правильную миграцию.
(Если это ВП, то миграцию нужно делать спец. плагинами/скриптами/wpcli)
Да, WordPress .БД — 4гб, файлов на 17гб
Пробовал пару плагинов для миграции, в «2 клика» там тоже ничего не получается, возни прилично.
А нововведения нужно тестировать практически каждый день, тратить кучу времени на правильную миграцию не хочется.
Алеандр
Junost #:
Да, WordPress .БД — 4гб, файлов на 17гб
Пробовал пару плагинов для миграции, в «2 клика» там тоже ничего не получается, возни прилично.
А нововведения нужно тестировать практически каждый день, тратить кучу времени на правильную миграцию не хочется.
А в БД тоже ежедневные изменения структуры? Сомнительно. Если же только файлы, то один раз сделать копию БД для тестов, для файлов данных создать симлинки. Остальные, изменяемые часто файлы переложить в другую папку, назначить другой поддомен на них, закрытый не просто в роботс, но и банальной Basic Auth на уровне апача и с этой копией работать.
Выглядит это так: 2 рядом расположенных папки рабочего домена и поддомена для тестов. Все глобальные картинки, аплоад файлы и тд, чаще всего лежащие в папке upload — их сделать линками, так будет работать, но тягать туда-обратно не придется. Остальные файлы тем — обычные файлы. Файл конфигурации и база — разные. Обычно она нужна только для данных и тестов на ней. Делается копия и из поддомена смотрится в нее.
После тестирования изменений в файлах шаблонов или движка достаточно перезалить эти файлы в соседнюю папку с реальным доменом и ничего мигрировать не нужно.
Конечно, все зависит от сложности постоянных изменений, но для ежедневных очень сомнительно, что переписывается все подряд и сразу много.
garry69
Junost #: Да, WordPress .БД — 4гб, файлов на 17гб
А зачем вам для тестов вся база и все залитые файлы? Закинули все плагины, шаблон, дочерний… в общем все, что составляет функционал сайта. Структуру воссоздали, закрыли от индекса и тестите себя все, что угодно на поддомене.
SeVlad
Junost #: Да, WordPress .БД — 4гб, файлов на 17гб
Файлы рояли не играют. Их как раз можно (даже лучше) «простым копипастом», а вот размер БД.. да, внушительный. Я думаю наверняка его можно уменьшить. Подумай над оптимизацией базы.
Да с такой базой с плагинами наверное будет тяжело (во всяком случае с бесплатными. Платный дубликатор наверняка справится), тогда юзай этот скрипт https://interconnectit.com/products/search-and-replace-for-wordpress-databases/ Или покури wp-cli, если у тебя не «простой шаред».
Database Search and Replace Script in PHP | interconnect/it
interconnectit.com
It has come to our attention that some users have been leaving this script on their servers despite advice to the contrary. Due to the very real dangers, it can present when used that way, we now ask that you complete a form where we make sure you’re aware of these risks in order to receive the download link. Do also carefully read the…
SeVlad
Алеандр #: А в БД тоже ежедневные изменения структуры?
Не структуры, а данных. И не ежедневное, а может быть и ежеминутное.
Но может быть и изменена структура — смотря какие новшевства хочет сделать ТС.
И вообще.. Если не знаешь ВП — лучше почитай https://ru.stackoverflow.com/a/767562
garry69 #: А зачем вам для тестов вся база и все залитые файлы?
А что можно «часть базы» перенести? 🙂
Все файлы конечно может и не понадобятся, но отбирать [не]нужные может быть очень ..мм хлопотно.
Начнем с причин. Глобально, их три. В первую очередь так происходит потому, что все ссылки в базе WordPress хранятся как абсолютные . Например, ссылка на иконку сайта выглядит примерно так: Обратите внимание на то, что даже при простом переводе сайта с на , все ссылки внутри базы надо менять! За использованием абсолютных ссылок в WordPress…
Junost
Подскажите, пожалуйста, как удобнее всего будет проверять что-то новое перед внедрением на «живом» сайте, чтобы не беспокоить юзеров?
На ум приходит только заливать его копию на другой сервер и вписывать себе в hosts ip, но может есть более правильные способы…
SeVlad
На ум приходит только заливать его копию на другой сервер и вписывать себе в hosts ip, но может есть более правильные способы…
Да, но на другой сервер несколько не правильно, если это касается технических фич. Лучше на том же, но на другом домене.
S_E_O
Да, но на другой сервер несколько не правильно, если это касается технических фич. Лучше на том же, но на другом домене.
Только от индексации лучше закрыть.
SeVlad
Только от индексации лучше закрыть.
Само собой 🙂
Но мне показалось, что это ТСу не нужно объяснять, тк он умеет
вписывать себе в hosts ip,
и может тестить даже на фейковом домене.
Junost
Всем спасибо.
Да, на другом домене на том же сервере было бы попроще, но при простом копи-пасте слетает куча всякого, приходится долго править «ручками», чтобы нормально работало на новом домене.
Наверное, можно заказать скрипт, который в один клик будет удалять существующую копию на тестовом сервере и заливать актуальную…
SeVlad
но при простом копи-пасте слетает куча всякого
Значит надо делать не «простой копипаст», а правильную миграцию.
(Если это ВП, то миграцию нужно делать спец. плагинами/скриптами/wpcli)
Junost
Значит надо делать не «простой копипаст», а правильную миграцию.
(Если это ВП, то миграцию нужно делать спец. плагинами/скриптами/wpcli)
Да, WordPress .БД — 4гб, файлов на 17гб
Пробовал пару плагинов для миграции, в «2 клика» там тоже ничего не получается, возни прилично.
А нововведения нужно тестировать практически каждый день, тратить кучу времени на правильную миграцию не хочется.
Алеандр
Да, WordPress .БД — 4гб, файлов на 17гб
Пробовал пару плагинов для миграции, в «2 клика» там тоже ничего не получается, возни прилично.
А нововведения нужно тестировать практически каждый день, тратить кучу времени на правильную миграцию не хочется.
А в БД тоже ежедневные изменения структуры? Сомнительно. Если же только файлы, то один раз сделать копию БД для тестов, для файлов данных создать симлинки. Остальные, изменяемые часто файлы переложить в другую папку, назначить другой поддомен на них, закрытый не просто в роботс, но и банальной Basic Auth на уровне апача и с этой копией работать.
Выглядит это так: 2 рядом расположенных папки рабочего домена и поддомена для тестов. Все глобальные картинки, аплоад файлы и тд, чаще всего лежащие в папке upload — их сделать линками, так будет работать, но тягать туда-обратно не придется. Остальные файлы тем — обычные файлы. Файл конфигурации и база — разные. Обычно она нужна только для данных и тестов на ней. Делается копия и из поддомена смотрится в нее.
После тестирования изменений в файлах шаблонов или движка достаточно перезалить эти файлы в соседнюю папку с реальным доменом и ничего мигрировать не нужно.
Конечно, все зависит от сложности постоянных изменений, но для ежедневных очень сомнительно, что переписывается все подряд и сразу много.
garry69
Да, WordPress .БД — 4гб, файлов на 17гб
А зачем вам для тестов вся база и все залитые файлы? Закинули все плагины, шаблон, дочерний… в общем все, что составляет функционал сайта. Структуру воссоздали, закрыли от индекса и тестите себя все, что угодно на поддомене.
SeVlad
Да, WordPress .БД — 4гб, файлов на 17гб
Файлы рояли не играют. Их как раз можно (даже лучше) «простым копипастом», а вот размер БД.. да, внушительный. Я думаю наверняка его можно уменьшить. Подумай над оптимизацией базы.
Да с такой базой с плагинами наверное будет тяжело (во всяком случае с бесплатными. Платный дубликатор наверняка справится), тогда юзай этот скрипт https://interconnectit.com/products/search-and-replace-for-wordpress-databases/ Или покури wp-cli, если у тебя не «простой шаред».
SeVlad
А в БД тоже ежедневные изменения структуры?
Не структуры, а данных. И не ежедневное, а может быть и ежеминутное.
Но может быть и изменена структура — смотря какие новшевства хочет сделать ТС.
И вообще.. Если не знаешь ВП — лучше почитай https://ru.stackoverflow.com/a/767562
А зачем вам для тестов вся база и все залитые файлы?
А что можно «часть базы» перенести? 🙂
Все файлы конечно может и не понадобятся, но отбирать [не]нужные может быть очень ..мм хлопотно.