Джекилл против Друпала, Wordpress и Joomla

1. Почему мы мигрировали из Друпала в Джекилл? Четыре года назад мы перенесли наш сайт и блог в Wordpress....
2. Спектакль
3. Управление конфигурацией
4. Управление версиями контента
5. Стоимость
6. авторинг
7. гибкость
8. Заключение

Почему мы мигрировали из Друпала в Джекилл?

Четыре года назад мы перенесли наш сайт и блог в Wordpress. Я никогда не забуду реакцию, когда мы объявили новости нашей команде. Молчание, быстро сопровождаемое раздражением, обидой и в конечном итоге множеством циничных шуток. Через два года после перехода на Wordpress мы перешли на Drupal. Было много причин, почему Drupal лучше подходил для нас, и на этот раз я был уверен, что команда выстроится в очередь для создания контента. К сожалению, результат был таким же. Обе попытки увенчались успехом с технической точки зрения, но усыновление и взаимодействие так и не начались. Наша проблема? BHW не согласен с аудиторией, на которую ориентированы решения CMS. Наша команда полностью состоит из технического персонала, владеющего HTML и Markdown. Нашим сотрудникам мешают традиционные решения CMS. После двух лет работы на Drupal мы переехали в Джекил , генератор статического сайта. На этот раз реакция была другой.

Чтобы быть ясным, Wordpress и Drupal являются зрелыми системами CMS, которые при правильном проектировании, развертывании и уходе предлагают простые решения для разработки практически для всех. Если вашей команде не нравятся HTML, текстовые редакторы и некоторые базовые средства управления исходным кодом, тогда генератор статического сайта, вероятно, не для вас. В то время как генераторы статических сайтов не готовы заменить традиционные решения CMS, их растущую популярность и количество нельзя игнорировать. Большинство компаний, принимающих сегодня решение по созданию контента, выберут CMS, но многие не учитывают, что вы используете платформу и все, что с этим связано. Слишком легко поверить, что выбор CMS с открытым исходным кодом - это недорогое решение с низким риском. Компании ошибочно полагают, что « бесплатную » CMS с открытым исходным кодом будет легко переключать позже, потому что в конце концов она « бесплатна». Тщательно продумайте, на что вы подписываетесь:

• Безопасность
• Заделка
• Обновления
• Повышение квалификации

Многие из этих усилий требуют хороших советов и рекомендаций от консультантов, чтобы быть безопасными и эффективными. Стоимость неправильного решения выше, чем вы ожидаете, просто потому, что миграции CMS сложны, а ваш ценный контент хранится в базе данных контента и глубоко вложенных каталогах, разбросанных на множество фрагментов. Объединение вашего контента может показаться эпизодом телешоу с командой людей, которые склеивают уничтоженные документы. Небольшая ошибка может означать, что SEO, над которым ваша команда работала так усердно, было потеряно из-за дублированных штрафов за контент, неработающих ссылок или отсутствующих метаданных.

Безопасность

Подумайте о безопасности на мгновение. Популярные системы CMS с открытым исходным кодом основаны на PHP и используют множество плагинов даже для самых простых веб-сайтов. В последнее время было много дискуссий о 75% сайтов PHP имея известные уязвимости. Новые сайты с меньшей вероятностью будут подвержены этим проблемам, что заставляет вас сосредоточиться на самом программном обеспечении CMS. В то время как Drupal и Wordpress тщательно проверяются на наличие уязвимостей, уязвимости всегда проскальзывают и требуют постоянной бдительности в виде исправлений и обновлений. Большинство лучших практик CMS рекомендует использовать как можно меньше плагинов, чтобы уменьшить площадь атаки. Плагины обычно пишутся небольшими командами, исправляются реже и в большинстве систем CMS являются основной точкой входа для атак. Даже если вы потратите время, чтобы опередить эти проблемы, теперь вам приходится сталкиваться с человеческими проблемами, такими как сложность слабых паролей, общие пароли и т. Д. Проблема в любой из этих областей открывает ваш сайт для атаки.

Сравните этот опыт со сгенерированным Jekyll статическим сайтом. Jekyll работает только на рабочей станции и создает статические файлы. Ваш сервер работает только с веб-сервером, файлом конфигурации и содержит ваши статические файлы. Вместо того, чтобы обслуживать динамический контент из систем CMS на основе PHP и их плагинов, вы обслуживаете статические файлы через Nginx или же апаш два самых надежных и тщательно протестированных веб-сервера на планете. Поддержка Nginx или Apache не может быть проще, так как большинство дистрибутивов Linux автоматически обновляют эти два пакета на наличие уязвимостей. Затраты и беспокойство по поводу запуска PHP CMS сводятся практически к нулю.

Как насчет восстановления? Если ваша CMS некоторое время работала, будьте готовы столкнуться с проблемами при установке именно той версии плагинов и программного обеспечения, которая вам нужна, а затем исправлении уязвимости. Если ваш PHP CMS был взломан, вы, вероятно, сталкиваетесь с переустановкой сервера и восстановлением базы данных, включая восстановление файловой системы для ваших образов и других ресурсов. Без последней резервной копии вы потеряете контент и данные. Не стоит недооценивать время и сложность восстановления, и, если вас это беспокоит, попросите команду или поставщика выполнить тест восстановления, чтобы убедиться, что вы подготовлены в случае атаки. Будьте готовы наблюдать, как их лицо падает, когда они рассматривают усилие. Даже если вам повезет и у вас есть резервная копия моментального снимка для восстановления, вам все равно придется вызвать ее и надеяться, что вы сможете найти уязвимость и исправить ее, прежде чем ее снова взломают. Восстановление на Jekyll может быть простым:

• Предоставление новой ВМ
• Установить Nginx
• Разверните ваши файлы

В отличие от PHP CMS, в Jekyll нет шансов на потерю контента или данных, поскольку ваши статические файлы развертываются после сборки на локальной рабочей станции. Благодаря распределенному и размещенному управлению исходным кодом ваш сайт будет в безопасности, даже если вы потеряете доступ к своей рабочей станции. Просто найдите другой компьютер, откройте исходный код, установите jekyll (это установка из командной строки в одну строку) и создайте свой веб-сайт.

Спектакль

Производительность - еще одно преимущество Jekyll по сравнению с PHP CMS. Поиск в Google производительности Drupal или Wordpress покажет множество рекомендаций по подключаемым модулям и прокси-серверам, два из самых популярных - W3TotalCache и Varnish. Даже после использования этих решений, тщательной настройки нашей конфигурации и обновления нашего сервера мы все еще не могли надежно обеспечить ожидаемую производительность. Быстрый поиск покажет те же проблемы производительности, упомянутые в Интернете. Кэширование и прокси-системы используются для преодоления низкой производительности Drupal или Wordpress. Обе базовые системы CMS очень болтливы и выполняют много запросов для отображения одной страницы. Плагины усугубляют ситуацию, выполняя свои собственные запросы. Просмотр типовой страницы может генерировать сотни запросов к базе данных контента. Кэширование - отличный способ обойти эту проблему, но у него есть и свои недостатки. Стратегии кэширования различаются, но вам часто требуется больший сервер с большим объемом оперативной памяти для кэширования вашего сайта. Редактирование отдельных страниц может быть быстрым обновлением кэша, но изменения всего сайта означают, что вам необходимо полностью перестроить весь кэш. На нашем сайте Drupal восстановление всего кэша заняло почти 10 минут, и сайт был в основном непригодным для использования, пока это происходило. Прокси-системы, такие как лак, могут даже кэшироваться на основе HTTP User Agent, что приводит к нескольким копиям веб-сайта для разных устройств и браузеров. Мы использовали метод предварительного кэширования нашего сайта, но если бы мы просто позволяли сайту отображать страницы, которые не попали в кеш, мы увидели бы, что страницы загружаются в течение четырех секунд. Наш переход на Jekyll позволил нам удалить всю эту инфраструктуру и просто использовать Nginx для обслуживания статических файлов - задача, в которой он превосходен. На самом деле это настолько быстро, что мы смогли уменьшить размер нашего виртуального сервера в несколько раз и сэкономить на стоимости хостинга, одновременно демонстрируя лучшую производительность, чем раньше!

Управление конфигурацией

Системы CMS скрывают свою конфигурацию на нескольких страницах настроек. После того, как вы добавите модули к миксу с их собственной настройкой, вы можете легко получить ситуацию, когда ваша конфигурация хранится на более чем десяти различных экранах. Соедините это с тем фактом, что ваши пользовательские страницы и содержимое блога, вероятно, имеют свои собственные настройки и элементы управления для своих метаданных и информации SEO. Когда вам нужно внести изменения в конфигурацию, поиск изменений и уверенность в их результатах могут стать настоящей проблемой. Сравните это с подходом Джекилла. Конфигурация хранится в одном из двух мест: в файле _config.yml для общесистемных задач или в верхней части страницы или отдельного файла публикации в "передний вопрос" раздел YAML, в котором перечислен простой набор пар имя-значение, полезных для страницы. Подход Jekyll - это долгожданное изменение вашего обычного сайта на Drupal или Wordpress. Это дает вам возможность просматривать информацию о вашей конфигурации в одном месте, а также легко редактировать с помощью инструментов текстового редактора, поиска, замены и т. Д.

Управление версиями контента

В традиционной системе CMS у вас может быть управление версиями контента (с подключаемым модулем), но эта функция редко распространяется на информацию и шаблоны конфигурации системы управления версиями. Обычно вы создаете резервную копию базы данных до изменения конфигурации, называя резервную копию чем-то соответствующим, чтобы ссылаться позже, если это необходимо. Резервная копия непрозрачна. Нет никакого способа точно узнать, что было изменено, у вас просто есть версия состояния системы до и после. Подход «плоских файлов» Джекилла точно такой же, но принципиально отличается в том, как он применяется. В отличие от резервных копий базы данных, простые файлы легко сравниваются, а различия легко понять с помощью инструментов командной строки или продуктов с графическим интерфейсом, таких как "Вне всякого сравнения" , Jekyll может выполнить тот же конечный результат, сохраняя изображение состояния конфигурации «до и после», но это делается гораздо более доступным способом, который обеспечивает удивительную полезность. Когда вы соединяете этот подход с контролем версий, у вас теперь есть визуальная запись изменений, примечание о причине и аудит, кто и когда выполнил изменение.

Управление конфигурацией Jekyll настолько превосходит CMS, что это одна из главных причин, по которой мы перевели наш веб-сайт и блог с CMS, поддерживаемой базой данных. Эта особенность дает вам простой запасной вариант, поддержку ветвления для тестирования новых идей, контекстный контрольный журнал, комментарии и многое другое. Сила этого подхода к управлению изменениями распространяется даже на сам контент, позволяя редактировать страницы и посты в одном и том же мощном контексте сравнения. Не стоит недооценивать значение этого ключевого различия между этими платформами. В BHW эта особенность была главной причиной, по которой мы даже начали исследовать системы CMS с плоскими файлами. Drupal и Wordpress имеют некоторые плагины, которые обещают видения подобного подхода, но многие из этих плагинов имеют недостатки и часто несовместимы с другими плагинами, которые вы можете выбрать для своего веб-сайта.

Стоимость

Я начал статью с упоминания о том, что многие компании недооценивают стоимость традиционной CMS с открытым исходным кодом. Свободное программное обеспечение не означает наличие «бесплатного» веб-сайта. Даже если у бизнеса есть контроль над первоначальной стоимостью, очень немногие понимают стоимость обслуживания. Долгосрочные затраты делятся на несколько категорий:

• Хостинг
• техническое обслуживание
• Создание контента

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

Техническое обслуживание, вероятно, стоимость, которую большинство предприятий недооценивают. Игнорирование обслуживания - основная причина взлома большинства сайтов. Постоянная бдительность необходима для отслеживания уязвимостей и установки обновлений или исправлений. В большинстве случаев обновление или исправление можно легко установить; однако некоторые обновления требуют изменения кода или конфигурации. Подключаемые модули могут не переносить исправление на версию, которую использует ваш веб-сайт, что приводит к необходимости обновления до новой версии подключаемого модуля. Эти изменения кода и события принудительного обновления происходят чаще, чем вы думаете, и они всегда неожиданны. Обычно вы в конечном итоге работаете в промежуточной среде, чтобы протестировать обновление перед развертыванием в рабочей среде. Для точного тестирования важно максимально точно отразить производство, то есть синхронизировать производственный контент с подготовкой. Само по себе это может занять много времени, но правда заключается в том, что немногие предприятия делают это. Большинство просто устанавливают в производство и «надеются на лучшее», а затем реагируют, если что-то идет не так. Некоторые, вероятно, считают это образованной азартной игрой, которая экономит затраты на запуск второй среды за счет неожиданной срочной работы сайта, если что-то пойдет не так. Как только ваша CMS с открытым исходным кодом запускается некоторое время, вам в конечном итоге придется выполнить обновление основной версии, например перейти с Drupal 6 на 7 или 8. Это чрезвычайно сложные и трудоемкие события, и их игнорирование подвергает вас риску, поскольку поддержка старых версий базового решения CMS быстро исчезает по мере выпуска новых основных версий.

авторинг

Устранение каких-либо барьеров во время создания контента было самым большим фактором в нашей команде. Немногие вещи могут остановить принятие быстрее, чем плохой опыт в инструментах разработки. Когда сотрудники начнут вносить свой вклад, следующая задача состоит в том, как помочь им сделать свой контент привлекательным и привлекательным. Опять же, если инструменты мешают, наша команда с меньшей вероятностью внесет свой вклад. В обоих случаях мы обнаружили, что авторство из знакомой среды текстового редактора, такого как Sublime, было намного лучше по сравнению с инструментом CMS на основе браузера. Третий барьер - это инфраструктурные требования для авторинга, подключения к данным, входов в систему, VPN и т. Д. Мы хотели, чтобы наша команда создавала контент, где бы он ни находился, без каких-либо скачков. Преимущество, которого мы никогда не ожидали от Jekyll, заключается в том, что он позволяет полностью автономную авторизацию. Поскольку Jekyll поставляется со встроенным веб-сервером для рабочей станции-разработчика, наши сотрудники могут выполнять авторские работы, даже если они находятся в автономном режиме без подключения к данным. Последним препятствием для нашей команды было доверие. Системы CMS могут показывать крутые кривые обучения, и спектр ошибок в конфигурации может означать, что ваш контент неэффективен. Система публикации и компоновки Jekyll настолько проста, что не вызывает той же тревоги, которую вызывает сложная CMS.

гибкость

Последнее соображение - это гибкость контента. Насколько легко перенести ваш контент в другое авторское решение? Мы считаем, что статический подход к файлам в Jekyll более «ориентирован на будущее», чем использование базы данных контента. Когда мы впервые выполнили переход с Drupal на Jekyll, мы попытались использовать скрипт для извлечения контента. Поскольку мы использовали плагины для метаданных и изображений, инструмент не смог извлечь весь наш контент. Мы должны были написать больше сценариев самостоятельно, покопаться в базе данных и использовать код Ruby для объединения вещей. Даже после попыток написания кода нам все еще приходилось выполнять ручную очистку многих файлов. Теперь, когда мы работаем над Jekyll, если мы когда-нибудь решим переключиться на другую CMS, трудно представить более переносимый формат для нашего контента, чем статические файлы Jekyll. Каждый файл содержит весь контент и параметры конфигурации, необходимые для рендеринга на нашем сайте. Это гораздо полезнее, чем объединять содержимое базы данных.

Заключение

Одна вещь, которую мы не обсуждали в этой статье, это начальная разработка сайта. В BHW мы редко разрабатываем веб-сайты по шаблону, предпочитая создавать адаптивные веб-сайты, наилучшим образом адаптированные к видению дизайнера, используя соответствующий инструмент для каждой работы. Мы регулярно создаем интеграции и веб-сайты в таких системах, как Drupal и Wordpress для клиентов, и, исходя из нашего опыта, нет сомнений в том, что Jekyll проще, что приводит к удешевлению. Если ваш бизнес может выдержать более высокую техническую планку, которую навязывает Jekyll, это, несомненно, более выгодная цена, чем традиционная CMS. Существует множество успешных сайтов, работающих на Wordpress и Drupal. Я рад сообщить, что наш сайт больше не является одним из них.

Похожие

Комментарии