Não foi possível instalar ... já existe na configuração ativa

15

No Drupal 8.1, continuo executando esse tipo de mensagem quando tento ativar um módulo personalizado ou um recurso personalizado que faz algumas modificações na página básica. (adicione campos).

É realmente irritante ...

Passos:

  • Limpar banco de dados completamente
  • vá para /install.php e escolha Perfil padrão
  • Agora que o site está sendo executado, vá para Estender
  • Página Selecionar Recurso - Básico

Resultado:

Unable to install Feature - Basic Page, core.base_field_override.node.page.promote, core.entity_form_display.node.page.default, core.entity_view_display.node.page.default, core.entity_view_display.node.page.teaser, field.field.node.page.body, node.type.page already exist in active configuration.

Bem, sim ... é isso que eu quero fazer: Alterar essas configurações padrão!

Expexted:

Consiga instalar meu recurso que faz algumas modificações na página básica.

Meu Recurso

Aqui está o meu recurso criado com o módulo Recursos

Basicamente, adiciona dois campos, banner_image e background_image à página básica

Arquivos:

config
    install
        core.base_field_override.node.page.changed.yml
        core.base_field_override.node.page.created.yml
        core.base_field_override.node.page.promote.yml
        core.base_field_override.node.page.status.yml
        core.base_field_override.node.page.sticky.yml
        core.base_field_override.node.page.title.yml
        core.base_field_override.node.page.uid.yml
        core.entity_form_display.node.page.default.yml
        core.entity_view_display.node.page.default.yml
        core.entity_view_display.node.page.teaser.yml
        field.field.node.page.body.yml
        field.field.node.page.field_banner_image.yml
        field.field.node.page.field_image.yml
        field.storage.node.field_banner_image.yml
        language.content_settings.node.page.yml
        node.type.page.yml
feature_basic_page.features.yml
feature_basic_page.info.yml

Por que essa coisa simples não é suportada? Isso é um bug? O que devo fazer para poder usar meu recurso?

Guillaume Bois
fonte
1
Use drupal EasyInstall módulo que é usado para remover configurações activas
Karthikeyan Manivasagam
1
+1 módulo interessante - vale a pena dar uma olhada - obrigado @KarthikeyanManivasagam
therobyouknow

Respostas:

24

Com drush você provavelmente pode fazer

drush config-delete module_name.settings

excluir as configurações que reclamam

GiorgosK
fonte
Também descobri durante a minha batalha épica contra o Drupal que você pode mover essas configurações em uma optional/pasta para fazê-lo calar a boca. Mas eu não tenho certeza de todas as implicações ...
Guillaume Bois
@GuillaumeBois: as implicações são que essas configurações opcionais seriam ignoradas se já estiverem instaladas ou se as dependências não forem atendidas. Portanto, isso pode causar problemas adicionais se a configuração for necessária para o módulo funcionar.
Renrhaf
+1 obrigado @GiorgosK (Parte 1 de 2): Encontrei esta solução para funcionar no meu caso: Ocorreu um erro no navegador da web do meu site de desenvolvimento: Warning: in_array() expects parameter 2 to be array, null given in lightning_layout_block_alter() (line 91 of modules/contrib/lightning_layout/lightning_layout.module).depois de configurar a fonte git do código do site e o banco de dados em outra máquina .
therobyouknow
(Parte 2 de 2) Então, para resolvê-lo, tentei desinstalar o lightning_layout e reinstalá-lo. drush pm-uninstall lightning_layoutfuncionou, mas quando tentei reinstalá-lo drush en lightning_layout, obtive o erro de linha de comando "Na linha 65 do PreExistingConfigException.php: os objetos de configuração (field.storage.node.panelizer) fornecidos pelo lightning_layout já existem na configuração ativa". solução assim: drush config-delete field.storage.node.panelizer e foi capaz de reativar o módulo:drush en lightning_layout
therobyouknow
1
se você não tem certeza que "configurações" você tem que excluir, você deve executar "Drush config-list" para obter o nome exato da configuração
Jorge Valvert
3

Isso não é suportado porque um módulo pode não substituir uma entidade de configuração que já existe com a instalação.

Para adicionar configurações de modo de formulário e exibição para um tipo de nó já existente, você deve implementar isso no código em hook_install ().

Ou você deve excluir o tipo de nó primeiro no seu site, mas também precisará excluir o conteúdo.

E não, isso não é um bug, é assim que é definido para evitar a perda de configuração.

Berdir
fonte
Isso é muito triste. No D7 isso foi possível (adicione campos a uma página básica por meio de um Recurso). Eu ainda acho que deveria estar no D8 também. Você diz que é para evitar a perda de configuração, mas, na realidade, simplesmente adiciona configurações (campos, peso, rótulo etc.). Observe que eu também tive esse problema com meus próprios módulos personalizados.
Guillaume Bois
Não, não basta adicionar. as exibições de exibição e formulário são compartilhadas em todos os campos de um único tipo de nó. o que acontece se dois módulos tentarem adicionar esse arquivo, quem vencerá? O que acontece com os campos existentes que já estão no tipo de página? e se o tipo de nó básico existir, mas com configurações diferentes das do seu campo? Os cenários de comportamento como esse não estão definidos. Para um recurso independente, é melhor definir seu próprio tipo de nó e implantar essa alteração em seu próprio site, não é necessário um módulo de recurso como no 7.x, você pode apenas exportar a configuração e importá-la novamente.
Berdir
@berdir isso é muito interessante. Portanto, venho deste problema ao tentar criar um recurso de perfil de usuário que inclua notas de exibição e formulário. Então, você está dizendo que isso não pode ser feito em recursos porque o tipo de conteúdo do usuário já existe e o recurso está tentando habilitá-lo? Existe alguma maneira de permitir que um recurso substitua isso para que alguém possa ativar um recurso de perfil em um site já existente?
Kaleemclarkson
O usuário @kaleemclarkson não é um tipo de conteúdo, mas um tipo de entidade. A única maneira de fazer isso é o que eu descrevi, você precisa implementar o código no hook_install () do seu módulo de recurso para definir o formulário e exibir a configuração de exibição. Ou use o módulo de perfil e defina seu próprio tipo de perfil lá.
Berdir
3

Módulo encontrado, use o módulo Easy Install para limpar a configuração ativa sem usar o devel ou drush . Funciona mesmo se você perdeu a pasta opcional e a opção imposta nos arquivos de configuração do módulo ( yml )

Karthikeyan Manivasagam
fonte
1
Esta é uma opção fantástica! Eu apenas usei isso hoje e isso me salvou muito tempo!
Rtd1123
3

Tenho o mesmo problema no site do panteão. Entrei no comando drush

Pantheonsite: drush @ pantheon.SITENAME.ENVNAME config-delete ERRORNAME

Local: drush config-delete ERRORNAME

é trabalho para mim.

omkar gaonkar
fonte
0

Se você deseja adicionar configurações ao seu módulo personalizado, mas elas já existem na configuração ativa, e por algum motivo você não pode usar o drush para excluir essas configurações (no meu caso, porque faz parte de um perfil de instalação), e você tem certeza você não substituirá a configuração, aqui está uma abordagem para substituir essas configurações.

Adicione uma nova pasta ao seu módulo personalizado, / config / hook_install e adicione seus arquivos de configuração .yml nessa pasta e, em seguida, no hook_install do seu módulo.

use Drupal\Component\Serialization\Yaml;

/**
 * Implements hook_install().
 */
function mymodule_install() {

  // Replace these configs.  We're using code to do this, as they are already
  // installed.
  $config_files = [
    'language.types',
    'language.negotiation',
  ];

  foreach ($config_files as $config_id) {
    $raw_data = file_get_contents(drupal_get_path('module', 'mymodule') . '/config/hook_install/' . $config_id . '.yml');
    \Drupal::configFactory()->getEditable($config_id)
      ->setData(Yaml::decode($raw_data))
      ->save();
  }
}
oknate
fonte