V předchozím článku Nenažraný Composer (a Drupal) aneb kolik sakra potřeba volné paměti jsme si ukázali, jak vyřešit bežné problémy Composeru s nedostatkem paměti. To jde ale dělat jen na lokále, na produkčním serveru těžko.
Ono je to ale více méně správně, že máme problémy se spouštěním Composeru na produkčním serveru. Tam by se také potenciálně rizikové operace, měnící Drupal a moduly, neměla vůbec spouštět. Správný postup je si to vše v klidu připravit někde na lokálu, a na produkční server přenést už jenom hotový výsledek. A to právě pomocí již zmiňovaného souboru composer.lock.
composer update VS composer install
Trik je právě v těchto dvou příkazech. Spuštění composer update zkontroluje všechny vazby mezi jednotlivými knihovnami podle definice v composer.json a vygeneruje soubor composer.lock, a tak composer install už jen použije výsledný composer.lock a bez větších nároků na paměť provede dané operace, např. aktualizaci modulu. Takže asi takhle:
- dev server: upravit podle potřeby composer.json
- dev server: spustit composer update drupal/modulename --with-dependencies
- přenést oba soubory composer.json a composer.lock na produkční server
- produkční server: composer install --no-dev
Nezapomeňte ale, že pokud jste instalovali nový modul, tak je třeba ještě spustit drupal module:install jmenomodulu, popř. ho nakonfigurovat. A úplně nejlépe udělat Configuration synchronization.
To samé platí i pro composer remove, také generuje nový composer.lock.
Problematika Composeru je samozřejmě obsáhlejší, ale jako začátek by to mohlo stačit. Další čtení např. zde:
- Drupal 8 Composer Best Practices https://www.lullabot.com/articles/drupal-8-composer-best-practices
- Update core via Composer https://www.drupal.org/node/2700999 a Update modules https://www.drupal.org/docs/8/update/update-modules