XAMPP for Linux: еще о зеркалировании...

/ Просмотров: 2290

Один из комментаторов цикла постов о XAMPP обратил внимание на проблему доменных суффиксов.

Дело в том, что большинство пишущих о XAMPP (и я тоже) рекомендуют применять для виртуальных хостов фиктивные, не существующие в интернете доменные суффиксы, например, .dev вместо .ru (.com, .org, net и т.п.) Смысл в этом есть, он, имхо, даже интуитивно понятен, поэтому рассусоливать на эту тему не будем. Но возникает проблема.

Предположим, мы развернули на XAMPP сайт mysite.dev, отработали его и теперь хотим перенести его на реальный боевой сервер в сети. Однако ссылки-то внутри сайта с суффиксом .dev, а не .ru. Просто перенеся сайт на доменное имя mysite.ru, мы получим массу нерабочих ссылок, неоткрывающихся картинок и т.д. и т.п.

Для тех, кто хорошо знает MySQL, синтаксис SQL-запросов и команд, а также устройство базы своего движка, вопроса тут, как я понимаю, вообще никакого нет. А нам-то, бедным хрестьянам, как быть, ежели мы во всем этом не то чтобы очень?!

Выход, однако, есть, и даже не один.

Внимание!   Перед всеми манипуляциями с базами/дампами баз данных обязательно делайте бэкапы! Даже если применяете "неразрушающие" методы, даже если уверены, что просто не можете ошибиться (вы заблуждаетесь, уверяю вас).

Известно, что дамп базы данных – это текстовый файл, вполне доступный для правки в любом текстовом редакторе. Напрашивается простейшее решение: открыть дамп базы (назовем его для примера dump_my_base.sql) в виме, Gedit'e, Geany, KomodoEdit или что вы предпочитаете, и произвести элементарную операцию "найти и заменить". А можно обойтись и потоковым редактором sed, к примеру, так (предварительно зайдя в каталог с дампом):

sed 's+mysite.dev+mysite.ru+g' dump_my_base.sql > dump_my_base_2.sql

В результате мы получим исправленный дамп dump_my_base_2.sql и при этом сохраним исходный.

Описанное (как с текстовым редактором, так и с sed) было опробовано мной, так сказать, на своей шкуре и полностью оправдалось.

Конкретно: я довольно долго не синхронизировал свой сайт с зеркалом на XAMPP, последнее сильно устарело, и, наконец, это стало действовать мне на нервы и даже реально мешать в работе. Сделал бэкап реального сайта и проделал операции, описанные тут: заменил на виртуальном хосте все файлы на файлы с реального сайта, затем заменил содержимое базы с помощью Sypex Dumper (напомню, если делать это вручную, импортом в phpMyAdmin, лучше предварительно удалить все содержимое базы, чтобы не нарваться на ошибку 1062, хотя некоторые предпочитают более сложный путь; если же вы применяете Sypex Dumper для импорта, то достаточно просто выставить REPLACE в стратегии восстановления), перезапустил XAMPP и получил актуальное, новенькое, чистенькое заркало... да? Хренушки. Пока виртуальный сайт-зеркало имеет возможность втихаря подсасывать из интернета, с сервера основного сайта, картинки, переходить туда по внутренним ссылкам и т.д., всё выглядит якобы хорошо. Но стóит отключить машину от интернета, как сразу станет ясно, кто есть ху.

Вот тут я и применил вышеописанную идею: взял дамп базы (не имеет значения, откуда мы его возьмем, экспортом из phpMyAdmin действующего сайта или "отберем" у Sypex Dumper) и заменил все ссылки типа mysite.ru на mysite.dev. Импортировал исправленный дамп через phpMyAdmin на XAMPP'e, перезапустил последний и получил действительное зеркало, полностью автономное от реального сайта.

И хотя я зеркалировал сайт, так сказать, наоборот, "снаружи внутрь", не вижу никаких причин, чтобы это не сработало при "нормальном направлении", т.е. при развертывании сайта, созданного на XAMPP, на реальном хостинге.

В заключение несколько оговорок.

Во-1-х, речь у нас о сравнительно небольших базах, десятки-сотни килобайт, в крайнем случае немногие мегабайты. Как поведет себя тот или иной редактор при обработке файла в сотни мегабайт – вопрос. Думаю, по мере увеличения базы всё более предпочтительным будет sed.

Во-2-х, я упомянул в начале о том, что описанный выход – не единственный. Действительно, вы можете без труда нагуглить решения на php (вот пример) или sql (еще пример). Однако, имхо, для нашей скромной задачи – замены внутренних ссылок – вполне достаточно вышеописанного.

И в-3-х, всё это касается сайтов на базах данных. А что насчет так называемых статических сайтов, без БД или на текстовых базах данных?
Как это ни парадоксально на первый взгляд, тут, возможно, придется повозиться немного побольше, хотя для тех, кто более-менее владеет bash и умеет накропать простенький цикл с регекспами, также никаких особенных затруднений не предвидится. Ну придется потратить на это с полчаса, – так ведь не каждый день приходится заниматься зеркалированием! И потом, как я и отмечал в ответе на вышеупомянутый коммент, преимущества абсолютной адресации по меньшей мере дискуссионны, а при относительной – сама проблема с заменой ссылок не возникает.

Оставьте комментарий

Комментарий будет опубликован после проверки

(обязательно)