Drupal 8: Два варианта установки ядра
Блог

Drupal 8: Два варианта установки ядра

Стандартная установка с drupal.org и composer drupal project. В чём их отличие, плюсы и минусы. А также, как мигрировать из одного варианта в другой.
33 комментария
Опубликовано 29.06.2018
4 мин.
Drupal 8: Два варианта установки ядра
image/svg+xml

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

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

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

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

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

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

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

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

  • Плюсы
    • Официальный и стандартный вариант установки. Для кого-то это может стать очень важным решающим фактором.
    • Не требует никаких дополнительных знаний и подготовки. Достаточно скачать архив, распаковать его в 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

  1. Заходите на страницу проекта.
  2. Решаете как ставить, через git clone или composer create-project в корне проекта.
    1. git clone
      1. В корне проекта git clone https://github.com/drupal-composer/drupal-project.git .
      2. composer install.
    2. composer create-project
      1. В корне проекта composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction
      2. cp -r some-dir/. ./ && rm -rf some-dir/
  3. Устанавливаем.

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

А теперь небольшой обзор, в чем же их отлчие. По факту, всем чем отличается стандартный подход от 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. Сделайте полный бэкап кодовой базы.
  2. Удаляете все что было в папке проекта.
  3. Качаете composer drupal project любым из вариантов.
  4. Отредактируйте composer.json. Для этого переносите все что было добавлено вами, а также все зависимости из require. Не нужно копипастить всё, файлы сильно отличаются.
  5. Перенесите файлы из /sites/default/files в /web/sites/default/files.
  6. Перенесите все кастомные модули и темы в /web/modules/custom и /web/themes/custom, соответственно. Если контриб модули до этого качались руками, то запросите их через композер: composer require drupal/PROJECTNAME. Если вы решиле вести проект на данном варианте, только так, и никак иначе.
  7. Копируете /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
Drupal 8
небольшой уютный чатик

Комментарии

V
Vitaliy
вт, 07/03/2018 - 17:55

Спасибо за статью! Интересно больше узнать о данной теме: "Подключение своих приватных реп для обновления кастом модулей".

N
Niklan Vitaliy
вт, 07/03/2018 - 17:59

У меня такого опыта, к сожалению нет, но есть официальная документация, где все инструкции есть.

Надеюсь, @adubovskoy не обидится) Но можно спросить у него, или попросить написать статью как это у них организовано. Если ничего не путаю, они этой возможностью пользуются, и он как раз начал блог вести, так что сразу двух зайцев ?

В ближайшем будущем ковырять данную особенность композера пока не собираюсь, есть куда более интересные темы)

А
Алексей
вт, 07/31/2018 - 21:44

Здравствуйте! Не могу понять один момент. Пока устанавливал Drupal через composer понял, что он требует очень много оперативной памяти и его нужно использовать только на локальном хосте, а в продакшене использовать не надо. И у меня возник вопрос как тогда правильно проводить обновление сайта (ядро и модули) на рабочем сайте?

N
Niklan Алексей
ср, 08/01/2018 - 10:43

На дев-сервере, на локалке. Если ничего такого нет, ну что поделать, только на продакшене.

Особенность тут в том, что для обновления зависимостей композера не нужен сам проект (веб сервер со всеми файлами и БД) ?.

Достаточно на локальном компе, например, поставить php и composer. Выгружаете себе кодовую базу проекта через git, делаете composer update, коммитите изменения, пушите их в репозиторий, забираете на продакшене и вызываете composer install. На локалке оперативки должно хватить, а для composer install её даже на самом стремном хостинге хватит, так как никаких тяжелых операций там не выполняется и не парсятся репозитории.

А
Алексей Niklan
ср, 08/01/2018 - 12:33

Спасибо за ответ. Я с git ещё на Вы, но так понимаю что в ближайшее время надо освоить. Если я правильно понял то качаем файлы с рабочего сайта на локальный, запускаем composer update, затем возвращаем все на рабочий сайт и вызываем composer install. Запускаем скрипт обновления БД.

N
Niklan Алексей
ср, 08/01/2018 - 19:24

Да, всё верно.

Даже не то что файлы, по факту, будет достаточно composer.json + composer.lock. Если уж вообще по-минимуму. Есть свои ньюансы, поэтому лучше, конечно, кодовую базу проекта через гит качать и заливать. Файлов будет минимум и только те что нужны.

Т
Тарас
пн, 09/03/2018 - 16:19

Т.е. после установки Composer drupal project через git clone, установщика самого ядра запускать по урлу /web/install.php?

N
Niklan Тарас
пн, 09/03/2018 - 16:36

Нет. Как и у обычной установки, example.com/install.php.

В Composer Drupal Project docroot находится на уровень выше, в папке web, где и находится index.php. Это влияет на структуру проекта, но никак ни на работу сайта.

Т
Тарас Niklan
пн, 09/03/2018 - 20:28

но example.com/install.php - Not Found. по адресу example.com показывает список фалов и папок Composer Drupal Project ставил через Putty по SSH. И только если попробовать example.com/web/install.php идет переадресация на example.com/web/core/install.php и начинается установка, и сайт потом доступен по адресу example.com/web.)) Извините, если что, если мои вопросы тупы и примитивны))

N
Niklan Тарас
вт, 09/04/2018 - 08:14

В статье об этом указано и даже обращено на это отдельное внимание.

Либо веб-серверу нужно менять путь до index.php, чтобы он искался в web. Либо смещать директорию на уровень ниже.

Т
Тарас Niklan
вт, 09/04/2018 - 10:41

Спасибо, всё получилось. Невнимательно читал))) Начал изучать D8 и понял, что знания D7 мне не помогут))) Сейчас буду учиться ставить модули))) Еще раз спасибо и за статью и за ответы

С
Сергей Тарас
ср, 09/05/2018 - 19:06

Подскажите, как у вас получилось? Устанавливал Друпал при помощи Composer Drupal Project . Сайт на Апаче, добавляю в корень сайта .htaccess, в котором пишу DirectoryIndex web/index.php .

Вариант1 1. Устанавливаю сайт при помощи site.ru/web 2. Сайт открывается по site.ru, но в админке все ссылки на /web, логин - /web/user/login. Добавляю одну ноду, site.ru/node/1 - Not Found

Вариант2 1. Устанавливаю сайт при помощи site.ru - редиректит на /core/install.php - Not Found

N
Niklan Сергей
чт, 09/06/2018 - 07:14

Это должно разруливаться не на уровне .htaccess, а на уровне VirtualHost Apache. Где для домена указывается его docroot, там должно быть теперь окончание на web. Никакие манипуляции с ядром не требуются.

У хостингов обычно для этого есть опция в панели управления, где можно задать путь до index.php. Обычно там просто так и написано index.php, подразумевая что корень будет та папка, что создана хостингом под сайт. Но в случае с Composer Drupal Project надо будет указать web/index.php. Никакие изменения в .htaccess и иные файлы вносить изменения не требуется.

Если VPS, тут вообще должно быть все просто. Открываете VirtualHost апача для нужного сайта и меняете ему DocumentRoot. Например, если он указан как /var/www/example.com, то нужно будет поправить на /var/www/example.com/web.

Что касается NGINX, аналогично. Разруливается это на уровне его конфигов, а не настроек файлов друпала.

При любой ситуации, данный вопрос решается не средствами друпала, так как не ими и разруливается.

А
Алекс
ср, 09/19/2018 - 13:10

Здравствуйет, во первых списибо за полезную статью. Возможно ли в папке vendor создать полноценный кастомный модуль с контроллерами и т. д. или в vendor устанавливаются только библиотеки, а модуль должен находиться в папке modules? Спасибо.

N
Niklan Алекс
чт, 09/20/2018 - 07:11

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

Модули создаются в modules и нигде больше им места нет (хотя могут и заработать, но это не значит что это правильно).

А
Алекс Niklan
чт, 09/20/2018 - 11:09

Спасибо за ответ. Я в своем вопросе не уточнил, что модуль должен устанавливаться через композер в папку вендор. Тоесть я хочу чтобы мои кастонмые модули (полноценные с контроллерами и т. д. не только библиотеки) можно было установить через композер в venodr\my_company_name\my_module. На данный момент у меня есть тестовый модуль, если он находится в папке modules все ок, друпал его видит в админке в разделе Extend. Если я его устанавливаю через композер он попадает в вендор, но друпал уже его не видит в админке в разделе Extend

N
Niklan Алекс
чт, 09/20/2018 - 15:09

Модулям своим в их composer.json добавьте тип, либо drupal-module, чтобы они попадали в /modules/contrib, либо drupal-custom-module и добавьте в compoer.json проекта extra.installer-paths, если аналогичного ещё нет:

"modules/custom/{$name}": ["type:drupal-custom-module"],

Здесь про это отдельно расписано.

Д
Дмитрий
ср, 10/10/2018 - 07:07

Никита, я с вашей подачи уже почти год пользуюсь drupal-composer/drupal-project, но вы наверняка гораздо плотнее меня следите за прогрессом интеграции Композера в Друпал.

Не изменилась ли за прошедшее время ситуация со Scaffold files (drupal-scaffold)? Их обновлением так же надо заниматься отдельно или эту часть всё-таки как-то интегрировали в drupal-composer/drupal-project?

N
Niklan Дмитрий
ср, 10/10/2018 - 12:16

Я вообще ни разу с ним не работал напрямую. Он есть в зависимостях и работает. Обновляется с ядром и ладно. Так что да, зависимость ещё нужна, это типа скрипта для композера, но не обязательна и по факту разруливается все автоматически.

MK
Maksym Konovalov
пт, 10/19/2018 - 09:36

Спасибо за статью и блог в целом! Доступно и понятно все. Только у меня после установки drupal/project перестали устанавливаться libraries webform( Ставил раньше командой: drush webform-libraries-download

N
Niklan Maksym Konovalov
пт, 10/19/2018 - 10:34

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

С
Сергей
пт, 11/09/2018 - 18:07
  1. Подскажите, как при помощи composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction установить не последнюю стабильную, а определенную версию ядра? Например: 8.7-dev
  2. После установки методом composer drupal project теперь drush можно вызывать только через vendor/drush/drush/drush или vendor/bin/drush . Если устанавливать стандартным способом - вызывается простым drush. Решилось копированием vendor/bin/drush.bat -> vendor/bin/drush.php,bat
N
Niklan Сергей
сб, 11/10/2018 - 14:18
  1. Не пробовал, но скорее всего, нужно ядру указать 8.6.x-dev в composer.json и обновиться.
  2. В Linux просто юзается Drush Launcher и проблема самоустраняется для всех проектов. Для Windows там тоже есть инструкция по установке, так что попробуйте.
А
Андрей
ср, 01/30/2019 - 19:15

"...Как правило, просто в настройках сайта\домена меняется настройка индекс файла с index.php на web/index.php."

Лучше менять весь root. Например, для OpenServer c Apache: 1) в файле \openserver\userdata\config\Apache-PHP-7+Nginx-1.10_vhostn.conf меняем: было - root "%hostdir%"; стало - root "%hostdir%/web/"; 2) в файле \openserver\userdata\config\Apache-PHP-7+Nginx-1.10_vhosta.conf меняем: было - DocumentRoot "%hostdir%" стало - DocumentRoot "%hostdir%/web/"

П
Павел
ср, 05/01/2019 - 15:32

Здравствуйте! Установил Drupal-project на хостинг Beget с Linux При попытке установки тоже ругалось на то, что файл не найден. Проблему решил с помощью команды "ln -s public_html web" Но появилась другая проблема При попытке установить модуль через composer появляется ошибка http://prntscr.com/nj34rz

Может подскажете в чём может быть дело?

N
Niklan ikode
чт, 07/04/2019 - 10:14

Поидее, это просто путь до папки. Сильно зависит от откружения. На линуксах /tmp и есть папка. Это корневая системная папка для временных файлов, соответственно, друпал туда и пишет файлы перед тем как сохранить их.

i
ikode Niklan
пт, 07/05/2019 - 10:12

А в корне сайта располагать папку tmp (с настроенным .htaccess) большая угроза безопасности? P.S.: Благодарен за ответ.

N
Niklan ikode
вт, 07/09/2019 - 09:32

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