O seguinte é OK para sistema liberta 8.4.x> 8.4.y , mas não OK para lançamentos menores 8.4.x> 8.5.x . Vá para a ATUALIZAÇÃO 3 abaixo para o que acredito ser "a resposta" para atualizações menores de versão.
1- Faça backup dos arquivos que acompanham o Drupal que você modificou, como .htaccess, robots.txt, etc. (esses 2 são os mais comumente alterados).
2- [Me disseram que o arquivo de bloqueio de exclusão está errado, consulte ATUALIZAÇÃO abaixo] Exclua o arquivo composer.lock (na pasta de nível superior do seu site). Isso é recriado na etapa 5.
3- Verifique seu compositer.json (na pasta de nível superior do seu site) e verifique se o "drupal: core" está na seção de necessidade e não em uma seção de substituição, por exemplo
"require": {
"drupal/core": "^8.4"
},
não
"replace": {
"drupal/core": "^8.4"
},
Se "drupal / core" estiver na seção de substituição, mova-o para a seção de necessidade e exclua a seção de substituição. Se houver outras entradas na seção de substituição, basta remover o "drupal / core" e não toda a seção de substituição - mas acho que "drupal / core" é normalmente a única coisa lá.
Coloque em qual versão você deseja atualizar em "drupal / core", exemplos:
"drupal / core": "^ 8.5" - será atualizado para a versão mais recente do 8.5. "drupal / core": "8.4.6" - será atualizado para a versão 8.4.6.
5- Execute isto (na pasta de nível superior do seu site):
composer update drupal/core --with-dependencies
6- Se não houver erros, faça o habitual, execute as atualizações e limpe o cache:
drush updatedb
drush cr
Ou, se não estiver usando o drush, vá para /update.php para executar atualizações, depois para admin / config / development / performance e clique no botão "Limpar todos os caches".
7- Se você fez o backup dos arquivos na primeira etapa (.htaccess, robots.txt), coloque-os de volta. Mas verifique se o Drupal fez atualizações nesses arquivos e adicione essas alterações às suas.
FEITO
Se houve erros com a atualização do compositor na etapa 5, geralmente isso ocorre devido a problemas com versões do material na pasta do fornecedor.
Este é um ótimo post para lidar com esses problemas: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update e leia os outros 2 posts de Jeff no Drupal and Composer para obter mais conhecimento sobre isso.
Foi-me dito por duas pessoas no Twitter que o composer.lock não deve ser excluído (Etapa 2 acima). O composer update drupal/core --with-dependenciescomando recria o arquivo de bloqueio de qualquer maneira.
Ao testar esse método, acho que funciona bem para 8.4.3> 8.4.6 (por exemplo), mas recebo erros para 8.4.6> 8.5.x. Irá relatar quando eu descobrir.
Exemplo de erros:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
- symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
- symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
- drupal/core 8.5.0 requires symfony/yaml ~3.4.5 -> satisfiable by symfony/yaml[3.4.x-dev].
- Installation request for drupal/core 8.5.0 -> satisfiable by drupal/core[8.5.0].
- Installation request for symfony/console (locked at v3.2.8, required as ~3.2.8) -> satisfiable by symfony/console[v3.2.8].
Este post de Jeff Geerling aborda questões semelhantes, mas até agora não tenho sorte: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update
Então ... a única coisa que parece funcionar para mim para 8.4.x> 8.5.x é a "opção nuclear" que muitos outros parecem usar, que é executada composer update.
Acho que está tudo bem, desde que você tenha certeza das versões do módulo em composer.json. Talvez alguém deva bloqueá-los para a versão atual. Por exemplo:
"drupal/address": "1.3"
ao invés de:
"drupal/address": "^1.3"
Mas é a resposta certa?
OK, a resposta que parece estar em toda parte é fazer a "opção nuclear":
A. Exclua a /vendorpasta.
B. Execute composer updatee simplesmente atualize seus módulos junto com o core. Ou bloqueie as versões do módulo, composer.jsonse você não quiser atualizá-las.
Uma pessoa do Drupal Slack disse que "toda a filosofia do Composer é que você deve sempre atualizar os pacotes com a maior frequência possível" . O pacote inclui módulos, eu acho. Então faz algum sentido, eu acho.
Quando cheguei do 8.4.6 ao 8.5.0, isso funcionou bem para passar do 8.5.0 ao 8.5.1 composer update drupal/core --with-dependencies, da mesma forma que nos 8.4.3 ao 8.4.6.
Estou começando a concluir que "a resposta" é excluir a pasta do fornecedor e o arquivo composer.lock e, em seguida, usá composer update-lo, e deve-se simplesmente garantir que os números de versão das dependências no arquivo composer.json sejam o que você deseja . Não é tão importante gerenciar em quais versões do módulo você deseja manter ou permitir a atualização composer.json.
Por exemplo:
"drupal/admin_toolbar": "1.18", significa ficar com 1,18
"drupal/admin_toolbar": "^1.18", significa ir em frente e atualizar, mas dentro de 1.x (não 2.x)
Isso é apoiado por um comentário (General Redneck) nesta postagem: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update
"Uma das coisas que eu O que eu descobri enquanto trabalho no suporte é que bloquear as versões dos módulos e do núcleo é uma boa idéia, para que você possa ouvir a coisa quando quiser, porque há momentos em que alguns dos vários plugins nem querem se comportar corretamente. "
A propósito, o arquivo composer.lock não ajuda em nada composer updateporque fica deslumbrado (ao contrário de composer installonde o arquivo de bloqueio é lido):
A corrida composer installirá:
- Verifique se
composer.lockexiste
- Caso contrário, execute a
composer updatepara criar um
- Se
composer.lockexistir, instale as versões especificadas no arquivo de bloqueio
A corrida composer updateirá:
- Verifica
composer.json
- Determine as versões mais recentes a serem instaladas com base nas especificações de sua versão
- Instale as versões mais recentes
- Atualização
composer.lockpara refletir as versões mais recentes instaladas
Ref: https://www.engineyard.com/blog/composer-its-all-about-the-lock-file
Vejo que isso é mencionado acima: https://github.com/drupal-composer/drupal-project . Eu usei isso e está bom, mas não é um requisito para usar o Composer com o Drupal. É confuso, pois meio que "soa" como se fosse o nome. Quando comecei com o Drupal 8, pensei que era necessário, então construí meu primeiro site D8 com isso, pensando que era uma prática recomendada.
Essa "versão" do Drupal tem ele docroot em uma pasta / web, não na pasta superior do projeto. Também há um monte de coisas adicionadas ao .gitignore em comparação com o Drupal normal:
/drush/contrib/
/vendor/
/web/core/
/web/modules/contrib/
/web/themes/contrib/
/web/profiles/contrib/
/web/libraries/
Portanto, esta versão do Drupal é realmente mais voltada para sites que usam integração contínua para fazer uma nova compilação do Drupal em cada implantação, usando a instalação do compositor. Se você implantar com um método mais normal, obviamente precisará comprometer todo o material acima no seu repositório git ou ele não será implantado no seu servidor [1], e esse material é necessário para que o Drupal seja executado.
[1] se o git estiver envolvido com sua implantação - se você implantar com SFTP, ignore isso.