17 ноября 2022 в 17:55
Вроде всё делаю правильно:
/sites/default/settings.php
include $app_root . '/' . $site_path . '/settings.local.php';
}
/sites/default/settings.local.php
* Disable css and js preprocessing.
*/
$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;
/**
* Disable Render Cache and Dynamic Page Cache.
*/
$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';
/**
* Enable local development services.
*/
$settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.services.yml';
/**
* Enable access to rebuild.php.
*/
$settings['rebuild_access'] = TRUE;
/sites/development.services.yml
#
# To activate this feature, follow the instructions at the top of the
# 'example.settings.local.php' file, which sits next to this file.
parameters:
http.response.debug_cacheability_headers: true
twig.config:
debug: true
auto_reload: true
cache: false
services:
cache.backend.null:
class: Drupal\Core\Cache\NullBackendFactory
Но никаких комментариев в коде не отображается. Кэш, понятное дело, чистился неоднократно.
А вот если залезть прямо в ядро core/core.services.xml и там включить дебагер, то все сразу начинает работать. Но это неправильно. А почему не работает, когда правильно делаешь?
Комментарии
Попробуйте сделать по этой инструкции. Там всё намного проще. Ну и не забудьте сбросить кэш
По этой инструкции получилось. Но прежде drush cr ругнулся на отсутствие нужных прав к файлу services.yml. И тогда стала понятна причина, почему не получалось и с прежней схемой. Она наверняка тоже рабочая, просто на settings.local.php тоже не было нужных разрешений. Да и дебагер мне понадобился, чтобы понять, почему в моей кастомной теме не цепляется файл page.html.twig. Теперь понятно - на него тоже не было нужных прав... Я с удаленным сервером работаю, тут вероятно файлы по умолчанию создаются с какими-то урезанными правами.
Спасибо за помощь!
Возможно, вы просто заходите не под тем пользователем, от имени которого запускается php.
у меня есть только один пользователь - тот под которым я подключаюсь к удаленному серверу. Предположим, user1
Но если выполняю команду composer - то папки в проект записываются с другим владельцем (сисадмином, который мне выдал доступ). Предположим, user2. Править что-то в этих файлах - permission denied.
Если я создаю какие-то файлы/папки - они создаются с правами rwx------ и друпал их вообще не видит.
php запускается от www-data - это, как я понимаю, третий пользователь...
А еще есть группа docker, в которую добавлен user1, чтобы sudo не писать, работая с командами докера.
Как настроить права так, чтобы все работало как надо?
Что со всеми этими пользователями делать, чтобы забыть о permission denied?
В данной ситуации проще настроить отдельного пользователя для работы докера и под ним же логиниться в систему и выполнять команды. Так работает, например, docksal
в docksal это настраивается и где-то можно прочитать как? Или это из коробки уже работает?
Это из коробки. Но нужны права sudo для пользователя, чтобы запустить контейнеры, хотя сервисы будут работать от имени этого пользователя и проблем с правами не будет
получилось установить docksal, накатить друпал последнюю версию. Но дальше те же проблемы с правами, что и на d4d. Все файлы, которые создаю, создаются с правами rwx------ И друпал их не видит.
Вот кастомная тема /themes/custom/isp. На странице "Оформление" она появилась, но скриншота нет.
Пока вручную права не заменю (сначала у папки custom, потом у папки isp, потом у файла скриншота) - ничего не появляется. Но так невозможно работать.
Причем, модули, которые устанавливаю через композер - там все с правами норм. Также все норм, если через терминал создавать папки.
Плохо, когда работаю в смонтированной на винде папке с проектом.
Какой пользователь владеет файлами? От имени какого пользователя работает доксал? Почему на скриншоте винда?
На скрине винда, потому что каталог открыт через виндовый ftp-клиент.
Docksal установлен на линукс, но это удаленный сервер, доступ к нему через SSH на локальной машине, на которой винда.
Для доступа к удаленному серверу имеется пользователь user1. Он же является владельцем файлов и папок, которые создаются как вручную от имени пользователя, так и через композер.
От имени какого пользователя работает doсksal - не знаю. Как это проверить?
Папка проекта из линукса примонтирована как диск на винду. И проблема с правами (всё только для владельца) наблюдается только если создавать папки/файлы именно из винды. То есть открываю я в своем редакторе кода на винде вот эту примонтированную папку, создаю файлы и они имеют права rwx------
ну по идее от имени которого запускается команда fin p start
Ну вот и ответ. Не должно быть такого по умолчанию.
А через какой протокол она примонтирована? smb? ftp? sftp?
примонтирована с помощью пакетов WinFsp и SSHFS-Win. Последний использует SFTP
Проблему удалось решить установкой программы SSHFS-Win-Manager. В ней можно настроить права.