Сайты могут быть созданы как на готовых платформах (WordPress, Tilda, Drupal), так и самописными — когда разработчик (ожидаемо) сам пишет код, который превращается в сайт. В какой-то момент такое мероприятие становится слишком дорогим удовольствием: программист должен городить код на любой, даже самый простой запрос. Готовых решений, как у известных платформ, у самописки нет.
К нам обратились клиенты как раз с таким сайтом. Их задача на тот момент могла вылиться в 200 часов разработки против 50 часов этой же задачи на Drupal. Так мы предложили им миграцию и перспективы развития, но обо всём по порядку.
В этой статье мы расскажем о том, как переносили данные с самописного сайта и проводили миграцию, какие фишки Drupal даёт сайту с множеством контента и какие преимущества дарит переезд на Drupal в принципе.
Клиент и его задача
Наш клиент — «социальная сеть» травматологов, ортопедов и хирургов calcaneus.ru. На их сайте специалисты со всей России публикуют тематические статьи, делятся опытом и общаются. Как мы уже говорили, сайт сделан на чистом коде. Никакой системы управления контентом для админов, никакого привычного движка для простых смертных — онли код.
И по сути, владельцы могли внедрять всё, что угодно. Но докручивать нужный функционал на самописе становилось всё дороже и всё дольше.
Клиент обратился с запросом добавить на сайт календарь событий. Чтобы пользователи могли записываться на онлайн и офлайн-мероприятия, получать уведомления о них и т.д. При оценке мы выяснили, что задача займёт 200 часов, хотя на Drupal под это есть готовые модули. Их не надо писать заново и внедряются они куда быстрее — часов за 50. Плюс разговор с клиентом дал понять, что они планируют дальнейшее развитие и новые функции, которые могут занять куда больше времени. Мы предложили оптимальное решение: переезд на Drupal для экономии времени, сил и денег (эта троица звучит банально, но так и есть).
Контентному сайту нужен Drupal
— У меня есть сайт, который работает, зачем переезжать?
Но мы не мы, если не расскажем про преимущества Drupal.
Оговоримся: на старте сделать самописный сайт было не самым плохим решением, всё по правилам MVP (минимально жизнеспособного продукта): набросать недорогой прототип, проверить работоспособность и спрос. Но как только случился положительный эффект, нужно задуматься о более рациональном развитии.
Наш основной довод для этого клиента был прост: у вас контентный сайт. Несколько тысяч статей, профили пользователей, в перспективе календарь. А Drupal буквально создан для работы с контентом:
- сформировать подборки статей
- внедрить поиск по статьям
- взаимодействовать с воркфлоу: сохранять черновики, модерировать статьи и т.д.
И всё это может сделать мышкой в админке минимально обученный человек, вместо программиста, который полезет в код. Помимо этого:
- массовые операции над пользователями: забанить, дать новый статус;
- инструменты модерации комментариев и контента;
- проще собирать отчёты: сколько комментариев было добавлено за какой-то период;
- в будущем проще внедрять аналитику.
Контентному сайту как воздух необходима система управления контентом, а её не было. Самописка выполняла необходимый минимум, но для нового функционала нужен был программист, который хорошо знает сайт и будет его дописывать.
Этапы работы
Вот в каком порядке мы действовали.
1. Выгрузили из базы данных старого сайта весь контент в отдельные файлы.
2. Создали пустой сайт без контента со всем функционалом, который был на старом сайте.
3. Написали миграцию. Условно пути соответствия между местами откуда мы взяли старые значения и местами, куда нам нужно записать на новом сайте. По всем сущностям на сайте прописывается путь: имя пользователя было здесь, перенести его нужно сюда и т.д. Таким же образом нужно перевести:
- комментарии
- лайки;
- профили пользователей, избранное у пользователей.
Мы впервые проводили работу по миграции пользователей с сохранением паролей. Сложность была в том, что самописный сайт и Drupal имеют разные системы шифрования. Паролей в открытом виде у нас не было, поэтому нам нужно было перекодировать их из одной системы в другую. У нас всё получилось, поэтому все пользователи продолжили пользоваться сайтом под своими учётками.
4. Импортировали контент на сайт. Ещё одна загвоздка: контент был неоднородным. Например, в процессе развития проекта, изменилась система загрузки картинок. Поэтому в части статей картинки хранились одним образом, а в части поновее — другим. При переносе это приходилось учитывать. Так что было достаточно много ручной работы по данным, которые плохо импортировались.
Мы переносили пользователей, статьи, комментарии под статьями, рейтинг статей, избранные статьи, избранные контакты и многое другое.
Также провели большую работу по изменению админки Drupal, чтобы пользователи и редакторы после переноса попали в привычное окружение. Обычно клиентов это не интересует, т.к. с внутренним устройством имеют дело только сотрудники или разработчики. В этом случае на кону стоял комфорт пользователей, поэтому команда дизайнеров, замороченных на юзабилити, развлеклась с переделкой админки Drupal под вид самописной. Привычный друпальный вид остался только для супер-админов, которые кодят.
На этом же этапе мы внедряли календарь событий.
5. Запуск. Мы закрыли старый сайт от записи на три дня, чтобы там не образовался новый контент. Выгрузили заново все файлы, загрузили на наш на пустой сайт, протестировали и запустили. Переключили домен, настроили инфраструктуру, сервер. Подняли копию, чтобы внедрять изменения в будущем.
Бонус: параллельно с переносом, мы сделали небольшой редизайн по просьбе заказчика. Пользователи особо не заметили подмены — их просто разлогинило, а перезашли они на слегка обновлённый сайт.
Итог: сайт на момент написания статьи работает месяц без серьёзных ошибок. Пользователи продолжают заходить, регистрироваться, администраторы публикуют статьи. Жизнь идёт своим чередом.
Выводы и перспективы развития
В дальнейшем заказчик хочет внедрить функционал для продажи онлайн-курсов. Помимо этого, у клиента есть сайт, который развивают параллельно. Его также планируется перенести на Drupal и внедрить мультисайтинг — оставить единую кодовую базу, но с разным контентом, чтобы новые функции внедрялись на второй сайт параллельно.
И это далеко не всё. Но даже учитывая только эти планы на развитие, Drupal обойдётся однозначно дешевле. Второй плюс — надёжность. Все модули, необходимые для развития, у Drupal стабильные, оттестированные, в них меньше багов и ошибок. Кодить новые функции с нуля, это, грубо говоря, изобретать велосипед. Единообразный стандартизированный контент. И никакого насилия.
Добавить комментарий