Эта осень выдалась особо плодовитой на всевозможные «вводные» по части неотложных мер, которые приходилось предпринимать по отношению к сайтам, находящихся под моим присмотром. Например, в середине октября на многих новостных порталах, даже не специализированных, громко прошло сообщение об обнаружении серьезной дыры в системе управления сайтами (CMS) Drupal 7-ой версии, позволяющей выполнять различные несанкционированные запросы к базе данных с непредсказуемыми последствиями (например, на CNews и OpenNet).
Обновить ядро сайта и заткнуть брешь — несложное вроде бы дело, но при выполнении нескольких «если»: если ты можешь сделать это сам или есть кого попросить, если сайтов не слишком много и их конфигурация достаточно стандартна. Наконец, если есть банальная физическая возможность и свободное время сесть за компьютер в нужный момент времени и все это проделать.
Почти сразу после инцидента с нахождением коварной уязвимости в Drupal приходит письмо от хостинг-провайдера одной из наших площадок с сообщением о вынужденном отключении ими для целой группы сайтов PHP-функции, используемой для отправки почты. Причина — неожиданная рассылка спама скриптами-зловредами, непонятно откуда там взявшимися. Скрипты удалось быстро найти и удалить, хостер включил обратно поддержку отправки почты, однако никаких следов своего появления в доступных логах доступа к сайту зловреды не оставили, как бы неявно намекая, что мол «I’ll be back», может быть. Подобный инцидент произошел впервые за много лет и, возможно, был связан с использованием хакерами найденной уязвимости в Drupal на этом сервере.
Другой забавный эпизод. На одном из сайтов под управлением WordPress аккурат 17 ноября вдруг исчезли все ранее отображаемые на нем календари расписаний мероприятий. Начинаем разбираться и выясняется, что Гугл произвел запланированное и неоднократно объявленное в своих онлайн-руководствах для разработчиков аж 3 года назад отключение 2-ой версии API своих календарей и перешел на 3-ю версию Google Calendar API, сменив заодно и формат идентификаторов фидов для календарей. Кто бы еще помнил об этом предупреждении! Разработчики соответствующего плагина для WordPress также оказались не в курсе запланированного Гуглом перехода, разумеется, со всеми вытекающими, а точнее — вылезающими, глюками на сайтах, где этот плагин используется (341 тыс. пользователей). Починили его, правда, довольно быстро, хотя пока и не до конца.
Все вышеперечисленное конечно же делает нескучной жизнь веб-разработчика, однако вряд ли добавит дополнительного энтузиазма владельцам бизнесов, которым просто нужно использовать сайт по своему прямому назначению и как можно меньше отвлекать силы на его техническое обслуживание и исправление неожиданно возникающих «косяков». Поневоле начинаешь возвращаться мыслями к конструкторам сайтов, которые по определению свободны от проблем превышения разрешенной нагрузки на хостинге, необходимости периодического обновления компонентов и обеспечения их совместимости, да и что бы там ни говорили, становятся все лучше и удобнее.
Совсем недавно одному из лучших российских конструкторов сайтов Nethouse, про который я писал в предыдущем посте, исполнилось 3 года. К письму рассылки, приуроченному к юбилейной дате, они приложили впечатляющую статистику роста клиентской базы, усовершенствований сервиса и интеграции с партнерами — другими известными игроками рынка, а также один запоминающийся ролик, в котором Масяня популярно и без обиняков объясняет, почему сайты с собственным хостингом — это зло, и нужно непременно переходить на конструктор сайтов (понятно, какой именно). Несмотря на присущую Масяне категоричность и несбалансированность оценок, в ее «лекции» есть немало правды и здравомыслия…
Предыдущая заметка про Nethouse: Что общего у конструктора сайтов Nethouse и продукции компании Apple