Join Log in
Score:0
phep avatar Drupal

CSS, JS, ... not created by drush site:install

gq flag
phep

Drupal installation is failing after the following steps on a Debian box (database is already created and privileges granted to specific user):

(user) $ composer create-project drupal/recommended-project myproject
# ... ask if it is OK to install composer/installers, drupal/core-composer-scaffold and drupal/core-project-message, answer Yes 
# ... emits 2 warnings about doctrine/reflection and webmozart/path-util being obsolete
(user) $ cd myproject
(user) $ composer composer require drush/drush
(user) $ drush site:install --locale=fr
# ... asks for MySql credentials
# ... displays admin user credentials.

Everything runs smoothly with no error messages, only the 3 questions and 2 warnings mentionned supra.

Yet, after running those commands, according to Drupal installation docs (https://www.drupal.org/docs/develop/using-composer/using-composer-to-install-drupal-and-manage-dependencies#s-install-drupal-using-the-command-line) the site should be accessible through-the-web. Yet, when I browse the configured path (DocumentRoot is set to the "web" directory) I got an unstyled page (same appearance than CSS not applying in drupal 8 site , but stylesheets href are set to "/").

If I take the through-the-web installation path instead of running Drush, then everything runs fine except for minor annoyances with permissions settings under 'web/sites/default'.

Comparing both "web" directories shows that (besides unsignificant differences due to different hashes) no "css", "js", "languages" nor "php" directories are created and populated under the Drush installed "web/sites/default/files" directory.

What am I doing wrong? I could find no help in Drupal documentation nor by googling around.

  • Drupal : 9.3.9
  • Composer : 2.2.9
  • Drush : 11.0.7

Thanks in advance

52
0 + 0
cn flag
Clive
It's very likely to be permissions. You install with one user, then serve over the web with a different user who can't write to the folders the first user created as part of the install. Make sure `www-data` or equivalent can write to the files folders and the tmp folder
3
Reply
phep avatar
gq flag
phep
@Clive thank you for your comment but as stated in my question the problem only happens when the whole installation is run from the command line, obviously with the same user, hence no permission problem can possibly be involved. The common problem you describe relates to through-the-web install but this one runs fine in my case.
0
Reply
cn flag
Clive
How did you get an “unstyled page” through the command line? What you’ve described still strongly suggests a permission issue. Run `sudo -u www-data touch docroot/sites/default/files/test.txt` to make sure. If you get a perms error on that op, you’ve probably found the problem
1
Reply
phep avatar
gq flag
phep
@Clive I edited the question to try to make it clearer that the problem occurs when the installation is made with Drush invocation, not by going through "core/install.php". As stated, if I install by using the web interface I meet not substantial problems. Those happen when I use `drush site:install` instead. According to the documentation, running this command should equate to going the usual web process (I mean browsing to core/install.php, ... Is it more clear now?
0
Reply
ru flag
Hudri
Drush does not create any JS or CSS or cache files, this happens on demand by visiting pages in the browser. And if those are not created on demand, it is almost certainly due permissions. And even the web install *runs fine except for minor **annoyances with permissions settings under 'web/sites/default'***
1
Reply
cn flag
Clive
Yep, I wrangle with these setups day in day out, it's very familiar to me :) I think I see where the confusion is though - the css/js/php folders aren't generated by the site installation, they're generated by a subsequent web request. So you install through the web, the `files` folder is owned by `www-data`, and in the subsequent web request, `www-data` can write to that folder. When you install through CLI, `files` is owned by `foo_user`, then when the subsequent web request runs, `www-data` can't write to that folder because `foo_user` owns it
0
Reply
phep avatar
gq flag
phep
Thank you @Clive and @Hudri for taking time to answer, but could you please tell me then what is the use of running `drush site:install` at all if one still needs to go the `core/install.php` way after. I thought that drush would precisely let us install and configure a Drupal site in a scriptable and repeatable way.
0
Reply
cn flag
Clive
You've nailed it, that's exactly what `site:install` does - you don't need to visit core/install.php afterwards (indeed you can't, it'll tell you that the site is already installed). Unless this is an edge case based on something not visible in the context so far, the styles are almost certainly missing because the web server can't write to sites/default/files. I just posted an answer detailing both processes, hopefully that'll help to clear it up
0
Reply
leymannx avatar
ne flag
leymannx
Just for completeness: in both cases a .htaccess file exists in web/ and has the RewriteBase uncommented?
0
Reply
Score:0
avatar Drupal
cn flag
Clive

The folders you mentioned aren't generated by the site installation process, they're generated by a page request to the resulting Drupal site itself.

When you install through the UI, this happens:

  • Drupal gets installed
  • sites/default/files is created and owned by the web server (typically www-data)
  • You get redirected to the front end of the site, Drupal generates assets and tries to persist them to sites/default/files
  • The request is running as www-data, the folder is owned by www-data, so all good - files get created.

When you install through the CLI, it's slightly different:

  • Drupal gets installed
  • sites/default/files is created and owned by the user you ran drush as, which wouldn't typically be www-data (if it was, you shouldn't be having these problems).
  • You visit the site in a browser, Drupal generates assets and tries to persist them to sites/default/files
  • The request is running as www-data, but the folder is owned by your user, so no dice - files are not created.

High level, the answer is to make sure www-data can write to the sites/default/files folder after you install via the CLI. The Securing file permissions and ownerships docs have some suggestions on how you can accomplish this.

0 + 0
phep avatar
gq flag
phep
Could you please tell me exactly what you mean in the 3rd step of the CLI install process you describe when you say "You visit the site in a browser"? Do you mean any (site related) URL or some specific _end of the install URL_ one? And in this case, I repeat my question : what's the use of the Drush path? Thank you anyway, I appreciate you help.
0
Reply
cn flag
Clive
I mean literally any URL on the front-end of the site, not a specific one. When CSS/JS aggregation is enabled (as it is by default after install), the aggregated files are generated on demand when a page is visited, and cached from then. Your current issue seems to be that the aggregated files can't be written, and the steps you've outlined to get to this point support that idea
0
Reply
phep avatar
gq flag
phep
Thank you for your patience. A pity such basic clue is absent from Drupal docs. I have to admit that I had hitherto never crossed the path of a webapp that waits for the very first non-targeted / non authenticated connection to complete its installation process ;-).
0
Reply
cn flag
Clive
It gets away with it because asset generation is supposed to be dynamic, it's not part of the installation process. But I get what you mean, it's confusing if you haven't done it a hundred times before
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.