Выходим на новые рынки: как мультисайтинг помогает экономить бюджет и время на разработку региональных копий сайта

Для выхода на рынок в другой стране целесообразно создать копию сайта в доменной зоне этого региона и на его языке. Это даёт больше возможностей для продвижения и эффективного маркетинга. Если на первоначальный сайт заложить правильную архитектуру и выбрать подходящую платформу разработки, то создание и развитие региональных копий пройдёт безболезненно. Так выйдет дешевле и быстрее, чем создавать каждую новую версию с нуля.

Разработку сайта можно сравнить со строительством: если изначально всё сделано по уму, то проблем будет минимум. Но если там забили, тут сэкономили, а здесь поленились — итоговый результат придётся постоянно чинить в одном месте, пока он ломается в другом. Для выхода на новые рынки сайт необходимо подготовить.

В этом кейсе речь пойдёт о том, как мы пофиксили неверно выбранное архитектурное решение, которое обернулось для клиента лишними часами разработчиков и дополнительными расходами. Мы расскажем обо всех преимуществах мультисайтинга на Drupal и о том, почему это обязательная тема для тех, кто собирается развивать бизнес в других странах.

С компанией PNEVMOTEH мы сотрудничаем с 2018 года. Это e-commerce проект по продаже строительного оборудования из России. На тот момент у них было два сайта, согласно географии продаж — .ru и .by.

Компания обратилась к нам в Initlab за стандартной поддержкой сайтов. На первых этапах задачи были несложные, поэтому мы спокойно вносили правки параллельно на русскую и белорусскую версии и это не сильно било по бюджету. Но география продаж росла, как и коммерческий успех, поэтому PNEVMOTEH нуждались в третьем сайте — .kz.

Перед нами стояла задача сделать казахскую версию ровно так, как было принято у предыдущих разработчиков: скопировать сайт, перевести и запустить — что мы и сделали. Но в момент завершения проекта стало понятно, что мы лишь множим проблемы:

• базовые задачи теперь нужно делать сразу на трёх сайтах (а в будущем их станет ещё больше);
• все обновления/нововведния придётся вносить также на три сайта;
• уже сейчас нужно учитывать кучу нюансов: это публикуем здесь, а здесь не нужно, здесь нашли проблему, значит она на всех сайтах… И так далее.

Все эти проблемы могло победить готовое решение — мультисайтинг на Drupal. Но на тот момент у клиента были другие приоритеты, поэтому выделить бюджет на внедрение мультисайтинга он был не готов. Так что мы продолжили работать как работали, отложив эту необходимость до лучших времён.

И вот в 2020 году PNEVMOTEH пришёл с задачей, которая дала понять: дольше тянуть нельзя. Нам предстоял редизайн всех сайтов.

Это был самый подходящий момент для внедрения мультисайтинга, потому что теперь он стал не только необходим, но и целесообразен: переносить новый дизайн поочерёдно на три сайта вышло бы дольше и дороже, чем внедрить одно готовое решение. Полный профит: мультисайтинг облегчает нам редизайн и создание новых доменных версий на других языках в будущем, помогает работать дешевле и быстрее, а клиент экономит и получает необходимую фичу.

Мультисайтинг на Drupal — это единый пульт управления всей экосистемой сайтов, готовое решение, которое первая команда внедрять не стала. Почему так случилось, гадать не будем, но в любом случае — это несоблюдение стандартов разработки Drupal. После появления первой копии следовало сразу же заняться мультисайтингом. Но языковые версии просто начали развивать параллельно. Мы ребята не гордые, поэтому просто вернули одну из главных частей бизнеса клиента в правильное русло.

В чём суть мультисайтинга? Drupal — это набор модулей, которые должны быть установлены на сайте и исправно функционировать. И если мы работаем с несколькими копиями сайта отдельно, нам приходится заходить на каждый из них и включать/настраивать/чинить нужный модуль. А это долго и неэффективно. Но у Drupal есть функциональная возможность сделать так, чтобы необходимые модули либо выводились на все сайты одновременно, либо работали только там, где нам нужно. Это и есть мультисайтинг.

Выглядит это как папка с подпапками. В одной подпапке лежат общие для всех сайтов модули + есть подпапка для каждого отдельного сайта — в них мы кладём то, что должно выводиться только на нужной доменной версии.

Проблемы, которые ждут, если решить «не заморачиваться» и пойти путём параллельного развития:

• обновление до новой версии каждого модуля придётся делать и три, и пять, и более раз по количеству сайтов;
• внедрять новый функционал, менять дизайн также по нескольку раз;
• нашли и исправили ошибку в логике — теперь её нужно менять на каждом сайте.

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

У нас в Initlab рабочий процесс устроен так: разработчик делает задачу на локальной копии сайта, затем показывает что получилось на демонстрационной копии, заказчик утверждает правки и итог работы уходит на боевой сайт. И если единичный перенос изменений занимает, к примеру, час, то в случае с несколькими копиями мы умножаем это время на количество сайтов. Соответственно, каждый новый увеличивает количество работы на один пункт. И это не просто затраты по времени — это бюджет клиента.

Возьмём для примера строку копирайта в «подвале» сайта, работающего на тёплом-ламповом Седьмом Drupal. Допустим, на первом сайте она выглядит как © ООО «Рога и Копыта», а на втором — © ЗАО «Копыта и Рога».

Сейчас она прописана в шаблоне следующим образом:

Нам нужно заменить эту строку на переменную. В кастомном модуле добавляем в админку страницу с настройками, и на этапе препроцесса страницы добавляем переменную копирайта, присвоив ей сохраненное в админке значение. Теперь мы можем изменить вывод копирайта в шаблоне на более универсальный:

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

Аналогичная история с модулями. Мы можем поместить модуль в папку, видимую только конкретным сайтом и добавлять необходимую логику или переопределять существующую. Например, у нас в базовой логике есть страница, а мы хотели бы поменять её адрес на другом сайте. Тогда мы описываем переопределение пути в кастомном модуле, видимом только для этого сайта, и получаем нужный результат.

И ещё более понятный пример — методы оплаты. Для сайта из России мы кладем в его подкаталог модули для оплаты через Сбер или Яндекс.Кассу, а для, например, Казахстана, уже другие — с их сервисами оплаты. При этом эти модули видимы в админке только того сайта, для которого они предназначены, и не могут быть ошибочно включены.

Мультисайтинг сокращает время на разработку, сроки внедрения функционала, повышает надёжность правок — разработчику не нужно делать одно и то же несколько раз, а значит меньше шансов, что он ошибётся. И самое главное: появляется возможность потратить освободившееся время (и бюджет) на развитие сайтов и работу над другими задачами.

Примерные этапы внедрения мультисайтинга выглядят следующим образом:

• в первую очередь разработчик проводит рефакторинг сайта, т.е. приводит весь код к стандартам разработки на Drupal;
• затем он выносит весь контент из кода в базу данных;
• выносит логику из темы оформления в модули;
• отделяет общее от частного и выносит частное в папки мультисайтинга.

Помните мы говорили, что отдельное внедрение редизайна обошлось бы дороже? Как раз его мы спокойно внедряли параллельно со всеми этапами мультисайтинга, что и облегчило, и удешевило процесс.

Мультисайтинг не всесилен, поэтому часть задач всё равно делается отдельно:

• контент (страницы доставки, оплаты, график работы, товары, сертификаты и т.д.);
• теги для SEO;
• правила скидок, распродаж и т.д.

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

Наш искренний совет всем владельцам сайтов на Drupal: как только речь заходит о создании доменной копии на другом языке, лучше сразу вложиться в мультисайтинг — это займёт куда меньше времени, чем в нашем случае, и убережёт от множества проблем в будущем.

За 2020 и 2021 год мы добавили ещё четыре версии сайта — .kg .am .uz и .com.ua. Два последних на момент написания статьи находятся в стадии запуска. Только представьте, сколько времени и сил уходило бы на 7 сайтов без мультисайтинга.

Мы не можем дать точных цифр в часах и деньгах, сколько конкретно мы сэкономили клиенту и себе самим. Но за счёт сокращения этих затрат мы смогли направить бюджет на другие полезные функции:

• внедрили тестирование для более стабильной работы всех сайтов;
• постоянно проводим рефакторинг кода (исправляем и делаем его лучше);
• внедряем решения для развития бизнеса клиента (коммерческая тайна, сами понимаете).

Тот же самый бюджет теперь распределяется иначе. Всё меньше задач «замазать», где «течёт», и всё больше работы на масштаб и перспективу.