Установка Drupal.

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

Ранее мы с вами разобрались как на свой компьютер. После того, как локальный сервер установлен и готов к работе, можно приступать к установке Друпал.

Установка Drupal 7 проходит в два этапа. Первое, что нам необходимо будет сделать – это создать базу данных, и второе – начать непосредственно саму установку данной CMS. Приступим!

Создание Базы данных

Для того, чтобы создать базу данных нам нужно в адресной строке браузера вписать: http://localhost/Tools/phpMyAdmin и в открывшемся окне нажать на вкладку «Базы данных».

Пишем название нашей базы данных (1) и нажимаем кнопку «Создать» (2).

Как только база данных была создана, самое время добавить пользователя для этой базы данных. Чтобы это сделать, кликните по «Проверить привилегии».

И нажимаем кнопку «Добавить пользователя».

Пишем имя пользователя (1), указываем хост – локальный (2) и пароль (3).

Проматываем немного ниже и жмем – «Отметить все» (1) для того, чтобы выставить максимальные привилегии для данного пользователя. И после этого нажимаем кнопку «Добавить пользователя» (2).

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

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

Перейдем на нашем локальном сервере в директорию: C:\WebServers\home\localhost\www\ и создадим папку, в которой будет находиться наш будущий сайт – «drupal7». Следует запомнить, что название папки будет соответствовать локальному доменному имени, по которому будет доступен сайт, т.е. в данном случае, сайт будет доступен по следующему адресу – http://localhost/drupal7.

Теперь разархивируем скачанный ранее релиз и скопируем файлы с него в созданную папку «drupal7». У вас должно получиться следующее:

Давайте перезагрузим Denwer для того, чтобы не было никаких непредвиденных ошибок. После этого открываем браузер, пишем в нем: http://localhost/drupal7 и начинаем установку Drupal.

На открывшейся странице установки выберите «Standard» и нажмите кнопку «Save and continue».

Нам предлагают выбрать язык, по умолчанию есть только английский. Чтобы добавить русский язык, нам нужно кликнуть по ссылке – Learn how to install Drupal in other languages.

Необходимо выполнить два шага для установки русского языка:

1. Скачать перевод со специального сервера переводов
2. И затем поместить скачанный перевод в папку: /profiles/standard/translations/

Скачиваем перевод, для этого переходим по ссылке – translation server.

На открывшемся сайте переходим на – Translations Homepage.

Скачиваем перевод для нужной нам версии.

Теперь перейдем в /profiles/standard/translations/ и скопируем в эту папку скачанный перевод.

Возвращаемся обратно к установке Друпал и обновляем страницу. Мы видим, что появилась возможность выбора русского языка. Выбираем «Russian (Русский)» и жмем «Save and continue».

Drupal самостоятельно проверяет все ли соответствует его требованиям, и если нет никаких замечаний, то переходит к следующему шагу – Установка БД.

В конфигурации базы данных необходимо вписать параметры базы данных, которую мы создали ранее. В типе базы данных выбираем – «MySQL, MariaDB или аналог» (1), в название базы данных пишем – drupal7 (2), имя пользователя БД у нас совпадает с названием базы данных – drupal7 (3) и указываем пароль к базе данных (4). Дополнительные настройки оставим без изменений. И нажимаем кнопку «Сохранить и продолжить».

Начинается процесс установки Drupal.

После установки происходит импорт переводов интерфейса. Дожидаемся окончания и перед нами появляется страница с настройками сайта.

Здесь нужно ввести общую информацию о сайте. Придумываем название сайта (1), указываем e-mail адрес сайта (2), имя пользователя отличное от admin, так как admin лучше не использовать в целях безопасности (3), e-mail адрес для администратора присвоится такой же, как и в настройках сайта выше (4) и пароль как можно сложнее, это повысит безопасность сайта (5).

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

Как только вся нужная информация заполнена, нажимаем «Сохранить и продолжить».

Теперь вы можете перейти на свой сайт кликнув по ссылке – Войти на свой новый сайт.

И в открывшемся окне вы увидите главную страницу сайта.

На этом установка Друпал закончена и можно приступать к дальнейшему изучению движка.

Зарождался друпал в далёком 1999 году, а активно развиваться начал уже с 2001 года. В настоящее время последней версией системы является восьмая. На начало 2015 года восьмая ветка ещё проходит бета тестирование, но уже вполне пригодна для разработки сайтов. Седьмая версия весьма стабильна, но мы не будем ориентироваться на неё, а пойдём в ногу со временем. Итак, Drupal 8. Восьмая версия имеет значительные отличия от 6 и 7 версий. Как в административном интерфейсе, так и в написании модулей. Многие вещи уже есть в ядре. Некоторые из них вошли ещё в седьмую версию системы, какие-то решили включить лишь в восьмой версии. В настоящее время на восьмёрке работает уже порядка 4500 сайтов. На той же семёрке немногим более миллиона. Ещё 150 тысяч на шестёрке и 1.170.000 на более старых версиях движка. Полная статистика здесь https://www.drupal.org/project/usage/drupal Drupal уникален тем, что на его основе можно собрать фактически любой сайт. Например визитку, интернет магазин, каталог, доска объявлений, блог или даже социальную сеть. Скажу честно-неподготовленному пользователю, даже с серьёзным опытом программирования или опытом работы с другими CMS, разобраться в друпале будет сложно. У него достаточно высокий порог вхождения. Но, думаю вы не испугаетесь. На этом всё. Больше не будем углубляться в теорию, а посмотрим как же это всё работает. В ключевых моментах я дам точные определения различных сущностей и объясню для чего они предназначены и как их можно использовать в реальных задачах. Начнём с установки системы на сервер. Это может быть как локальный сервер, так и сервер в интернете. Скажу сразу-друпал достаточно требователен к ресурсам сервера, в частности к оперативной памяти. Для Drupal 8 нужно минимум 128Mb ОЗУ . Но, чем больше-тем лучше. Я буду вести разработку на VPS под управлением Debian 7. Друпал так же вполне работает под Windows. Вы уже должны знать, как создать домен и базу данных, в нашем случае это будет MySQL. Скачиваем последнюю версию друпала тут https://www.drupal.org/project/drupal Я скачиваю 8.0.0-beta7 Вы можете скачать в zip архив и распаковать на локальной машине. Если используете сервер-лучше качать в tar.gz и распаковывать(командой tar xvzf archive.tar.gz) уже на сервере, используя протокол SSH. Будьте внимательны - в папке с сайтами(обычно /var/www) должна быть папка сайта и в ней листинг файлов друпала Я создал БД с именем dr8_test, а так же пользователя dr8_user Открывайте сайт в браузере. Если вы всё сделали верно - то попадёте на адрес core/install.php Хочу обратить ваше внимание-что в восьмёрке стандартная тема свёрстана адаптивно и отлично адаптируется под любые разрешения экранов.
Систему можно сразу ставить на русском языке. В шестой и даже седьмой версиях локализация проводилась вручную или с помощью специальных модулей. Я выберу русский язык. Я сразу же столкнулся с ошибкой "The translations directory does not exist.". Установщик сразу подсказывает как её решить "Create the directory sites/default/files/translations .". Важно! При работе с сайтом вы можете загружать файлы в директорию sites/default/files. Модули нужно складывать в sites/default/all/modules и темы в sites/all/themes. Создаём папку translations в директории sites/default/files. Папки files в sites/default тоже нет - создадим и её. Папки files и translations должны иметь права 777. Если создали папку-то выбираем стандартный профиль и продолжаем установку:
Я получил ещё 2 ошибки "The Файл настроек does not exist." и "The Services file does not exist."
Для решения первой проблемы нужно создать копию файла sites/default/default.settings.php и назвать её settings.php. Дать права 777. Если вы работаете на сервере и у вас под рукой консоль - можете использовать данные команды, находясь в корне сайта: Вторая проблема решается аналогично, только с файлом services.yml. Я так же приведу листинг команд. Обе ошибки ушли и на следующем шаге необходимо ввести данные для доступа к БД. Дополнительные настройки оставляем по-умолчанию. Некоторые хостинги имеют хост базы данных отличный от localhost, так что не забывайте об этом.
Пошел процесс установки. Устанавливаются модули ядра.
Что стоит знать о модулях. Модуль - это некий функциональный блок, который выполняет ту или иную функцию. Например позволяет комментировать материалы, даёт возможность оценить материал по пятибальной шкале, транслитерирует адреса, подгружает блоки аяксом и огромное количество другого функционала. Модули могут зависеть друг от друга. Например 1 модуль может требовать для включения ещё 5 других модулей, некоторые из которых могут требовать другие модули. Придётся их все скачать и включить. Все модули и темы хранятся на официальном сайте http://www.drupal.org . Они все бесплатны. Модули не имеют обратной совместимости. То есть модуль, написанный для 8 версии движка, будет работать только с ядром восьмой версии. Для семёрки нужен модуль, написанный под 7 версию. С шестёркой аналогичная ситуация. Тоже самое касается и тем. Исключение составляют лишь библиотеки, но только благодаря тому, что это сторонние скрипты и пишутся не под друпал. Если вы скачали модуль и положили его в папку sites/all/modules - то модуль ещё не будет работать, его ещё надо включить, но об этом позже. Ненужный модуль нужно выключить, потом удалить и лишь после этого можно физически удалить папку с модулем. Ну вот все модули установились и друпал выдал сообщение "Все необходимые изменения в sites/default и sites/default/settings.php были выполнены, но вы должны удалить разрешение на запись в них в целях безопасности." Отнестись к этому нужно со всей серьёзностью. Файлам sites/default/settings.php и sites/default/services.yml выставляем права 444, то есть только чтение. На завершающей странице задаём название сайта, а так же логин и пароль администратора. Далее идёт завершение установки и можно лицезреть установленный сайт.
На этом установка сайта завершена.

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

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

Но хотел бы отметить, что популярность эта, в основном припадает на западную часть интернета. Что же касается рунета — то первые места в рейтингах CMS делят между собой такие всем известные платформы как Joomla и WordPress, что, на мой взгляд, не совсем справедливо по отношению к рассматриваемой нами. И причина этого — проста и банальна – Drupal не совсем удобна и привычна в плане работы и использования обычными пользователями. То есть, когда сайт разрабатывается – он используется непосредственно разработчиком, но по завершении работы, дальнейшее использование переходит непосредственно заказчику и здесь могут быть сложности. Так как юзабилити CMS, несколько не привычно, но хотел бы Вас заверить, что это только на первый взгляд. Вы в скором времени сами убедитесь,то пользовательский интерфейс вполне приемлем и даже и крайне удачно реализован.

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

Теперь, собственно, давайте поговорим о том как установить drupal 8. Для начала, переходим на официальный сайт разработчика по ссылке .

Тем самым мы переходим в раздел загрузок. Нам необходимо, для начала, скачать только ядро, а значит, используем соответствующую кнопку “Download Drupal 8.2.6” (на момент написания текущей статьи последняя актуальная версия 8.2.6).

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

На данном этапе хотел бы заметить, что для работы CMS Drupal необходим веб-сервер, интерпретатор языка PHP, а так же сервер системы управлениями базами данных Mysql. Данные компоненты Вы, конечно же, можете установить отдельно и выполнить их конфигурацию, но для этого нужно обладать соответствующим набором знаний. Или же Вы можете использовать готовые сборки, то есть программные продукты, в которые все выше перечисленные компоненты установлены и настроены для работы. Это могут быть такие программы как OpenServer, Denver, Xampp и т.д, то есть все зависит от Ваших предпочтений. Я привык работать с OpenServer, а значит в каталоге domains, я создал папку dru.loc, в которую и скопировал исходники CMS (в распакованном виде).

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

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

При этом первый этап – выбор языка будущего сайта, соответственно интересующая локализация будет загружена во время установки. Выбрав необходимый – кликаем “Save and continue”.

Второй этап – это выбор режима установки – стандарт или же минимальный. Здесь стоит выбрать стандарт, так как он предусматривает начальную настройку после установки системы, что очень полезно.

Следующий этап проверка совместимости Вашей системы на соответствие минимальным системным требованием CMS, полный перечень которых приведен на странице документации .

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

Следующий этап предварительная установка и импорт переводов.

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

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

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

Итак, Друпал 8 установлен что дальше, можете спросить Вы. Далее необходимо приступать к изучению самой CMS, то есть Вы сейчас, на пороге огромнейшего небоскреба, который еще предстоит исследовать. Но так как Вы уже знаете как установить друпал 8 – значит, Вы сделали хоть и небольшой но уверенный шаг и вошли в первую дверь,а значит не останавливайтесь и смело идите вперед.

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

На этом данная статья завершена. Всего Вам доброго и удачного кодирования!!!

image/svg+xml

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

Вариантов на данный момент уже явно много, но я выделяю всего два:

• Стандартный - официальный вариант установки ядра из архива скаченного с drupal.org.
• Composer Drupal Project - установка и управления ядром полностью через composer.

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

Мой опыт работы с Drupal 8, заставляет меня делать очень неоднозначный вывод. Стандартный вариант установки - непрактичный, имеет недостатки, особенно для новичков, и проблемы с composer. С ним приходиться больше бороться и воевать, а преимуществ, как таковых, нет.

Плюсы и минусы вариантов

Стандартный способ

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

Drupal, как минимум с 7-ой версии, позиционируется как CMF решение. То есть, это некая золотая середина между CMS и чистыми фреймворками. Если у Drupal 7 был перевес в сторону CMS, то Drupal 8 ещё сильнее перевешивает в сторону фреймворков. И сторонние зависимости от Symfony ещё сильнее его туда склоняют. Исходя из этого, я выделяю следующие минусы.

• Минусы
  • Самый фатальный недостаток, который и является следствием всех проблем и остальных минусов - то что composer внедрили после релиза Drupal 8, в Drupal 8.1. Получилось так, что структура проекта уже сформировалась и люди уже держали продакшен сайты на 8-ке. Но данная структура совершенно неудачное решение для такого уровня CMS. Именно поэтому все проблемы с composer на данном варианте и возникают. Конфликты версий, проблемы с зависимостями, потерянные файлы - всё это отсюда, потому что всё в куче.
  • Структура для такого уровня CMS просто напросто неудобная. Drupal 8 нам принес не только новую цифру в версии? и какие-то API и фишки, он также полностью меняет процесс разработки сайтов на Drupal в сравнении с Drupal 7, а структура, при этом, осталась прежней с косметическими изменениями.
  • Drupal 8 полностью крутится вокруг конфигураций. Конфигурации можно смело отнести в разряд кодовой базы. Это самые обычные YAML файлики, но при этом, они содержат кучу важной и приватной информации. Такие файлы ни в коем случае не должны быть доступны из сети по запросу. К сожалению, структура такого подхода делает данный момент максимально уязвимым. Конфиги, как вы ни крутите, будут лежать в пределах вебрута проекта, вся надежда на то, что.htaccess отработает корректно и вы его не потеряете, а если у вас NGINX, то вообще, если сами не проконтролируете, они из коробки будут качаться у вас. Такие файлы хранить в вебруте и ниже по иерархии - не нужно. Но выбора тут у нас нет.
    • ? Вы и сами можете проверить. Попробуйте запросить любой конфиг файл из проекта прямым запросом: http://example.com/sites/default/files/config_XYZ/sync/automated_cron.settings.yml (XYZ замените на ваш хэш, и если у вас конфиги экспортируются не в sites/default/files/config_XYZ, на новый путь). Скачался? Это очень тревожный звоночек. А что если эти XYZ узнаеет третье лицо? А если вы поменяете путь на какой-нибудь sites/default/config/sync, где даже XYZ знать не надо? А это очень популярный способ экспорта конфигов. Конфиги имеют стандартное именование у всех сайтов, и если у вас магазин, например, подогнать название конфига от какой-нибудь платежной системы или друго сервиса, и скомпрометировать ваши API ключи, не составит труда. Очень много если, и ни одной причины держать их открытыми для загрузки, НИ-О-ДНО-Й.
  • Аналогично и с зависимостями Composer. vendor директория находится в вебруте проекта. По умолчанию она хорошо защищена и часть файлов при установке оттуда удаляется. Но сторонние зависимости надо контролировать руками и слепо верить им, или проверять в ручную. Но вы сами то в это верите, что вы будите проводить аудит безопасности всех зависимостей которые у вас скачаются по ходу развития проекта, как вами, так и контриб модулями и т.д. там по цепочке зависимостей? Там могут быть совершенно неочевидные пути к взлому, все это, как минимум, компрометирует инфомрмацию о внутреннем устройстве проекта. И опять же, нет ни одной причины их держать открытыми в веб. Как по мне, это плохая практика. Посмотрите на структуру проекта Symfony или Laravel . А это, на минуточку, одни из топовых фреймворков, у которых управление зависимостями также построено на composer и они активно используют YAML конфигурации. Видите где у них index.php, а где конфиги и vendor? Захотите повторить - получится composer drupal project.
  • Возможно вы используете или собираетесь использовать данный способ как способ избежать взаимодействия с Composer, или свести её к минимуму. Возможно, вы сведете, на старте. Но когда у вас начнутся проблемы и конфликты версий, вы в итоге потратите больше времени на решение проблем и возню с ним. Вы не избежите композера никак.

Composer Drupal Project

• Плюсы
  • От композера вы не убежите, он вас нагонет. А дальнейшая интеграция Drupal и Composer будет только усиливаться. Если же это неизбежно, проще сразу вести проект полностью на нем. Это решит проблемы в будущем, и текущие проблемы. У вас не будет каши, когда часть модулей стоит с drupal.org руками или ещё как, а другая через композер. Проще все вести в композере, зачем вам такой бардак на проекте? И это я не беру во внимания побочные плюсы самого композера, типа лока версий, автопатчинг, и возможность подключать свои приватные репы для обновления кастом модулей.
  • Структура файлов тут немного отличается от оригинальной. Тут появляется всего один новый уровень в иерархии, и это решает все минусы стандартного подхода. vendor и конфигурации тут находятся за пределами webroot проекта, а следовательно, эти файлы не доступны по прямому запросу, никак, вообще. Если вы сами не напишите контроллер который будет их отдавать. И не важно уже, apache у вас или nginx, потеряли вы.htaccess файли или нет, до них просто физически не добраться. Помните пример на проверку выше? Тут даже примера быть не может, так как данные файлы находятся на уровень выше вебрута. Если бы такое можно было писать, то было бы так: http://example/../config/sync/automated_cron.settings.yml. Но такой возможности нет, а следовательно, вы как в танке.
  • Такая структура также очень приятная если вы захотите сделать приватную файловую систему. Опять же, её можно положить в корень проекта, и она автоматически защищена от прямого запроса. Приватную файловую систему рекомендуется выносить за пределы вебрута, тут это будет за пределами и внутри проекта. На стандартном проекте, с 99.999% вероятностью она будет у вас в пределах вебрута. Так как вынести её за пределы? дело очень веселое и повлечет за собой множество проблем. И опять, придется заботиться как бы файлы оттуда не начали качаться по прямому запросу. А тут создали и забыли. Оно просто работает.
  • Репозиторий проекта максимально чистый. Из-за данной структуры и того, что она решает проблемы с композером, как минимум. Вам не придется держать в репозитории ядро друпала, что придется делать с очень высокой вероятностью на стандартном подходе, так как композер качает ядро на стандартном подходе как повезет. В итоге в вашем репозитории окажутся только кастомные темы, модули, а также файлы что вы положите, окружения, докер файлы и вот это вот всё. Никаких контрибов, ядра и зависимостей там не будет.
• Минусы
  • Самый страшный минус. ? Из-за того что вебрут находится на уровень ниже, то на хостингах и VPS, с 99% вероятностью потребуется легкая настройка. Как правило, просто в настройках сайта\домена меняется настройка индекс файла с index.php на web/index.php. Делов, не более чем на 5 минут на 1 раз.
  • Это не минус, больше рекомендация. С данным подходом очень желательно начать пользоваться git для деплоя изменений. Иначе из него будет не выжать максимум. Деплоить изменения гитом и композером на такой структуре просто кайф.

Вывод

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

Например, модуль Swift Mailer используется для отправки html писем, очень полезный и нужный. Попробуйте его установить и завести без композера. По факту то поставить можно, но это займет, скорее всего, часы в первый раз, а затем, любое обновление\изменение композера или модуля - опять семь кругов ада и это даже близко не пара минут даже с опытом. Или Drupal Commerce . В общем, композер вас догонит, как ни крути, да ещё пнет так, что сами не рады будите. Именно поэтому, многие новички могут посмотреть на это, и сказать - "Drupal говно!". К сожалению, они так могут и не понять почему у них столько проблем. И причина тут не в композере, и не в новичках.

Composer - это круто и удобно, но то как он работает и приготовлен в ядре из коробки, вызывает ненависть к нему. Мысль о том, что что-то вы делаете не так, все равно начнет со временем расти у вас в голове, отчасти это проблема ядра, и решение поискать другие варианты установки или ведения проекта на Drupal может быть совершенно неочевидным решением, особенно для новичков. Поэтому этот материал и есть, а также есть composer drupal project.

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

Установка

Стандартный способ

1. Заходим на страницу с ядром.
2. Качаем актуальную версию в виде архива.
3. Распаковываем в webroot вашего проекта.
4. Устанавливаем.

Корень проекта, он же вебрут выглядит так.

А теперь небольшой обзор, в чем же их отлчие. По факту, всем чем отличается стандартный подход от composer drupal project в том, что, то что в composer drupal project находится в web, находится в корне проекта на стандартном варианте. index.php и обработка запросов будет из web/ папки. А всё что выше её в иерархии - недоступно из сети прямым запросом, а это drush, scripts, vendor директории, в дальнейшем там будет и config директории для конфигов, и какая-то папка для приватной файловой системы, если потребуется.

Корень проекта у вас там где composer.json, а вебрут в web. Вот и вся разница. Никакой магии, всё просто и понятно. В web у вас будет абсолютно вся та же структура сайта на Drupal, как и в стандартной установке. Вот только потенциально опасные папки на уровень выше. И это решает все проблемы с композером и безопасность.

• Данный проект запрещает по умолчанию качать модули и темы через drush, на попытку запроса загрузки модуля будет выдана ошибка с напоминанием, что данный проект ведется композером, и чтобы скачать PROJECTNAME надо использовать composer require drupal/PROJECTNAME .
• composer.json немного модифицирован для вашего удосбтва. Он умеет докачивать index.php, robots.txt, update.php и прочие файлы из корня стандартной установки в web директорию. Чего не умеет ядро из коробки! ? И всё это настраивается! Даже web папка необязательна, правите composer.json где web, например, на public, и всё будет там. Только не забудьте написать composer update и перенести кастомы с файлами если проект уже рабочий.
• Некоторые модули указывают библиотеки через композер типа drupal-library . Стандартный вариант установки не распознает их, а этот установит в web/libraries/{name}.
• После установки данного варианта, он автоматически создаст вам settings.php и настроит чтобы конфигурации были в../config/sync . То есть в корне проекта, но за пределами вебрута, как и vendor.

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

Миграция из одного варианта в другой

Лучше посмотреть видео, где это продемонстрировано наглядно. Таймкоды: 52:02 и 1:02:29.

Будьте аккуратны, не забывайте делать бэкапы.

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

Что нужно чтобы сделать миграцию из одного варианта в другой (в обоих случаях):

1. Сделать бэкап кодовой базы, вообще отдельную копию для удобства. Из него будем копировать в актуальную папку проекта.
2. Удалить актуальную кодовую базу проекта. Базу данных трогать не нужно, у них всё идентично.
3. Закинуть чистое ядро для варианта, в который будет миграция.
4. Отредактировать composer.json - самое важное require раздел, а также всё что было добавлено руками: патчи, репозитории, настройки плагинов, скрипты, команды.
5. Перенести файлы /sites/default/files
6. Перенести все кастомные модули и темы в новый проект. Если контриб модули и темы ставились руками, то переносите руками.
7. Перенести settings.php и скорректировать путь до конфигураций.

Миграция из стандартного варианта в composer drupal project

1. Качаете composer drupal project любым из вариантов.
2. Отредактируйте composer.json. Для этого переносите все что было добавлено вами, а также все зависимости из require. Не нужно копипастить всё, файлы сильно отличаются.
3. Перенесите файлы из /sites/default/files в /web/sites/default/files.
4. Перенесите все кастомные модули и темы в /web/modules/custom и /web/themes/custom, соответственно. Если контриб модули до этого качались руками, то запросите их через композер: composer require drupal/PROJECTNAME . Если вы решиле вести проект на данном варианте, только так, и никак иначе.
5. Копируете /sites/default/settings.php в /web/sites/default/settings.php. Затем находите старый вариант $config_directories["sync"] и ставите значение "../config/sync" .

Теперь можно зайти на сайт, и всё заработает. Для надежности можно сбросить кэш.

Миграция из composer drupal project в стандартный вариант

1. Сделайте полный бэкап кодовой базы.
2. Удаляете все что было в папке проекта.
3. Качаете архив с ядром и распаковываете в корень проекта.
4. Отредактируйте composer.json.
   1. Для этого переносите все что было добавлено вами, а также все зависимости из require. Не нужно копипастить всё, файлы сильно отличаются.
   2. Удалите или оставьте зависимости, которые ставит для вас composer drupal project: cweagans/composer-patches , drupal-composer/drupal-scaffold , drupal/console , drupal/core (в стандартной установке он не должен быть в require), drush/drush , vlucas/phpdotenv , webflo/drupal-finder , webmozart/path-util . По сути, всё кроме composer-patches можно смело удалять. В зависимости от того как вы используете Drush и Drupal Console, решите сами, оставить или нет.
   3. Возможно, вам также потребуется перенести extra.installer-paths настройку "web/libraries/{$name}": ["type:drupal-library"] , только поменяйте путь на "libraries/{$name}": ["type:drupal-library"] . Если у вас не успели появиться такие зависимости на проекте, то, можно в принципе и не добавлять. В ядре её нет.
5. Перенесите файлы из /web/sites/default/files в /sites/default/files
6. Перенесите все кастомные модули и темы в /web/modules/custom и /web/themes/custom, соответственно. Вы можете продолжать управлять контриб модулями и темами через композер. Решайте сами. Можете удалить такие зависимости и закинуть их руками. Главное не потрите те модули, что ставятся исключительно композером.
7. Копируете /web/sites/default/settings.php в /sites/default/settings.php. Затем находите старый вариант $config_directories["sync"] и ставите значение "sites/default/files/config_XYZ" , где вместо XYZ поставьте какой-нибудь очень длинный хэш. Или настройте куда хотите, главное не забудьте позаботиться о защите этой папки.

Всё чаще стали предлагать работу на Drupal 8, а я ещё толком за него и не брался. Дай думаю для начала создам свой профиль и переведу блог на восьмёрку, благо совсем недавно вышла версия 8.4.

Начать решил по традиции с скрипта автоматической установки. Уже вбив в sh файлик заветное drush dl drupal вспомнил, что для восьмёрки нужен свежий Drush, несовместимый с версией для Drupal 7. Иду на drush.org → Docs → Install и вижу:

Проблема 1: друпал нельзя скачать с помощью Drush

Сайт встречает заметной плашкой:

Drush 9 only supports one install method. It requires that your Drupal 8 site be built with Composer and Drush be listed as a dependency.

Т.е. друпал должен быть установлен с помощью Composer, а Drush добавлен локально в качестве зависимости. Глобальная установка не поддерживается, но есть отдельная утилита drush-launcher , которая по сути просто перенаправляет команды в vendor/bin/drush .

Вспоминаю о Drupal Console:

Проблема 2: CLI утилиты теперь две

Существует альтернатива Drush под названием Drupal Console . Первоначально она задумывалась как код-генератор, но сейчас по факту клон Drush.

Что же выбрать? Мои фоловеры в твиттере предпочитают Drupal Console . Я пожалуй теперь буду тоже. Хотя ничто не мешает установить и то и другое.

И Drupal Console тоже можно установить только локально...

Ладно, двигаюсь дальше. Гуглю "drupal install composer". Вторая же ссылка ведёт на официальную документацию , где и правда советуют ставить друпал с помощью композера. Но:

Проблема 3: установка через Composer возможна тремя различными способами

Для скачивания друпала предлагается на выбор три варианта:

1. composer create-project drupal-composer/drupal-project
2.
3. с помощью утилиты

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

Основные отличия кроются в организации каталогов. В drupal-composer/drupal-project и hussainweb/drupal-composer-init папка vendor вынесена за пределы web root, что требует дополнительной настройки сервера.

Остановится решил на втором способе (как выяснится позже - ошибочно), чтобы результат был похож на оригинальный дистрибутив друпала. Выполняю в консоли composer create-project drupal/drupal . Друпал скачался, один в один, как в дистрибутиве.

Подобный подход позволяет забыть о ручном копировании дополнительных библиотек, требующихся для работы некоторых модулей. Композер сам скачает/обновит все зависимости. Раньше таким занимался drush make.

А sandbox модули ставятся так же просто? Нет:

Проблема 4: sandbox модули ставятся через костыль

Друпаловский композер-репозиторий packages.drupal.org ничего не знает о sandbox-ах. Это значит, что для установки каждого sandbox модуля, нужно дополнительно добавлять в composer.json соответствующий git-репозиторий:

composer config repositories.modulename git "https://git.drupal.org/sandbox/username/123456.git" composer require drupal/modulename

Сразу встаёт вопрос - как же обновлять всё это добро? Простое копирование затрёт изменённые файлы композера и возможно положит сайт. Документация однозначного ответа не даёт, описана только процедура обновления модулей : composer update drupal/modulename --with-dependencies , про обновление ядра пусто. Лезу в гугл. Везде советуют composer update drupal/core --with-dependencies . Ок, выполняю и:

Проблема 5: из коробки невозможно обновить Drupal с помощью Composer

Композер ругается:

Package "drupal/core" listed for update is not installed.

Пакет drupal/core добавлен в composer.json в секцию replace , поэтому его нельзя обновить с помощью композера. Гуглю, попутно бомблю в твиттер . Нахожу статью Troubleshooting Composer и мою проблему. Советуют изменить composer.json и перенести пакет drupal/core из секции replace в секцию require . Но:

Проблема 6: composer не может удалять пакеты из секции replace

В композере нет команды для удаления пакета из секции replace . Поможет только ручная правка composer.json .

Вручную, так вручную. Удаляю "drupal/core": "^8.4" . Выполняю composer require drupal/core . Всё отлично, ядро теперь можно обновлять. Главное не забыть после обновления файлов запустить update.php или выполнить vendor/bin/drush updb .

Как обновить сразу всё - ядро и модули? На drupal.org не советуют, но по идее composer update . Выполняю и:

Проблема 7: "composer update" обновляет зависимости ядра даже когда этого не надо

Composer update обновляет зависимости ядра, даже когда само ядро ещё не обновилось, т.е. оно с ними не оттестировано и теоретически могут возникнуть трудновоспроизводимые проблемы.

Проблема 8: файлы вне папки core не обновляются

Файлы index.php , robots.txt и другие, которые не находятся в папке core , не обновляются при вызове composer update drupal/core или даже composer update .

Проблема решается установкой очередного композер-модуля drupal-composer/drupal-scaffold : composer require drupal-composer/drupal-scaffold .

По умолчанию модуль будет выкачивать все файлы из дистрибутива, которые находятся вне папки core , в том числе robots.txt и .htaccess , что нежелательно. Чтобы ограничить список файлов, нужно изменить опцию . У композера есть команда для изменения настроек в секции extra, но:

Проблема 9: composer не умеет сохранять массивы в качестве значения опции

В extra.drupal-scaffold.excludes нужно сохранить массив файлов. Команда composer config этого сделать не может.

Вручную добавляем в секцию extra :

"drupal-scaffold": { "excludes": [ ".htaccess", "robots.txt" ] }

Теперь при обновлении версии ядра друпала, будут обновляться "scaffold" файлы, за исключением .htaccess и robots.txt .

Проблема 10: при обновлении композер не может разрулить конфликты

При попытке выполнить composer update он начнёт выдавать