Puncte:0

CSS, JS, ... nu sunt create de drush site:install

drapel gq

Instalarea Drupal eșuează după următorii pași pe o cutie Debian (baza de date este deja creată și privilegiile acordate unui anumit utilizator):

(utilizator) $ compozitor create-project drupal/recommended-project myproject
# ... întreabă dacă este OK să instalezi composer/installers, drupal/core-composer-scaffold și drupal/core-project-message, răspunde da 
# ... emite 2 avertismente despre doctrină/reflecție și webmozart/path-util ca fiind învechite
(utilizator) $ cd myproject
(utilizator) $ compozitor compozitor necesită drush/drush
(utilizator) $ drush site:install --locale=fr
# ... solicită acreditările MySql
# ... afișează acreditările utilizatorului administrator.

Totul merge bine, fără mesaje de eroare, doar cele 3 întrebări și 2 avertismente menționate mai sus.

Cu toate acestea, după rularea acestor comenzi, conform documentelor de instalare Drupal (https://www.drupal.org/docs/develop/using-composer/using-composer-to-install-drupal-and-manage-dependencies#s-install-drupal-using-the-command-line) site-ul ar trebui să fie accesibil prin web. Cu toate acestea, când răsfoiesc calea configurată (DocumentRoot este setat la directorul „web”), am primit o pagină fără stil (același aspect ca CSS nu se aplică pe site-ul drupal 8 , dar foile de stil href sunt setat la "/").

Dacă iau calea de instalare prin web în loc să rulez Drush, atunci totul funcționează bine, cu excepția unor neplăceri minore cu setările de permisiuni sub „web/site-uri/implicit”.

Compararea ambelor directoare „web” arată că (pe lângă diferențele nesemnificative din cauza hashurilor diferite) nu există directoare „css”, „js”, „limbi” sau „php” creat și populat sub Drush instalat „web/sites/default/files” director.

ce fac greșit? Nu am putut găsi nici un ajutor în documentația Drupal și nici prin cautând pe google.

  • Drupal: 9.3.9
  • Compozitor: 2.2.9
  • Drush: 11.0.7

Mulțumesc anticipat

drapel cn
Este foarte probabil să fie permisiuni. Instalați cu un singur utilizator, apoi serviți pe web cu un alt utilizator care nu poate scrie în folderele create de primul utilizator ca parte a instalării. Asigurați-vă că `www-data` sau echivalentul poate scrie în folderele de fișiere și în folderul tmp
phep avatar
drapel gq
@Clive vă mulțumesc pentru comentariul dvs., dar așa cum am spus în întrebarea mea, problema se întâmplă doar atunci când întreaga instalare este rulată de la linia de comandă, evident cu același utilizator, prin urmare nu poate fi implicată nicio problemă de permisiune. Problema comună pe care o descrieți se referă la instalarea prin web, dar aceasta funcționează bine în cazul meu.
drapel cn
Cum ați obținut o „pagină fără stil” prin linia de comandă? Ceea ce ați descris sugerează în continuare o problemă de permisiune. Rulați `sudo -u www-data touch docroot/sites/default/files/test.txt` pentru a vă asigura. Dacă primești o eroare de perms pe acea operațiune, probabil că ai găsit problema
phep avatar
drapel gq
@Clive Am editat întrebarea pentru a încerca să fie mai clar că problema apare atunci când instalarea se face cu invocarea Drush, nu trecând prin „core/install.php”. După cum am spus, dacă instalez folosind interfața web, nu întâmpin probleme substanțiale. Acestea se întâmplă atunci când folosesc `drush site:install`. Conform documentației, rularea acestei comenzi ar trebui să echivaleze cu trecerea la procesul web obișnuit (mă refer la navigarea la core/install.php, ... Este mai clar acum?
drapel ru
Drush nu creează niciun fișier JS sau CSS sau cache, acest lucru se întâmplă la cerere prin vizitarea paginilor din browser. Și dacă acestea nu sunt create la cerere, este aproape sigur permisiunile datorate. Și chiar și instalarea web *funcționează bine, cu excepția **deranjamentelor minore cu setările de permisiuni sub „web/sites/default”***
drapel cn
Da, mă cert cu aceste setări zi de zi, îmi este foarte familiar :) Cred că văd totuși unde este confuzia - folderele css/js/php nu sunt generate de instalarea site-ului, sunt generate de o cerere web ulterioară. Deci instalezi prin web, folderul `fișiere` este deținut de `www-data`, iar în cererea web ulterioară, `www-data` poate scrie în acel folder. Când instalați prin CLI, `files` este deținut de `foo_user`, apoi când se rulează cererea web ulterioară, `www-data` nu poate scrie în acel folder, deoarece `foo_user` îl deține
phep avatar
drapel gq
Vă mulțumesc @Clive și @Hudri pentru timpul acordat răspunsului, dar vă rog să-mi spuneți atunci la ce folosește rularea `drush site:install` dacă mai trebuie să mergeți pe calea `core/install.php` după . M-am gândit că drush ne va permite tocmai să instalăm și să configuram un site Drupal într-un mod scriptabil și repetabil.
drapel cn
Ai reușit, exact asta face `site:install` - nu trebuie să vizitezi core/install.php după aceea (chiar nu poți, îți va spune că site-ul este deja instalat). Cu excepția cazului în care acesta este un caz limită bazat pe ceva ce nu este vizibil în context până acum, stilurile lipsesc aproape sigur deoarece serverul web nu poate scrie în site-uri/implicit/fișiere. Tocmai am postat un răspuns care detaliază ambele procese, sper că va ajuta la clarificare
leymannx avatar
drapel ne
Doar pentru a fi complet: în ambele cazuri există un fișier .htaccess în web/ și RewriteBase nu a comentat?
Puncte:0
drapel cn

Dosarele pe care le-ați menționat nu sunt generate de procesul de instalare a site-ului, ci sunt generate de o solicitare de pagină către site-ul Drupal rezultat.

Când instalați prin interfața de utilizare, acest lucru se întâmplă:

  • Drupal este instalat
  • site-uri/implicit/fișiere este creat și deținut de serverul web (de obicei www-data)
  • Sunteți redirecționat către front-end-ul site-ului, Drupal generează active și încearcă să le păstreze pe site-uri/implicit/fișiere
  • Solicitarea rulează ca www-data, folderul este deținut de www-data, deci toate bune - fișierele sunt create.

Când instalați prin CLI, este ușor diferit:

  • Drupal este instalat
  • site-uri/implicit/fișiere este creat și deținut de utilizatorul pe care l-ați condus drush ca, ceea ce de obicei nu ar fi www-data (dacă a fost, nu ar trebui să aveți aceste probleme).
  • Vizitați site-ul într-un browser, Drupal generează active și încearcă să le păstreze pe site-uri/implicit/fișiere
  • Solicitarea rulează ca www-data, dar folderul este deținut de utilizatorul dvs., așa că nu există zaruri - fișierele nu sunt create.

Nivel înalt, răspunsul este să te asiguri www-data poate scrie în folderul site-uri/implicit/fișiere după ce instalați prin CLI. The Securizarea permisiunilor și a dreptului de proprietate asupra fișierelor documentele au câteva sugestii despre cum puteți realiza acest lucru.

phep avatar
drapel gq
Ați putea vă rog să-mi spuneți exact la ce vă referiți în pasul 3 al procesului de instalare CLI pe care îl descrieți când spuneți „Viziți site-ul într-un browser”? Vrei să spui vreo adresă URL (relativă a site-ului) sau vreun _sfârșit specific al adresei URL de instalare_? Și în acest caz, îmi repet întrebarea: la ce folosește calea Drush? Multumesc oricum, apreciez ajutorul acordat.
drapel cn
Adică literalmente orice adresă URL de pe front-end-ul site-ului, nu una anume. Când agregarea CSS/JS este activată (așa cum este în mod implicit după instalare), fișierele agregate sunt generate la cerere când o pagină este vizitată și apoi stocate în cache. Problema dvs. actuală pare să fie că fișierele agregate nu pot fi scrise, iar pașii pe care i-ați subliniat pentru a ajunge în acest punct susțin această idee
phep avatar
drapel gq
Vă mulțumesc pentru răbdarea dvs. Păcat că un astfel de indiciu de bază este absent din documentele Drupal. Trebuie să recunosc că până acum nu trecusem niciodată calea unei aplicații web care așteaptă ca prima conexiune non-țintită/neautentificată să-și finalizeze procesul de instalare ;-).
drapel cn
Se scapă, deoarece generarea de active ar trebui să fie dinamică, nu face parte din procesul de instalare. Dar înțeleg ce vrei să spui, e confuz dacă nu ai făcut-o de o sută de ori înainte

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.