When installing from an installation profile, the installer checks module requirements. If the public files directory is missing, it is created. When installing from a recipe, we get a warning instead:
Security warning: Couldn't write .htaccess file. Create a .htaccess file in your public:// directory which contains the following lines:
drupal_cms_helper module.drush site:export.sites/default/files.drush si ../recipes/site_export.Check module requirements when installing from recipe or config.
| Comment | File | Size | Author |
|---|
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
darren ohI have provided a fix. I am not interested in writing tests or arguing about which files should hold the code.
Comment #4
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #5
kieran.cottinstall.incandinstall.core.incseem like reasonable choices, and the fix resolves the issue for me after reproducing the error locally.I've tweaked the logic a bit - config and recipe install modes should probably be checked before falling back to profile requirements, otherwise existing-config installs with a profile can still miss requirements from modules listed in
core.extension.yml.Also added some kernel test coverage and addressed the PHPCS/Stan failures.
Comment #6
kieran.cottComment #7
nicxvan commentedI think the recipe and install maintainers will need to weigh in.
Also I'm not sure what to say about comment 3.
Drupal core is meant to be collaborative and I'm not sure if questions are welcome here.
Comment #8
darren ohComment 3 just means my part of the collaboration is done. I don't have more time for this issue. If someone thinks more work needs to be done, that's their job.
Comment #9
smustgrave commentedJust going to post this https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... as both comments #3 and #8 seem to be non collaborative, openly hostile, and frankly just rude.
Core maintains a number of gates/checks that must be passed, see https://www.drupal.org/about/core/policies/core-change-policies/core-gates. So test coverage will be needed.
Comment #10
benjifisherAt the risk of putting words into someone else's mouth, ...
IMO, Comments #3 and #8 were, if anything, badly worded. I do not read them as non collaborative. Would it be seen as rude if the comments were worded like this?
Or maybe "I do not have time" instead of "I am not a Drupal developer".
Thanks to kieran.cott for picking up where darren oh left off. It looks like collaboration to me.
Comment #11
kieran.cottI've expanded the kernel test coverage in MR !16049 to verify that:
- Config and recipe installs recreate a missing public-files directory through the system module’s install requirements.
- Module requirements from nested recipes are checked.
- Config requirements are checked independently of profile requirements.
- Invalid recipes are deliberately ignored during requirement checks.
I see functional JS pipelines are failing - though this does not seem to be related to any work here?
Comment #12
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #13
kieran.cottMR 16049 now brought up to date with
main.Pipelines pass.