Hosting Drupalu: požadavky, Composer a nastavení

Drupal 11 potřebuje PHP 8.3 nebo novější, databázi třídy MySQL 8.0, MariaDB 10.6 nebo PostgreSQL 16, v praxi alespoň 128 MB paměti pro PHP a webový server, který každý požadavek, k němuž nenajde soubor, pošle do index.php. Instaluje se přes Composer, ne rozbalením archivu, a právě tahle jedna věc určuje všechno kolem hostingu: build proběhne tam, kde běží Composer, a výsledek - včetně adresáře vendor s několika tisíci soubory - se nahraje na server.

Na hostingu se shellem jsou to dva příkazy. Na panelovém hostingu bez shellu postavíš web u sebe na počítači a nahraješ ho, což funguje naprosto dobře, jakmile víš, kam patří webový kořen. Tento návod pokrývá obojí, pak settings.php řádek po řádku, pravidla pro nginx, cron, cache (včetně Valkey), aktualizace a chyby, na které lidé skutečně narážejí.

Který Drupal a co vyžaduje#

Koncem roku 2026 jsou v oběhu tři hlavní verze a jen jedna je správná volba pro nový web.

Nové weby zakládej na Drupalu 11. Web na Drupalu 10 je potřeba povýšit hned, ne až v prosinci; cesta vede z verze 10.3 nebo novější na 11, modul po modulu, a modul Upgrade Status ti řekne, co je nekompatibilní. Požadavky se mění s menšími verzemi, takže si před jakýmkoli nákupem zkontroluj oficiální stránky: požadavky na PHP a požadavky na databázi.

Požadavky Drupalu 11 v praxi:

K paměti je potřeba říct pár slov. Web na Drupalu s dvaceti třiceti contrib moduly spotřebuje na jeden požadavek víc paměti PHP než srovnatelný WordPress a nejnáročnější okamžik je přestavba cache po nasazení. Tarif s 1 GB utáhne malý web na Drupalu; 2 GB je pohodlný začátek pro cokoli se stránkami postavenými na Views, s Media a Search API a memory_limit pro PHP by tam měl být 256 MB. Nastavení php.ini, na kterém záleží popisuje memory_limit, max_execution_time a OPcache.

Existuje také Drupal CMS, balená distribuce nad jádrem Drupalu určená tvůrcům webů, s předkonfigurovanými recepty pro běžné funkce. Instaluje se a hostuje stejně; platí pro něj všechno zde.

Sestavení kódu přes Composer#

Podporovaným výchozím bodem je šablona drupal/recommended-project:

$ composer create-project drupal/recommended-project example.com$ cd example.com$ composer require drush/drush$ composer require drupal/admin_toolbar drupal/pathauto drupal/redis

Výsledek má určitou strukturu a když jí rozumíš, předejdeš většině problémů s hostingem:

example.com/  composer.json        what you asked for  composer.lock        exact versions installed - commit this  vendor/              PHP libraries, Drush, Symfony - not web-accessible  web/                 the web root    index.php    core/    modules/contrib/    themes/contrib/    sites/default/

Servírovat by se mělo pouze web/. Adresáře vendor/ a soubor composer.json leží vedle, mimo webový kořen, takže si je nikdo nemůže vyžádat přes HTTP. To je hlavní strukturální rozdíl oproti WordPressu nebo Joomle, kde všechno leží ve webovém kořeni.

composer.json a composer.lock drž ve verzovacím systému spolu s vlastními moduly a šablonami a s vendor/, web/core a web/modules/contrib zacházej jako s výstupem buildu. composer.lock commituj vždy - právě díky němu build na tvém notebooku a build za půl roku vytvoří stejný web.

Instalace na hostingu bez shellu#

Panelový hosting často nabízí správce souborů a SFTP, ale žádný přihlašovací shell, takže Composer na serveru spustit nejde. To není překážka. Postav web lokálně a nahraj hotový build.

1. Sjednoť verze PHP. Lokálně používej stejnou hlavní a vedlejší verzi PHP jako na serveru. Composer řeší závislosti pro PHP, pod kterým běží, a lock soubor vytvořený na PHP 8.4 může natáhnout balíčky, které na 8.3 odmítnou běžet. Pokud máš na počítači novější verzi, připni ji v composer.json přes "config": { "platform": { "php": "8.3.0" } }.
2. Sestav bez vývojových balíčků: composer install --no-dev --optimize-autoloader.
3. Rozhodni, kam půjde webový kořen. Pokud můžeš nahrát celý projekt a nasměrovat web na web/, udělej to. Pokud hosting servíruje pevný adresář - public_html, www, public - přejmenuj raději webový kořen Drupalu, než abys přesouval soubory: v composer.json změň všechny cesty web/ v extra.installer-paths, nastav extra.drupal-scaffold.locations.web-root na název adresáře a spusť composer install znovu. Projekt nahraj o úroveň výš než tento adresář, aby vendor zůstal mimo něj.
4. Nahraj jako jeden archiv. Tisíce malých souborů přes SFTP trvají mnohem déle než jeden zip. Správce souborů, který archivy rozbaluje na místě, z toho udělá jediné nahrání; obě cesty popisuje SFTP a správce souborů.
5. Vytvoř databázi a uživatele, pak otevři web a spusť instalátor.

Pokud ti hosting dovolí zapisovat jen uvnitř webového kořene, Drupal s vendor uvnitř spustit jde, ale pak se musíš ujistit, že webový server odmítá požadavky na vendor/, composer.json a composer.lock - tyto soubory prozrazují přesné verze všeho, co provozuješ. Uspořádání s webovým kořenem o úroveň níž je lepší, pokud ho můžeš získat.

Na RE:NODE jsou pro takový CMS dimenzované tarify Engines. Drupal si nainstaluješ sám přes SFTP nebo správce souborů - žádný instalátor na jedno kliknutí neexistuje, takže ti nikdo nepřipne verzi - a každý tarif obsahuje dva sloty databáze vytvářené z panelu s vygenerovaným hostem, uživatelem a heslem. Web na Drupalu potřebuje jeden z nich; druhý je určený pro testovací kopii.

settings.php řádek po řádku#

Instalátor zkopíruje sites/default/default.settings.php do settings.php a zapíše do něj přihlašovací údaje k databázi. Několik nastavení je potřeba přidat nebo zkontrolovat ručně.

$databases['default']['default'] = [  'driver'    => 'mysql',  'database'  => 'drupal',  'username'  => 'drupal_site',  'password'  => getenv('DRUPAL_DB_PASSWORD') ?: 'from-the-panel',  'host'      => 'db.example.internal',  'port'      => '3306',  'prefix'    => '',  'collation' => 'utf8mb4_general_ci',  'init_commands' => [    'isolation_level' => 'SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED',  ],];$settings['hash_salt'] = 'a-long-random-string';$settings['config_sync_directory'] = '../config/sync';$settings['file_private_path'] = '../private';$settings['trusted_host_patterns'] = ['^example\.com$', '^www\.example\.com$'];$settings['update_free_access'] = FALSE;

K čemu který řádek slouží:

• `host` a `port` jsou místa, kde lidé chybují, úplně stejně jako u WordPressu. localhost funguje jen tehdy, když databáze běží na stejném stroji; u slotu databáze nebo samostatného databázového serveru použij hostname a port, které jsi dostal.
• `init_commands` s `READ COMMITTED` se týká databází z rodiny MySQL. Stavová zpráva Drupalu to doporučuje, protože výchozí úroveň REPEATABLE READ způsobuje při zápisových vzorcích Drupalu víc deadlocků. Novější instalátory mohou zapsat ekvivalentní klíč isolation_level samy; stačí jedno z obou.
• `hash_salt` se používá pro jednorázové přihlašovací odkazy, tokeny formulářů a další podpisy. Instalátor ho vygeneruje; drž ho v tajnosti a na všech serverech, kde běží stejný web, ho měj shodný.
• `config_sync_directory` je místo, kam se konfigurace exportuje a odkud se importuje. Dej ho mimo webový kořen, jak je vidět výše, aby exportovanou konfiguraci nešlo stáhnout.
• `file_private_path` zapíná soukromé soubory, které se servírují jen přes kontroly přístupu Drupalu. Také mimo webový kořen.
• `trusted_host_patterns` je bezpečnostní nastavení, ne volitelné. Bez něj Drupal přijme libovolnou hlavičku Host a dá se napálit, aby v e-mailech pro reset hesla generoval odkazy na doménu útočníka. Stavová zpráva upozorňuje, dokud není nastaveno.

Po instalaci nastav settings.php i adresář sites/default jen pro čtení. Drupal to kontroluje a ve stavové zprávě si stěžuje, pokud do nich může zapisovat.

Za reverzní proxy je Drupalu potřeba to říct dřív, než začne věřit hlavičkám X-Forwarded-For a X-Forwarded-Proto:

$settings['reverse_proxy'] = TRUE;$settings['reverse_proxy_addresses'] = ['192.0.2.10'];

Adresy jsou ty, ze kterých se tvá proxy připojuje. Bez toho se každý návštěvník tváří, že přichází z proxy, ochrana proti záplavě požadavků zablokuje všechny najednou a generované URL mohou na webu s HTTPS používat http://. Hlavičky vysvětluje Co dělá reverzní proxy.

Pravidla pro nginx#

Drupal dodává soubor .htaccess se svými pravidly přepisování a sadou ochran - zakazuje přístup k souborům .yml, .twig, composer.json a podobným. nginx .htaccess úplně ignoruje, takže tyto ochrany je nutné vytvořit znovu v konfiguraci serveru. Jádro:

location / {    try_files $uri /index.php?$query_string;}location @rewrite {    rewrite ^ /index.php;}location ~ ^/sites/.*/files/styles/ {    try_files $uri @rewrite;}location ~ (^|/)\. { return 403; }location ~ ^/sites/.*/private/ { return 403; }location ~* \.(engine|inc|install|make|module|profile|po|sh|sql|theme|twig|tpl|yml|yaml)$ {    return 403;}location ~ /vendor/ { deny all; }

Blok styles je důležitější, než vypadá: odvozeniny stylů obrázků se generují při prvním požadavku, takže chybějící soubor tam musí jít do Drupalu, ne vrátit 404. Bez něj jsou všechny zmenšené obrázky na webu rozbité. Úplný seznam ochran porovnej se souborem .htaccess ve svém adresáři web/, který je pro tvou verzi Drupalu autoritativním seznamem.

Na spravovaném hostingu nemusíš mít možnost konfiguraci nginx upravovat. Zjisti, jestli je standardní pravidlo front controlleru (try_files ... /index.php) už nasazené - pokud funguje /user/login, je. Pokud se styly obrázků nebo soukromé soubory chovají divně, je to část, na kterou se zeptej svého hostingu.

Cron a práce na pozadí#

Drupal potřebuje cron pro indexování vyhledávání, mazání prošlých cache a relací, kontroly aktualizací, zpracování front a cokoli, co moduly plánují. Spouštět ho lze třemi způsoby.

• Automated Cron, modul jádra, spustí cron na konci požadavku na stránku, když uplyne dost času - ve výchozím stavu každé tři hodiny, nastavitelné na /admin/config/system/cron. Pro malé weby v pořádku; návštěvník, který ho spustí, dostane pomalejší odpověď.
• URL cronu, zobrazená na téže stránce jako https://example.com/cron/<key>. Může ji volat libovolný externí plánovač - monitorovací služba, naplánovaná úloha na jiném stroji. Klíč drž v tajnosti; kdokoli s touto URL může cron spustit.
• Drush, drush cron, ze systémového crontabu tam, kde máš shell. Nejspolehlivější možnost a taková, která nevazuje cron na návštěvnost webu.

Pokud používáš externí spouštěč, vypni Automated Cron, aby cron neběžel navíc uvnitř požadavků návštěvníků. Syntaxi plánu popisuje Výrazy cronu vysvětleně.

Cache a přidání Valkey#

Základní cache Drupalu je dobrá a ve výchozím stavu zapnutá:

• Internal Page Cache ukládá celé stránky pro anonymní návštěvníky.
• Dynamic Page Cache cachuje části stránek, které jsou stejné pro mnoho uživatelů, včetně přihlášených, pomocí kontextů cache.
• BigPipe pošle nejdřív cachovaný rámec stránky a personalizované části doplní průběžně.
• Agregace CSS a JavaScriptu v části Configuration, pak Performance, by měla být v produkci zapnutá.

Ve výchozím stavu žijí všechny sekce cache v tabulkách databáze. Na vytíženém webu je to hodně databázového provozu pro data, která trvanlivost nepotřebují, a přesunutí sekcí cache do Valkey je standardní vylepšení. Modul drupal/redis mluví protokolem Redis a k Valkey se připojí beze změn. Nejdřív modul zapni, pak přidej do settings.php:

$settings['redis.connection']['interface'] = 'PhpRedis';$settings['redis.connection']['host'] = '203.0.113.20';$settings['redis.connection']['port'] = 6380;$settings['redis.connection']['password'] = getenv('VALKEY_PASSWORD');$settings['cache']['default'] = 'cache.backend.redis';$settings['cache_prefix'] = 'example_com_';$settings['container_yamls'][] = 'modules/contrib/redis/example.services.yml';

PhpRedis potřebuje rozšíření phpredis; Predis je alternativa napsaná čistě v PHP, instaluje se přes composer require predis/predis. Pokud jeden Valkey sdílí víc webů, nastav pro každý unikátní cache_prefix. Zdrojem pravdy zůstává databáze: cache lze kdykoli smazat přes drush cr nebo tlačítkem Clear all caches. Tarif Valkey začíná na 256 MB, což je pro většinu sekcí cache Drupalu víc než dost; proč se pro instanci jen na cache hodí vytlačující politika, vysvětluje Paměť Valkey a politiky vytlačování.

Aktualizace a nasazování konfigurace#

Drupal vydává bezpečnostní aktualizace podle zveřejněného plánu, obvykle ve středu. Bezpečnostní vydání jádra a oblíbených modulů se oznamují na drupal.org a modul Update Status ti pošle e-mail, když web zaostává. Čti bezpečnostní upozornění; „highly critical“ vydání jádra, jako byly problémy Drupalgeddon z roku 2018, se zneužívá během hodin.

Samotná aktualizace přes Composer:

$ composer update "drupal/core-*" --with-all-dependencies$ drush updatedb$ drush cache:rebuild

Bez shellu spusť composer update lokálně, nahraj změněné vendor/ a web/core/ (a všechny aktualizované moduly) a pak jako administrátor otevři /update.php, který provede aktualizace databáze. Vždy si nejdřív udělej zálohu a během aktualizace přepni web do režimu údržby, aby nikdo uprostřed nezapisoval do databáze. Důvod, proč zálohu zkoušet obnovit, uvádí Zálohy, které se opravdu obnoví.

Změny konfigurace - typy obsahu, pole, pohledy - by měly putovat z vývoje do produkce přes správu konfigurace, ne se klikat dvakrát: drush config:export na vývojové kopii, commit souborů YAML, nasazení, drush config:import na produkci. Ekvivalent v rozhraní najdeš v Configuration, pak Development, pak Configuration synchronisation.

Řešení potíží#

Instalátor se zastaví na „Requirements problem“. Přečti si seznam: obvykle chybí rozšíření PHP, verze PHP je pod 8.3 pro Drupal 11 nebo sites/default/files není zapisovatelný.

„The provided host name is not valid for this server“. trusted_host_patterns neodpovídá hostname, na který přistupuješ. Přidej ho, včetně www, pokud se používá.

Bílá obrazovka nebo „The website encountered an unexpected error“. Podívej se na poslední zprávy v logu na /admin/reports/dblog nebo do chybového logu PHP, pokud je administrace nedostupná. Vyčerpání paměti při přestavbě cache je časté; zvyš memory_limit.

Každá stránka kromě úvodní vrací 404. Chybí přepisování front controlleru - typické na nginx, když se spoléhalo jen na .htaccess z Apache.

Obrázky ve stylech obrázků jsou rozbité. Chybí pravidlo styles výše, nebo sites/default/files není zapisovatelný.

Smyčky přesměrování po zapnutí HTTPS. Hlavičkám proxy se nevěří; nastav reverse_proxy a jeho adresy.

FAQ#

Můžu nainstalovat Drupal bez Composeru?

Pro Drupal 11 ne podporovaným způsobem. Archivy jádra ke stažení existují, ale contrib moduly deklarují své závislosti přes Composer a ruční správa se rozbije na prvním modulu se závislostí na knihovně. Postav web Composerem na libovolném stroji a výsledek nahraj.

Jaký hosting potřebuje web na Drupalu?

Malý prezentační web běží na 1 GB s jedním nebo dvěma jádry CPU. Web se stránkami postavenými na Views, s Media, Search API a trochou přihlášeného provozu chce 2 GB nebo víc a memory_limit pro PHP 256 MB. Limitem bývá většinou paměť a počet workerů PHP dřív než CPU.

Je Drupal náročnější na hosting než WordPress?

Víc žádá od kroku buildu - Composer, oddělený webový kořen, správa konfigurace - a o něco víc paměti. Na oplátku se jeho cache a strukturovaný obsah škálují dál, než je potřeba cokoli přidávat. Po stránce hostingu jsou oba aplikace v PHP s databází.

Kdy musím opustit Drupal 10?

Bezpečnostní podpora Drupalu 10 končí 9. prosince 2026. Na Drupal 11 přejdi před tímto datem; weby, které na Drupalu 10 zůstanou i poté, nedostávají žádné bezpečnostní opravy.

Potřebuju pro Drupal Valkey?

Ne. Cache Drupalu v databázi fungují v malém a středním měřítku. Přesunutí sekcí cache do Valkey odlehčí databázi a pomůže vytíženým webům, zvlášť těm s mnoha přihlášenými uživateli.