Студиям разработки сайтов и мобильных приложений знаком тип клиента, который уверен, что его продукт будет идеален, и ничто — ни время, ни катаклизмы — не может нарушить его работу. Мы в ADCI Solutions и сами хотели бы, чтобы так было, но есть обстоятельства выше нас.

И вот близкий каждому пример.

В 2017 году компания Adobe анонсировала прекращение поддержки Flash Player. У владельцев сайтов и мобильных приложений, которые до сих пор используют Flash для проигрывания видео и музыки, осталось не так много времени на то, чтобы перевести функциональность работы сайта с мультимедиа-файлами на HTML5 или WebGL. До конца 2020 года, если быть точным. Если вы пользуетесь Google Chrome, то с той или иной периодичностью видите это предупреждение, когда запускаете браузер.

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

Очень жаль, что не все программные продукты, к которым относится и ваш Drupal-сайт, предупреждают нас так же, как Google Chrome. И тем более жаль, что устаревшая технология не подменяется её актуальной альтернативой автоматически. Устаревшие версии библиотек, на которых работает ядро Dupal, не получают поддержку безопасности и превращаются в источник уязвимостей, которые уже никто не будет чинить. А если будет уязвима библиотека, то будет уязвим и сайт, работающий на старой версии Drupal. Поэтому, чтобы предупредить отказ в работе сайта или важной его части, обеспечить безопасность своих данных и данных пользователей, вы должны закладывать бюджет на техобслуживание, апгрейд Drupal до свежей версии и поддержку.

Как это касается владельцев сайтов на Drupal

Наши советы будут ещё более актуальными потому, что 3 июня 2020 года вышла CMS Drupal 9, поэтому пора проверять, соответствуют ли ей модули, работающие под Drupal 8.

Drupal не был бы собой, если бы не сторонние библиотеки, на которых он работает: jQuery, Composer, Symfony, Twig, Guzzle и другие. Когда разработчики этих библиотек решают больше не поддерживать старую версию и переходят на новую, это влияет на работу всего Drupal и сайтов, на которых он построен.

Например, Symfony 3 не будет поддерживаться разработчиками с ноября 2021 года, а Symfony 4 не будет иметь с предшественником ничего общего. Это означает, что ошибки в работе Symfony 3 на сайтах с версией Drupal 8 останутся неисправленными и сайты на Drupal 8 станут необратимо плохо работать. Мораль: у вас есть полтора года на миграцию на Drupal 9, и вы как владелец сайта должны об этом позаботиться. Вот о каких вещах мы будем говорить, а вы вспомните это в урочный час.

Что и как часто нужно проверять

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

Перевод сайта на новую версию и на поддержку безопасности

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

Между датой релиза новой версии и окончанием поддержки старой версии нужно готовиться к обновлению до актуальной версии, чтобы обеспечить сайт не только свежей функциональностью, но и безопасной работой. Каждый минорный релиз или релиз безопасности обусловлен тем, что команда разработчиков Drupal поправила баги. То есть если багов не найдено или их пока что исправляют, то релиза не будет.

Существует понятие релизного окна (release window). Это промежуток времени, в котором должна выйти новая минорная версия с исправленными багами, или патч-версия. Такая версия релизится не чаще раза в месяц, в первую среду. Но могут быть исключения, когда баги настолько критичные, что ждать запланированную минорную версию невозможно, и выпускается внеочередная. Это может происходить даже раз в неделю.

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

Релизы с исправлениями в ядре Drupal обычно так часто не происходят — ими занимается отдельная команда, которая планирует релизы с комплексными исправлениями.

В случае минорных версий ядра Drupal периодичность более-менее стабильная: раз в полгода.
Подробнее о релизных циклах читайте в заметке Drupal core release cycle: major, minor and patch releases.

Продление SSL-сертификатов в контексте безопасности сайта подразумевается по умолчанию. Это делается автоматически или вручную за 2 недели до истечения срока действия сертификата.

Обновление версии PHP

В данный момент поддерживаются версии PHP 7.2, 7.3 и 7.4. Но раз в год одна из версий становится неактуальной. Так, поддержка версии 7.2 прекратится 1 декабря 2020.

Сайтам, работающим на Drupal 9, требуется версия PHP от 7.3 и выше.

Обновление версии PHP может потребовать исправлений в кастомном коде, патчей для каких-нибудь непопулярных модулей и т. д.

Проверка скорости загрузки сайта

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

Раз в 5–6 месяцев прогоняйте сайт через Google PageSpeed и оптимизируйте его работу. На помощь вам придут JCH Optimize, WebP by Bart Vanhoutte, ImageAPI Optimize WebP, ImageMagick, TinyPNG, Advanced CSS/JS Aggregation, Minify Source HTML, Minify JS.

Соответствие принципам доступности

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

ADCI Solutions выпустила статью о доступности в трёх частях: в первой мы даём определения основным терминам из этой области, во второй сравниваем дизайн доступной и недоступной страницы сайта, а в третьей рассказываем о законодательной стороне вопроса.

В Drupal доступность сайта предусмотрена по умолчанию. CMS располагает:

• специальными HTML-элементами (например, языковыми тегами),
• описанием изображений и альтернативным текстом,
• автоматическими метками для элементов формы,
• использованием заголовков для навигации по странице,
• контролируемой последовательностью табуляции, благодаря чему пользователи со слабым зрением и пользователи, не способные управлять мышкой, могут получить доступ ко всем элементам страницы.

В той или иной части света за несоблюдение правил доступности закон суров по-разному. Но в основном судебные дела заводятся в отношении государственных учреждений и тех компаний, которые работают с ними. Подробнее о том, на чьи сайты и в каких странах распространяются требования по доступности и сколько положено взыскать с нарушителей, можно почитать в статье от Web Standarts.

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

Отслеживание ошибок и сбоев через Google Analytics

Google Analytics не только собирает статистику посещаемости сайтов и действий пользователей. Библиотека analytics.js может, кроме прочего, мониторить неправильную работу JavaScript-кода на сайте и отправлять отчёты. Эти отчёты чаще всего говорят о том, что на стороне пользователя что-то не работает, так что лучше их избегать и своевременно чинить.
Просматривайте аналитику на предмет новых ошибок раз в месяц и каждый раз в течение двух дней — после деплоя кода.

Актуальность кодовой базы

В проекте не должно быть легаси-кода — старого кода, который больше не поддерживается и не обновляется. Программирование развивается, меняются стандарты языков, и те задачи, что решались элегантно вчера, сегодня требуют ещё более элегантных решений. Какое-то время код, написанный по старым канонам, будет работать, но однажды это закончится. Проверить, есть ли в модулях устаревший код, разработчики могут с помощью утилиты drupal-check, а если вы не программист, а простой владелец сайта, то модуль Upgrade Status интерпретирует и упакует отчёт из drupal-check в благообразный вид.

Проверяйте кастомный код при каждом обновлении сайта, кроме обновлений безопасности.
До ноября 2021 года у вас есть время обновить код и перейти на Drupal 9. Старый код будет помечен как @deprecated. API, которые подлежат удалению, собраны на этой странице.

Рефакторинг фронтенда

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

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

SEO

На базовом уровне продвижение сайтов на Drupal в поисковых системах ничем не отличается от продвижения других. Поисковики предъявляют одинаковые требования всем сайтам, а именно требуют наличия файла robots.txt, метатегов, 404 страниц, редиректа, хлебных крошек, отсутствия дублей страниц и битых ссылок и т. п.

Но без дополнительных плагинов и модулей, кроме тех, которые идут из коробки, SEO не будет считаться полноценным. Чтобы закрыть все задачи по поисковой оптимизации, не помешают как минимум такие модули, как Metatag, Custom filter, Search 404, SEO Checklist, Easy Breadcrumb, Pathauto, XML Sitemap. Держать их в актуальном состоянии — задача разработчиков. Делать проверку лучше всего раз в 3 месяца.

Проверка функциональности сайта, или почему клиенту студии тоже нужно быть немного тестировщиком

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

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

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

Проверять работу сайта на соответствие ожиданиям и целям лучше после каждого изменения, а 1–2 раза в месяц стоит предлагать доработки, отталкиваясь от изменений в бизнес-процессах.

Особое обращение к владельцам eCommerce-сайтов

Что делать, если продаж нет или хочется больше? Собирайте статистику и ищите места, в которых посетители сайта уходят с сайта и не доводят покупку до конца. Стройте гипотезы, как это можно исправить, и проводите A/B тестирования каждые пару месяцев, чтобы их проверять. Делать это лучше постоянно, как минимум раз в месяц.

Если ваш магазин интегрирован с сервисами доставки (CDEK, Boxberry и т. п.), проверяйте их API на актуальность — иногда он меняется без уведомления подключенных клиентов.

Чеклист

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

• 1 раз в месяц, первая среда месяца — обновление патч-версии Drupal с исправленными багами. Может быть чаще, зависит от критичности багов;
• 1 раз в месяц, третья среда месяца — релизы безопасности в модулях, поддерживаемых сообществом;
• 1 раз в 6 месяцев (начало июня и начало декабря) — обновление минорной версии ядра Drupal;
• за 2 недели до истечения срока действия сертификата, автоматически или вручную — продление SSL-сертификата;
• 1 раз в год — обновление минорной версии PHP;
• 1 раз в 5–6 месяцев — оптимизация по Google PageSpeed;
• 1 раз в 3–6 месяцев — соответствие принципам доступности;
• 1 раз в 3 месяца — SEO;
• 1 раз в 1 месяц и каждый раз в течение 2 дней после деплоя — отслеживание ошибок через Google Analytics;
• каждый раз при обновлении сайта — проверка кастомного кода;
• 1 раз в 6 месяцев — рефакторинг фронтенда;
• с периодичностью обновления сайта — проверка функциональности сайта клиентом.

Техобслуживание сайтов на WordPress: на что обратить внимание

Сайты, страницы которых созданы на разных CMS, например, на Drupal и WordPress — не редкость. Поэтому мы хотим быстро рассказать, что важно проводить в рамках техобслуживания на WordPress-сайтах:

• обновление минорных и патч-версий;
• обновление плагинов, модулей, библиотек, тем;
• обновление версии PHP;
• обновление SSL-сертификатов;
• проверка скорости загрузки сайта по Google PageSpeed и оптимизация;
• улучшения SEO;
• проверка важной функциональности сайта по чеклисту;
• мониторинг ошибок через Google Analytics;
• принципы доступности;
• рефакторинг фронтенда;
• интернет-магазинам: проверка гипотез по оптимизации воронки продаж, актуализация методов доставки;
• проверка функциональности сайта клиентом — с периодичностью обновления сайта.

Заключение

Как видно, техобслуживание сайта ведётся круглый год. Оно затрагивает столько всего, сколько владельцы сайтов не могут себе позволить отследить самостоятельно. Снимите с себя груз технических проблем и передайте его команде ADCI Solutions, которая уже 13 лет разрабатывает и поддерживает Drupal-сайты на профессиональной основе.

В рамках техобслуживания мы берём на себя заботу о таких моментах, как:

• контроль за работой компонентов и модулей сайта,
• поддержка актуальности кодовой базы (апдейты модулей и ядра),
• разработка и оптимизация модулей,
• удаление вирусов и вредоносного или неработающего кода,
• подбор хостинга и взаимодействие сайта с ним,
• перенос сайта на новый сервер,
• резервное копирование сайта,
• миграция сайта на новую версию CMS,
• редизайн,
• новая функциональность,
• установка security-апдейтов,
• оптимизация по Google PageSpeed,
• SEO

и многом другом. Напишите нам: hello@adcillc.com.
Подписывайтесь на наш Medium-блог, а также следите за нами на vc.ru, в инстаграме и ВКонтакте.