Всем привет! Вопрос немного не конкретно по Yii2, а скорее о организации работы. Вопрос в том как сделать копию сайта для отладки и чтобы не навредить сео? Т.е. есть боевой сайт (vps), есть локальная среда разработки, хочу развернуть еще сайт копию, чтобы были доступны инструменты типа https://pagespeed.web.dev/ и т.д. Кто какие схемы применяет, поделитесь?
Добрый день! В своих проектах я дублирую файлы сайт в поддиректории test и demo, tеsт только для разработки, dемо для обучения клиентов. В dемо, клиент может, например, попробовать забронировать отель или сделать оплату по кредитной карте без риска потерять деньги (доступ только к sandbox сервисов). Ключи и пароли для доступа к test (sandbox) и live environment вебсервисов и платёжных систем применяются исходя из того из какой поддиректории вызываются скрипты. Для test(demo) и live environment поддерживаются две базы данных с одинаковой структурой, но с разным наполнением. Например, список отелей доступных для бронирования в test environment, экспортируемый из вебсервисов, значительно урезан по сравнению live environment (на страну, несколько городов и несколько отелей в городе). БД для test environment доступна для скриптов из поддиректорий test и demo. Удачи!
Чтобы поисковые краулеры игнорировали ваш демо-сайт, есть robots.txt. Конечно этот отладочный сайт не должен обращаться к реальным продакшн службам. Только к песочницам или вообще к заглушкам, если песочниц нет. Это вроде бы очевидно, но не лишне перепроверить, а потом еще раз ))) На уровне скриптов демо-сайт должен быть одинаковым с реальным рабочим: с той же ветки VCS будет разворачиваться. Я бы не заморачивался с под-директориями внутри одного хоста, а отвёл бы отдельный корень сайта и раздел <VirtualHost> (Apache) или server {} (nginx).Так всё будет чище и более подконтрольно. Это вообще должно быть твёрдым правилом: конфигурация должна быть прописана в отдельном файле! (т.е. все пароли, ключи и адреса сторонних служб не захардкодены, а хранятся в отдельном файле (.env) а тот явным образом добавлен в .gitignore если у вас git! Тогда не будет причин каждый раз править что-то ручками после развёртывания и досадных проколов. Ну а отличающийся robots.txt для разных установок можно реализовать через настройки веб-сервера.
У меня был опыт работы с десятком демо-сайтов. В фирме, где я работал, был такой рабочий процесс, что для крупных новых фишек были отдлельные сайты, связанные с фича-ветками репозитория. Лайфхак: Если надо было спрятать демо-сайт от публичного доступа, виртуальных хост настраивался так чтобы отвечал на фиктивное имя домена. Члены команды могли прописать это соответствие IP - домен в локальных /etc/hosts и открывали его без проблем. А случайно туда никто не мог заглянуть. --- Добавлено --- Ну так давайте перенесем его в другой раздел. "Настройка веб сервера", как мне кажется, подходит.
Или прямо в код вывода роботс заложить, например всегда выводить заглушку для поддомена test или др. подобного. --- Добавлено --- Главное, чтобы не было www.test.site.ru (или всегда был первоочередной редирект на без www) --- Добавлено --- Если чЁ, заглушка роботс примерно такая (взял первую попавшуюся реальную заглушку): Код (Text): User-Agent: * Disallow: /
@miketomlin всё так. Только заострю внимание на нюансе: мы хотим всё кроме .env хранить в git, в т.ч. robots.txt и имя домена нигде не хардкодить. А также использовать для прода и демо одну и ту же ветку репозитория. Вроде бы здесь конфликт — потому то robots нужен разный для прода и демо (или нескольких продов и нескольких демо). Такое приходит на ум: а) Можно в настройках вебсервера демо сделать специальное правило для /robot.txt Код (Text): location ~ /robots.txt { rewrite ^ /robots.demo.txt; } б) Или, если у нас деплой автоматизирован, добавить команду копирования robot.demo.txt поверх robots.txt в) Или отдавать robots не как статику, а через php: сделать маршрут для него и обработчик, типа PHP: include config('environment') === 'production' ? 'robots.prod.txt' : 'robots.demo.txt'; Тогда в сорцах под контролем версий у нас всё чётенько: вот роботс для прода, а вот для не-прода. И без ручного труда при каждом деплое!