Русский
Русский
English
Статистика
Реклама

Drupal

Капля в море Запуск Drupal в Kubernetes

26.06.2020 20:05:42 | Автор: admin

image


Я работаю в компании Initlab. Мы специализируемся на разработке и поддержке Drupal проектов. У нас есть продукт для быстрого создания Ecommerce решений, основанный на Drupal. В 2019 году мы начали решать задачу построения масштабируемой и отказоустойчивой инфраструктуры для нашего продукта.


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


Часть статьи является переводом статьи Джеффа Герлинга. Со своей стороны добавили более подробное описание вариантов запуска баз данных и отказоустойчивого хранилища в кластере.


Drupal и Docker


image


Drupal и Docker могут работать вместе и хорошим примером тут служат локальные среды разработки, построенные вокруг Docker, такие как Docksal, Ddev, Lando и DrupalVM. Но локальные среды разработки, в которых кодовая база Drupal в основном монтируется, как том в контейнер Docker, сильно отличаются от рабочей среды, где цель состоит в том, чтобы вместить как можно большую часть кода в stateless контейнер.


В Kubernetes все, или почти все приложения вынуждены работать, как 12-факторное приложение и при развертывании Drupal в Kubernetes необходимо это учитывать.


Что такое 12 Factor Apps?


image


На базовом уровне 12-факторное приложение это приложение, которое легко развертывается в масштабируемой, широкодоступной и облачной среде.


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


Но 12-факторное приложение это приложение, которое облегчает развертывание и управление в масштабируемой среде:


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

Условия размещения Drupal в Kubernetes


Чтобы превратить приложение или веб-сайт на Drupal в более безликое 12-факторное приложение, необходимо соблюсти пять главных условий:


  1. База данных должна быть постоянной. Данные должны сохраняться между запусками контейнеров.
  2. Каталог файлов Drupal должен быть постоянным, масштабируемым и общим для всех веб-контейнеров.
  3. Установка Drupal и агрегация CSS и JS должны иметь возможность сохранять данные в каталогах с файлами Drupal-сайта.
  4. Настройки Drupal settings.php и другие важные настройки должны настраиваться установкой значений переменных среды.
  5. Задание cron в Drupal следует запускать через Drush, чтобы иметь возможность запускать его наиболее эффективным и масштабируемым образом.

Выполнение условий размещения Drupal в Kubernetes


1. База данных


Существует несколько способов решить задачу сохранения данных при перезапуске контейнеров в Kubernetes. Эту задачу необходимо решить любому веб-сервису, использующему базу данных. Рассмотрим эти варианты.


Управляемый сервис баз данных


Самый простой и наиболее часто применяемый способ использование сервиса управляемых баз данных: AWS RDS Aurora или Cloud SQL в Google Cloud. В этом случае, мы можем подключить свой сайт на Drupal напрямую к управляемой базе данных.


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


Docker образ mysql


Использовать базы данных внутри кластера Kubernetes можно, организовав отдельный контейнер для данных с помощью Docker. Это решение по стоимости дешевле, сохраняет переносимость и хорошо работает с небольшими сайтами и приложениями.
Но если необходимо иметь высокодоступные базы данных, реплицируемые на запись/чтение данных внутри Kubernetes, потребуется сделать гораздо больше работы.


MySQL Operator


Проект MySQL Operator предназначен для упрощения процесса размещения базы в кластере. Не работает в последних версиях kubernetes, начиная с 1.16. Кроме того, в каждой версии Kubernetes могут вноситься значительные изменения в API, из-за чего проект требуется адаптировать к новым версиям, что разработчики не всегда успевают делать.


Percona XtraDB Cluster Operator


Альтернатива MySQL Operator это решение Percona XtraDB Cluster Operator. Percona XtraDB Cluster объединяет в себе Percona Server для MySQL, работающий с механизмом хранения XtraDB, и Percona XtraBackup с библиотекой Galera, для обеспечения синхронной multi-master репликации.


image


Балансировка нагрузки выполняется с помощью демона ProxySQL, который принимает входящий трафик от клиентов MySQL и перенаправляет его на серверы MySQL. ProxySQL эффективно управляет рабочей нагрузкой базы данных по сравнению с другими балансировщиками нагрузки, которые не поддерживают SQL.


Helm chart для MariaDB


Более простым для запуска базы данных в кластере Kubernetes может быть использование Helm chart для MariaDB, которое позволяет развернуть в Kubernetes реплицированный кластер MariaDB. В данном кластере развертывается один master, а остальные slave контейнеры, с которых возможно чтение данных. В отличии от multi-master репликации, при отказе master контейнера будет остановке сервиса, на время запуска нового мастера.


PostgreSQL


Если рассматривать СУБД PostgreSQL, то существует проект Stolon облачный менеджер для обеспечения высокой доступности кластера PostgreSQL.


При деплое баз данных под MySQL или PostgreSQL, в Kubernetes, нужно где-то сохранять файлы с фактическими данных. Наиболее распространенный способ подключить Kubernetes PV (Persistent Volume) к контейнеру MySQL.


Итак, придется решить проблему запуска постоянной базы данных в кластере Kubernetes, если требуется использовать полностью облачную среду.


2. Каталог файлов Drupal


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


  • Когда во время установки Drupal перезаписывается файл settings.php.
  • Когда во время установки Drupal не проходит предварительную проверку установщика, если каталог сайта (например sites/default) не доступен для записи.
  • Если при создании кеша тем Drupal требуется доступ на запись в каталог публичных файлов, чтобы он мог хранить сгенерированные файлы Twig и PHP.
  • Если используется агрегация CSS и JS, Drupal требуется доступ на запись в каталог публичных файлов, чтобы он мог хранить сгенерированные файлы js и css.

Существует несколько вариантов решения этих задач.


NFS


Самое простое решение всех этих задач, позволяющее Drupal масштабировать и запускать более одного экземпляра Drupal это использовать NFS для папки файлов Drupal (например sites/default/files). Однако легче не значит лучше. У NFS есть свои особенности:


  • NFS имеет проблемы с производительностью блокировок файлов при нагрузках.
  • NFS может быть медленным для определенных типов доступа к файлам.

Облачное хранилище совместимое с S3


Можно использовать сервис хранения типа Amazon S3 в качестве общедоступной файловой системы для своего Drupal сайта, что снизит затраты на поддержку хранилища и повысит его надежность. Для интеграции S3 хранилища с drupal можно использовать, например, модуль S3FS.


Распределенные файловые системы


Также можно использовать распределенные файловые системы, такие как Gluster или Ceph. Однако тут увеличивается сложность поддержки таких решений, которые можно решить в Kubernetes с помощью проекта rook.


Проект Rook


image


Rook "превращает" распределенные системы хранения в самоуправляемые, самомасштабируемые, самовосстанавливающиеся сервисы хранения. Он автоматизирует задачи администратора хранилища: развертывание, загрузку, настройку, предоставление, масштабирование, обновление, миграцию, аварийное восстановление, мониторинг и управление ресурсами.


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


Rook управляет несколькими решениями для хранения, предоставляя общую платформу для всех из них. Rook гарантирует, что все они будут хорошо работать в Kubernetes:


  • Ceph
  • EdgeFS
  • CockroachDB
  • Cassandra
  • NFS
  • Yugabyte DB

3. Установка Drupal


image


Сделать файл settings.php доступным для записи во время установки более сложная задача, особенно если вам нужно установить Drupal, а затем развернуть новый образ контейнера ( что произойдет со всеми записанными значениями settings.php? Они будут удалены при перезапуске контейнера! ). Поэтому решение данной задачи получило отдельный пункт описания особенностей запуска Drupal в Kubernetes.


Пользователи могут устанавливать Drupal через веб-интерфейс мастера установки или автоматически через Drush. В любом случае Drupal во время установки, если еще не установлены все правильные переменные в settings.php, добавляет некоторые дополнительные конфигурации к файлу sites/default/settings.php или создает этот файл, если его не существует.


Следующие параметры должны быть предварительно установлены в settings.php, чтобы Drupal автоматически пропускал экран установки и не требовал записи дополнительных конфигураций в файл settings.php:


// Config sync directory.$config_directories['sync'] = '../config/sync';// Hash salt.$settings['hash_salt'] = getenv('DRUPAL_HASH_SALT');// Disallow access to update.php by anonymous users.$settings['update_free_access'] = FALSE;// Other helpful settings.$settings['container_yamls'][] = $app_root . '/' . $site_path . '/services.yml';// Database connection.$databases['default']['default'] = [  'database' => getenv('DRUPAL_DATABASE_NAME'),  'username' => getenv('DRUPAL_DATABASE_USERNAME'),  'password' => getenv('DRUPAL_DATABASE_PASSWORD'),  'prefix' => '',  'host' => getenv('DRUPAL_DATABASE_HOST'),  'port' => getenv('DRUPAL_DATABASE_PORT'),  'namespace' => 'Drupal\Core\Database\Driver\mysql',  'driver' => 'mysql',]

В данном примере используются переменные окружения (например: DRUPAL_HASH_SALT) с функцией PHP getenv() вместо "жестко" заданных значений в файле. Это позволяет контролировать настройки, которые Drupal использует как при установки, так и для новых контейнеров, которые запускаются после установки Drupal.


В файле Docker Compose, чтобы передать переменные, указываются директива environment для контейнера web/Drupal следующим образом:


services:  drupal:    image: drupal:latest    container_name: drupal    environment:    DRUPAL_DATABASE_HOST: 'mysql'    [...]    DRUPAL_HASH_SALT: 'fe918c992fb1bcfa01f32303c8b21f3d0a0'

А в Kubernetes, когда создаете Drupal Deployment, передать переменные среды можно с помощью envFrom и ConfigMap (предпочтительно), также можно напрямую передавать переменные среды в спецификации контейнера:


---apiVersion: extensions/v1beta1kind: Deploymentmetadata:  name: drupal  [...]spec:  template:    [...]    spec:    containers:        - image: {{ drupal_docker_image }}        name: drupal        envFrom:        - configMapRef:            name: drupal-config        env:            - name: DRUPAL_DATABASE_PASSWORD            valueFrom:                secretKeyRef:                name: mysql-pass                key: drupal-mysql-pass

Приведенный выше фрагмент манифеста предполагает, что уже в kubernetes есть ConfigMap с именем drupal-config содержащей все DRUPAL_* переменные, кроме пароля к базе данных, а также секрет, названный mysql-pass, с паролем в ключе drupal-mysql-pass.


На этом этапе, если создаете новую среду с помощью Docker Compose локально или в кластере Kubernetes, можете перейти к установщику пользовательского интерфейса или использовать Drush. При этом не требуется вводить учетные данные базы данных, поскольку эти и другие необходимые переменные уже предварительно настроены.


4. Конфигурация Drupal, управляемая средой


Также может быть ряд других параметров конфигурации, которыми требуется управлять, используя переменные среды. Drupal еще не имеет механизма для этого, поэтому необходимо встроить такие настройки в код, используя getenv().


5. Выполнение заданий Cron Drupal в Kubernetes


image


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


Внутри Kubernetes не нужно настраивать crontab ни на один из узлов Kubernetes, работающих с сайтами Drupal. И хотя может быть внешняя система, например Jenkins, запускающая задания cron на Drupal сайте, гораздо проще просто запускать Cron Drupal как Kubernetes CronJob, в идеале в том же пространстве имен Kubernetes, что и Drupal.


Самый надежный способ запуска Drupal cron через Drush, но запуск отдельного контейнера Drush через CronJob означает, что CronJob должен запланировать сложный контейнер, работающий как минимум на PHP и Drush. Поды CronJob должны быть максимально легкими, чтобы их можно было планировать на любом системном узле и запускать очень быстро (даже если ваш контейнер Drupal еще не был загружен на этот конкретный узел Kubernetes).


Cron Drupal поддерживает запуск путем посещения URL-адреса, и это самый простой вариант для работы с Kubernetes. Пример настройки CronJob:


---apiVersion: batch/v1beta1kind: CronJobmetadata:  name: drupal-cron  namespace: my-drupal-sitespec:  schedule: "*/1 * * * *"  concurrencyPolicy: Forbid  jobTemplate:    spec:    template:        spec:        containers:        - name: drupal-cron            image: byrnedo/alpine-curl:0.1            args:            - -s            - http://www.my-drupal-site.com/cron/cron-url-token        restartPolicy: OnFailure

URL drupal_cron_url зависит от сайта и можно его найти, посетив страницу /admin/config/system/cron. Убедитесь, что в настройках cron для Run cron every установлено значение Never, чтобы cron запускался только через CronJob Kubernetes.


Можно использовать byrnedo/alpine-curl образ докера, который является чрезвычайно легким всего 5 или 6 МБ так как он основан на Alpine Linux. Большинство других контейнеров, которые есть на базе Ubuntu или Debian, имеют размер, по крайней мере, 30-40 МБ (так что они будут использовать гораздо больше времени, чтобы загрузить первый раз, когда CronJob запускается на новом узле).


Заключение


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

Подробнее..

Длинная история про то, как мы веб-разработчика на фрилансерских сайтах искали, но так и не нашли

06.06.2021 20:07:08 | Автор: admin

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

Этот лонгрид - о фрилансерах в частности, и немного о веб-разработке в целом, от лица заказчика. Я прекрасно понимаю, что большинство завсегдатаев Хабра - исполнители, а заказчикам тут периодически прилетает. И все же рискну высказаться. Надеюсь, будет весело.

Тут надо сделать небольшое лирическое отступление, чтобы вы смогли погрузиться в контекст. Итак, у нас с коллегами есть небольшой pet-проект в области образования. Если точнее - в области постановки произношения. Внутри этого pet-проекта есть еще один вложенный класс pet-проект, - YouTube канал, на котором мы тестируем разные идеи, собираем отзывы, и немного анализируем рынок.

Постепенно у нас накопилось приличное количество текстового материала - статьи, аналитика, разные тестовые задачки, и тому подобное. Параллельно YouTube канал набрал несколько сотен тысяч подписчиков. А еще мы стали замечать, что доля поискового и внешнего трафика на канале приближается к 50% (это много). Причем поисковые фразы хорошо коррелируют с "нужными" высокочастотными запросами.

В общем, мы дозрели до своего сайта.

Пишем техзадание

Адекватного заказчика отличает хорошее понимание того, что он хочет. Проблема в том, что нам-то был нужен самый что ни на есть обычный контентный сайт. Мы даже ненадолго впали в ступор, как это красиво расписать. По большому счету, техзадание могло быть примерно таким:

Сделать совершенно типичный сайт для публикации статей. Функциональные требования не выделяются чем-то уникальным. Дизайн - примитивный. Нагрузка - средняя. Pagespeed insights >= 90%.

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

Полнотекстовый [морфологический] поиск а-ля ElasticSearch или Sphinx.
Фильтрация списков статей по множеству тегов.
Сортировка списков статей по времени и/или категориям.
Кастомное меню с навигацией по ключевым статьям на главной странице.
И еще одна секретная фича на фронтенде.

Я еще расскажу об этих "специальных" требованиях ниже. Впрочем, даже с ними функциональная часть нашего ТЗ не выглядела как Rocket Surgery.

Осталось разобраться с нефункциональными требованиями.

Гугл не скрывает, что использует скорость загрузки страниц в качестве одного из критериев своих алгоритмов ранжирования. Поэтому мы включили в ТЗ оптимизацию сайта до зеленой зоны PageSpeed Insights. Кроме вполне очевидной пользы, это требование позволяло нам отсечь неопытных исполнителей (спойлер: это сработало, но не совсем так, как мы предполагали).

За отправную точку оценки нагрузки взяли наш YouTube трафик. В хороший день это 7-8 тысяч уникальных посетителей со средним количеством просмотренных видео 2,4. Берем полуторакратный запас и получаем порядка 30 тысяч хитов. Это примерно 12 тысяч посетителей в день.

В общем, у нас получилось вполне приличное техзадание на 15 страниц.

Публикуем заказ.

Рассуждая в том ключе, что "хорошие" исполнители ТЗ читают, а "плохие" нам не нужны, мы добавили в техзадание "капчу": просьбу начинать отклик со слов "Hello there!".

Сам текст публикации был максимально коротким. Примерно таким:

Cделать контентный сайт на базе вашей любимой CMS/фреймворка согласно ТЗ

Внимательно прочитать требования к проекту (!).
Выбрать оптимальную CMS/фреймворк, удовлетворяющие требованиям.
Оценить общую трудоемкость и стоимость проекта.
Согласовать приблизительный поэтапный план разработки.
Собственно, сделать сайт согласно плану.

Заказ опубликовали на пяти площадках, с разницей по времени от нескольких дней до недели. Там, где было возможно, мы старались "выделить" объявление:

площадка

стоимость публикации

стоимость "выделения"

ИТОГО:

freelance.habr.com

0

800

800

fl.ru

350

1250

1600

freelancehunt.com

0

840

840

freelance.ru

350

0

350

weblancer.net

0

0

0

На все про все было потрачено примерно 3500 рублей. Бюджетненько!

Разбираем отклики

Всего на заказ отозвались ровно 100 исполнителей:

площадка

всего откликов

прошли "капчу"

прошли "капчу" %%

freelance.habr.com

33

8

24%

fl.ru

30

4

13%

freelancehunt.com

20

1

5%

freelance.ru

15

1

7%

weblancer.net

2

0

0%

ИТОГО:

100

14

14%

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

Чтобы себя успокоить, мы сделали трекер исполнителей с классификатором их видов:

Вид первый, "автобот":

Здравствуйте, это как раз мой профиль, готов помочь!
Портфолио > https://***.**/portfolio/
Телефон/Viber/WhatsApp: ***

(здесь и далее приведены совершенно реальные отклики, орфография и пунктуация авторов сохранены)

Характерные признаки "автобота": присылает отклик практически сразу после публикации заказа. Где-то в интервале от минуты до пары часов. Как правило, в портфолио бота половина ссылок не работает. Причем это лучшая половина. Чаще всего боты водятся на freelancehunt.com и freelance.ru. Что бы вы ни делали, вступать с вами в переписку бот не будет.

Вид второй, "разработчик продающих сайтов":

--не бот--

***, добрый день! Меня зовут ***, я веб-разработчик с опытом более 10 лет. Самое главное - это продающая структура, а уж потом дизайн и верстка, я делаю именно "продающие" сайты, которые реально работают.

CMS на которых делаю сайты: 1. 1С Битрикс 2. Тильда 3. Wordpress

Характерные признаки: старательно дистанцируется от ботов. Вне зависимости от задачи, использует такие словосочетания как "повышение продаж", "продающая структура", "конверсия", "SEO", и другие. Средний опыт работы - более 10 лет. В списке регалий имеет Битрикс и Тильду.

Наконец, вид третий. Самый забавный. "эффективный project manager":

Добрый день, ***!

Бюджет вашего проекта 10 000$. Если вас устраивает такая стоимость, то давайте назначим звонок на конкретное время. Длительность звонка: 1 час. Наш CTO к тому времени ознакомится с вашим документом и подготовит ответы на ваши вопросы.

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

В итоге, лучше всего себя показал freelance.habr.com (ура!), хуже всего - freelancehunt.com и freelance.ru. Как еще существует weblancer.net - непонятно.

Далее, из сотни откликнувшихся лишь 14 человек полностью прочитали наше задание. Еще шестеро капчу не прошли, но попали в short-list, потому что написали развернутый отклик.
Итого - 20.

Слава роботам!

Пытаемся планировать

Life is what happens to you while you're busy making other plans
John Lennon.

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

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

Почти половина отвалилась сразу, даже не попрощавшись. Причем, что интересно, отвалились как раз те, чьи отклики производили наилучшее впечатление.

Несколько человек все же планы прислали, чем нас еще немного повеселили. Ниже - наш топ-3.

"Стандартный" план:

этапы разработки у нас стандартные ))
1. Разработка прототипа проекта (UX проектирование)
2. Разработка дизайна
3. Верстка
4. Посадка верстка и доработки серверной части
5. Тестирование

Еще вариант, со сроками:

1. Прототипирование и создание дизайна сайта 10 дней
2. Верстка сайта 7 дней
3. Программирование структуры сайта 30 дней
4. Создание уникальных модулей 10 дней

И, наконец, мой любимый, самый короткий:

Разработка фронтенда, админ-панель, бэкенд
По срокам примерно 2-3 недели, цену предлагайте сами.

В результате, этап планирования прошли шестеро. Трое - с Wordpress, и по одному с Laravel, October CMS, и Drupal.

Впереди нас ждет еще очень много всего интересного!

Wordpress - три попытки, от $2000 до $4000

Когда-то в начале двухтысячных Wordpress задумывался как простая система для self-hosting блога: удобная админка, таксономия, теги, антиспам фильтр, неплохой по меркам тех времен редактор, и так далее. Где-то начиная с 2011, стали появляться разнообразные плагины: e-commerce, booking, формы, галереи, и так далее.

Наверное, это был правильный вектор развития с точки зрения бизнеса. В конце концов, миллионы владельцев "лэндингов" и интернет-магазинов не могут ошибаться. Вот только как система для публикации контента Wordpress так и остался где-то в 2010-м. И даже, по-моему, немного откатился назад.

Камнем преткновения для Wordpress разработчиков стали наши требования по скорости загрузки страниц. Напомню, что нам очень хотелось получить сайт в зеленой зоне PageSpeed Insights. Так вот, по оценке наших кандидатов, оптимизация Wordpress съедала 40-50%% бюджета. Буквально каждый кандидат категорически настаивал на разработке кастомизированной темы "с нуля".

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

Мы просто подсчитали, что только оптимизация обходилась нам где-то от $800 до $2000. Но это еще не самое страшное.

Другая проблема Wordpress, как ни странно, - это очень скромные "встроенные" средства управления контентом. Приведу такой пример: на Хабре можно посмотреть список статей в хабе фриланс, либо в хабе разработка веб-сайтов, но нельзя получить список статей, относящихся к обоим хабам одновременно.

У нас, конечно, гораздо меньше контента, чем на хабре. Зато время его жизни существенно больше. Чтобы помочь пользователям ориентироваться во всех наших статьях, мы решили добавить фильтры по множеству тегов.

Если вы хотя бы чуть-чуть знакомы с основами баз данных, то набросать запросы для фильтров many-to-many сможете за полчаса А вот стандартных плагинов для Wordpress с такой функциональностью - нет. Как нет и полнотекстового поиска из коробки, не говоря уже о морфологическом.

В общем, у нас были три Wordpress-кандидата. Все трое - хорошие специалисты с неплохими портфолио и впечатляющим опытом. Кстати, говоря о бюджете, даже с учетом Wordpress-оверхеда, он был вполне приемлемым: от $2000 до $4000.

Мы всячески пытались довести хотя бы одного из кандидатов до контракта. Но не сложилось: первый сошел с дистанции в процессе согласования деталей. Второй изначально особой активности не проявлял, как бы намекая, что не сильно заинтересован. Третий немного подумал, и сам предложил отказаться от Wordpress в пользу Laravel. За +20% к цене.

А ведь все так хорошо начиналось!

Laravel - $2000

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

Hello there! Я не могу предложить готовую CMS, но зато могу предложить потрясающий фреймворк Laravel. На нём могу реализовать весь необходимый вам функционал.

Вечер перестает быть томным, - подумали мы.

Буквально за выходные кандидат-ларавел развёл кипучую деятельность: написал весьма подробное техническое обоснование, включая примерный расчет VPS сервера под требуемую нагрузку, список необходимых сторонних библиотек, краткий план работ, mind map, и даже прислал несколько референсных тем. Несмотря на разницу во времени, кандидат отвечал на вопросы практически мгновенно, да и в целом производил самое что ни на есть благоприятное впечатление.

Вот только был один нюанс: у парня не было портфолио. Совсем не было. Ни единого сайта. Более того, он отказывался показать хоть какие-нибудь примеры своих работ, ссылаясь на NDA.

И тем не менее, мы решили рискнуть. Во-первых, кандидат-ларавел был самым коммуникабельным из всех, с кем мы на тот момент успели пообщаться. Во-вторых, сумма ($2000 за основную функциональность) и сроки (4 недели) выглядели вполне разумно. Поэтому мы предложили вариант с поэтапной оплатой через escrow. От него требовалось только подтвердить план на первые два этапа и заключить контракт

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

А жаль, нормально же вроде общались.

Drupal - $8000

В любом pet-проекте есть несколько интересных идей "на вырост". У нас они тоже есть. Что гораздо важнее, мы знаем, чего мы делать не будем: не будем открывать интернет-магазин, запускать корпоративный портал, хостить форумы, и тому подобное.

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

Поэтому мы немного удивились, когда на наш заказ откликнулась целая web-студия с предложением сделать сайт на Drupal 9. Они оценили бюджета проекта в $8000.

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

Как были обоснованы $8000? А никак! Все, что было хоть сколько-нибудь детально расписано, относилось к дополнительным опциям. Ну, вы понимаете, все эти , "структура сайта", "user story", "подготовка ТЗ" и "фиксация деталей по функциям". Где-то даже промелькнула фраза "наполнение контентом".

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

В общем, от этого предложения мы отказались сами: писать user story нам не хотелось, да и в целом выбор Drupal показался необоснованным.

А еще мы пожалели $8000.

October CMS - $2000

Нам изначально нравилась философия минимализма в October. К примеру, мы не планировали регистрацию внешних пользователей. Для простого контентного сайта в этом просто нет необходимости: контент будем добавлять только мы, а для комментариев все равно удобнее использовать что-то вроде commento.io. Зачем нам лишний код?

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

Мы хотели пообщаться с кем-нибудь с опытом в October, хотя статистически это и было маловероятно. И все же, иногда даже маловероятные события случаются.

В отличие от кандидата-ларавел, наш кандидат-october старался избегать телефонных разговоров. Зато он много писал. В частности, он написал самый детальный план из всех, что мы видели, включая целых два списка необходимых плагинов (основной, и "резервный"), расчет сервера, прикидку по "кастомной" функциональности, по доводке дизайна, оценку рисков, и еще много всего.

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

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

В общем, мы заключили контракт и закинули деньги за первые два этапа на escrow.

Первый этап был закончен точно в срок, мы даже удивились. Не то, чтобы это был сложный этап, - изначальная установка CMS, базовых плагинов и тем. Но к этому моменту мы уже так устали от всего происходящего, что радовались как маленькие дети. У нас, наконец, что-то заработало! Мы даже можем что-то опубликовать!

Увы, наша радость была недолгой. Второй этап был отложен на неделю, потом еще на неделю. Судя по коммитам на Github, второй этап даже не был начат. А потом исполнитель просто пропал.

Запил, наверное.

Бонус - профессиональные студии, до $18 000

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

Конечно, мы были несколько разочарованы тем, что найти фрилансера никак не получается. Но время не ждет, и мы решили обратиться к профессионалам. То есть к веб-студиям, которые зарабатывают на разработке сайтов.

Если коротко, то там еще хуже.

Нам присылали "коммерческие предложения", скопированные с других проектов, не имеющих ничего общего с нашим. Нам предлагали сделать магазин, - "вам же когда-нибудь понадобится магазин?" Нам предлагали "зашифровать чувствительные данные". Нам предлагали увеличить трафик в два раза (серьезно?!?), а также "переделать сайт под SEO продвижение", и "протестить нишу". Да, еще нам предложили "написать адекватное ТЗ". Я уже рассказывал про use cases и user story?

Нам долго и обстоятельно рассказывали о преимуществах EditorJS над Tailwind, и TinyMCE над Bootstrap (и наоборот). Нам даже объяснили, почему монолитная архитектура нам подходит лучше, чем микросервисы. Ах да, ну и конечно, правильный PHP - это PHP 7, правильный Laravel - это 8, ну а правильный HTML - это 5! И никак иначе!

Зачастую все это сопровождалось огромным количеством грамматических ошибок и перемежалось фразами "я вас услышал", "наиболее оптимальный", и тому подобными. Не поймите меня неправильно, лично я спокойно отношусь к грамматическим ошибкам. Но когда в твоей команде большинство - лингвисты, им сложно объяснить, почему project-manager подрядчика пишет как третьеклассник, а разговаривает как пятиклассник.

И все это за каких нибудь $18 000 (восемнадцать тысяч долларов США). Ну хорошо, если мы "урежем" часть требований - $12 000. Но тогда работа аналитика оплачивается отдельно.

Вместо эпилога

За время поиска веб-разработчика наши контент-менеджеры и редактор подготовили 15 новых статей. Их по-прежнему негде публиковать.

Подробнее..

Обзор CMS DRUPAL 9

10.08.2020 02:14:34 | Автор: admin

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


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


В этом обзоре я хочу поговорить об актуальной на сегодня версии DRUPAL 9. О возможностях системы, ее плюсах и ограничениях. И этот текст адресован, в первую очередь, будущим пользователям и владельцам сайтов. Потому здесь не будет сложных технических нюансов, их специалисты и без того уже не один раз обсудили в профессиональных сообществах.


Я постараюсь максимально простым языком объяснить потенциальным владельцам Drupal-сайтов, что можно ожидать от этой CMS, что требовать от веб-разработчиков в процессе создания сайта, и что можно реально получить для последующей самостоятельной работы с проектом.


Небольшое разъяснение:


  1. Я намеренно не сравниваю версии Drupal, так как на данный момент это уже не важно и вот почему:


    Для Drupal 7 разработка новых модулей практически не ведется. Для уже выпущенных модулей в приоритете DRUPAL 9. Думаю это связано не только с тем что Drupal 9 новее, но и потому что официальная поддержка Drupal 7 и Drupal 8 закончиться в ноябре 2022 года.



  2. Все скриншоты я делаю на работающем личном сайте (ссылку сможете найти в моем профиле).


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



  4. В каждом скриншоте, за редким исключением, вы сможете найти адрес страницы сайта, и при желании подставив свой домен вместо моего, вы сможете перейти к странице настроек как в статье.



Из чего состоит CMS


CMS (Content Management System) переводится как это компьютерная информационная система для управления контентом, т.е. содержимым сайта.Нередко можно встретить упрощенное название движок сайта, что по сути упрощение. Появились такие системы как ответ на решение одновременно двух проблем:


  1. Снижение трудоемкости работы программистов. CMS формирует страницы на лету на основе шаблонов и непосредственно контента (текста, картинок, видео и других материалов, хранящихся в базах данных).
  2. Предоставление возможности пользователям заниматься наполнением сайта. При помощи CMS даже человек, далекий от программирования, может добавлять или удалять страницы, изменять их содержимое и т.д.

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


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


Появление CMS-систем решило все эти проблемы, теперь все выглядит так:


  1. Есть шаблоны с дизайном сайта или его отдельных разделов.
  2. Есть сама система управления с удобным для пользователей разделом администратора.
  3. Есть базы данных и папки для хранения графики, документации, видео.

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


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


Управление данными в DRUPAL 9


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


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


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



Для работы с данными вам понадобятся 3 основные сущности:


  • Ноды;
  • Таксономия;
  • Представление.

О каждой из них поговорим подробнее.


Ноды (Типы материалов)


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


В разделе Типы материалов доступны:


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


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


  3. Добавляете контент на сайт.



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


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


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


Далее, ваш проект развивается, и вы понимаете, что вам нужен блог. А это совсем другой тип подачи информации. Здесь нужна страница самого блога, содержащая анонсы статей. И отдельно страницы текстовых материалов. Вы просто заходите в раздел Типы материалов и создаете еще два нода под страницу самого блога (не забудьте добавить отображение пункта меню), и под страницы текстовых материалов.


Примеры типов материалов: статья, базовая страница, запись блога, отзыв и т.д.


Таксономия (Taxonomy)


В Drupal под термином таксономия скрывается все, что касается структуры сайта. Для пользователей, привычным к другим CMS, структура немного необычная. Дело в том, что таксономия это может быть связано с меню сайта с любым количеством подпунктов ( для вывода категорий блогов выпадающем меню например), и привычные любителям Wordpress метки (тэги), рубрики и возможность связывать между собой материалы из разных разделов.


Основные сущности:


  • Словарь используется для объединения терминов ( например словарь категории или тэги)
  • Термины основные сущности (метки, разделы) для объединения материалов по какому-то признаку. При этом термины могут иметь неограниченное количество вложений.

Например, вы хотите создать магазин по продаже овощей и фруктов. Основные словари Овощи, Фрукты, Ягоды. В словаре Фрукты могут быть Яблоки, Апельсины, Бананы и т.д. Но, если вам нужна дальнейшая детализация без проблем. В термине Яблоки создаете, например, подпункты с названиями сортов. При этом вы можете одновременно использовать словарь сортировки, скажем, по цвету. И тогда ваши яблоки будут отображаться и при выборе покупателям раздела с яблоками, и при поиске по красным или зеленым фруктам.


Еще один классический пример это категории блога. Создаем словарь "Категория услуг", в словаре создаем термины, например CRM, ERP методология и т.



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



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


К слову, изменять порядок терминов в словаре или их подчиненность друг другу очень просто. Достаточно потянуть мышью нужный термин в нужное место, и он легко переместится в соответствии с той структурой, которую вы создаете.


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


Представление (Views)


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



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


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


Вот так выглядит представление страницы отзывов в административном разделе:



А вот результат на странице сайта отзывы отделены друг от друга, выбран стиль отображения, все поля выглядят одинаково:



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


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


Управление Пользователями


Пользователи (People) с точки зрения системы Drupal это все посетители вашего сайта, начиная от случайных читателей и заканчивая редакторами и администраторами.



Работать с этим разделом просто:


В меню Роли (Roles) вы создаете все необходимые виды пользователей. Количество ролей может быть столько, сколько вам нужно. Обычно это:



  1. анонимный, т.е. посетитель без регистрации,
  2. зарегистрированный, т.е. пользователь с авторизацией, но без доступа к административному разделу;
  3. автор или контент-менеджер человек, который может добавлять материалы в выбранные вами разделы;
  4. администратор полные права доступа и т.д.
  5. В меню Права доступа для каждой роли вы прописываете доступ, просто выставляя флаг галочка в выбранном поле. При добавлении каждой ноты или таксономии они автоматически попадают в этот список. И добавить право просматривать или как-то работать с ними вы можете при помощи редактирования прав доступа.


Всех активных пользователей вы видите на основной странице (Список), здесь же можно изменить для них права доступа, удалить или добавить нового пользователя.


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


Шаблонизация в Drupal 9


В Drupal 9 заметно упростили разработку шаблонов для отображения различных типов страниц. Теперь для этого нет необходимости знать язык программирования PHP. Шаблоны можно формировать в простом HTML-коде, в том числе, при помощи конструктора. Далее они дополняются некоторыми командами специального языка Twig 2.x.


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


Для примера вот код верстки на сайте из шаблона отвечающие за вывод отзывов.



Расширения


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


Система Drupal 9 поддерживает огромное количество модулей. Значительная часть из них уже установлена в коробке. Остается только решить, что с ними сделать включить и применять, отложить до лучших времен или удалить. Другие вы можете найти на сайтах, посвященных CMS Drupal, скачать и установить.



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


Из числа расширений хотелось бы выделить:


  • Набор модулей Commerce для организации интернет-магазина. Благодаря гибкой настройке и широкому перечную функций позволяют организовать практически любой тип электронной торговли.
  • Pathauto. Автоматически создает по шаблону осмысленные адреса страниц, соответствующие материалу.
  • Redirect 404. Регистрирует ошибки 404, позволяет анализировать статистику переходов на несуществующие страницы, создает редирект в случае попытки перехода на отсутствующую страницу.
  • Webform набор модулей для создания различных типов форм, в том числе, комментарии, обратная связь, работа с тикетами и т.д.

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


Локализация


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




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



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


Интеграция


Система Drupal легко интегрируется с различными информационными системами. Мы интегрировали Drupal-сайты с Zoho CRM и другими продуктами линейки, с учетными системами, в том числе, 1С, с различными платежными системами, онлайн-чатами поддержки и т.д.


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


Программист просто подключается к сайту и получает нужные данные, даже не зная Drupal. Он будет работать, например, над мобильным приложением или какой-либо системой обработки информации. И ему для получения информации с сайта понадобятся знание JSON, методов и запросов, которые широко используются при организации API.


Поисковая оптимизация


С точки зрения SEO-продвижения, сайты Drupal можно смело называть одними из самых настраиваемых. Больше возможностей дает разве что прямая работа с php-кодом. Расширений для SEO существует огромное количество. Расскажу про некоторые из них.


О модуле Pathauto, который создает осмысленные адреса страниц, я уже рассказывал выше. В случае необходимости вы также можете вручную менять синонимы URL для любых страниц.




Вторая строка выдачи.



Существуют в Drupal также встроенные поля для различных сео-тегов, не забывайте подключать их при настройке нодов, а после заполнять. Есть расширения для генерации карты сайта. В разделе расширений вы их найдете в разделе XML КАРТА САЙТА. А если не понравятся имеющиеся в коробке, всегда можно найти и установить альтернативные.


Скорость работы


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


Также в Drupal 9 появилась возможность хранить для определенного разрешения устройства определенный размер картинки. То есть загружаете вы картинку размера 1200*1600, и можно указать что разрешения экрана в 800 пикселей максимальная ширина картинки будет 800 и CMS сама сделаем соответствующую копию картинки. За это отвечает модуль Responsive Image.


Админ-раздел сайта также работает быстро. Страницы не перегружены информацией, потому загружаются и сохраняются все изменения без задержек. Нареканий работа системы с этой точки зрения не вызывает.


Для примера прикладываю замер с сервиса PageSpeed Insights



E- Commerce


Интернет-магазины на базе Drupal решение популярное. За организацию электронной коммерции отвечает соответствующий модуль Commerce. В базовой версии он выглядит так:





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


Вы можете:


  • Создать каталог товаров с разделением по категориям;
  • Организовать поиск по товарам;
  • Создать карточку товара с нужными полями;
  • Добавить товар в корзину;
  • Подключить различные платежные системы;
  • Настроить обмен данными с учетными, CRM и другими программными системами и т.д.

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


Безопасность данных


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


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


Почему я перешел на Drupal 9


Я много лет проработал с CMS Drupal 7, но в последние годы после внимательного изучения полностью перешел на Drupal 8, а затем как только вышла 9 версия, сразу на нее.


В чем преимущества системы:


  • Для работы с шаблонами не требуется знания PHP. Работать с ними теперь проще и быстрее, даже для опытного программиста.
  • Интеграция стала проще. О преимуществах модуля интеграции, который появился в Drupal 9, я подробно писал выше.
  • Большое количество модулей в Drupal 9 уже есть в коробке. В прошлой версии многие расширения приходилось искать и устанавливать вручную.
  • Открытость и бесплатность

Кроме того, многие возможности Drupal 7, в том числе, написанные под эту версию движка расширения, уже перестали обновляться. А новые решения уже ориентированы на Drupal 9.


Для каких сайтов подходит Drupal


Если вы создаете небольшой сайт-визитку и вам предлагают воспользоваться Drupal 9, стоит хорошо подумать и, скорей всего, отказаться. Здесь скорее будет актуален Wordpress или подобные решения. Также не имеет смысла выбирать Drupal для блога или простого статейного проекта. Выбирайте CMS, которые уже позиционируют себя как решения, подходящие под ваш тип сайта.


Дело в том, что Drupal 9 система мощная, но по-своему сложная. И число необходимых для начала работы настроек велико для организации небольшого сайта. Затраты времени на настройку и добавление информации, скорей всего, не окупятся. Впрочем, если к этой визитке в недалеком будущем будут подключаться и другие модули, выбор Drupal может оказаться, наоборот, верным решением.


Для создания корпоративного сайта или полноценного интернет-магазина CMS Drupal 9 подойдет наилучшим образом. Для подобных проектов важно:


  1. Скорость загрузки и сео-оптимизация;
  2. Возможность автоматизации и настройки обмена данными с другими системами;
  3. Распределение ролей пользователей для разных сотрудников;
  4. Настройка шаблонов для разных разделов и т.д.

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


Подробнее..
Категории: Cms , Drupal , Cms разработка

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru