Può succedere che quando si disinstalla un modulo la procedura non viene eseguita tutta oppure non è presente nessuna procedura di rimozione, per questo motivo il database rimane “sporco”.
Normalmente l’errore causato dalla rimozione forzata di un plugin è questo:
The “name-of-plugin” entity type does not exist.
in DrupalCoreEntityEntityTypeManager->getDefinition()
Abilitare la configurazione che mostra tutti i messaggi di errori, può aiutare a capire dove è presente l’errore e dove serve intervenire.
L’abilitazione completa dei log la puoi attivare nella pagina qui presente admin/config/development/logging. Questa configurazione può aiutarti a capire se il problema sono le configurazioni o il nome del plugin è hardcodato nel tuo codice.
Adesso affronteremo come risolvere la problematica se è legata alle configurazioni e per farlo abbiamo due modi possibili:
Esportando tutta la configurazione e reimportandola dopo aver rimosso i richiami al plugin
Agendo direttamente sulle configurazioni presenti in db e rimuovendo il plugin
Esportando tutta la configurazione e reimportandola
Questa soluzione molto probabilmente è tra le più utilizzare se si segue lo standard per la metodologia di rilascio consigliata dalla community di Drupal.
Esporta tutta la configurazione attraverso l’interfaccia grafica o con il comando drush config:export. Nei file recuperati dall’export effettua una ricerca full-text con il nome di plugin. Rimuovi la sezione di configurazione che sta causando l’errore e importa la configurazione con drush config:import
Agendo direttamente sulle configurazioni presenti in db e rimuovendo il plugin
Questa soluzione è utile per chi, come me, non ha la possibilità di esportare tutta la configurazione e reimportarla ma ha bisogno di lavorare “a caldo” sul sito.
Per trovare quali configurazioni stanno causando l’errore è possibile eseguire questa query sul db:
La query cerca nella tabella delle configurazioni il plugin incriminato e restituisce i nomi delle configurazioni che richiamano il plugin.
Quando si hanno i nomi delle configurazioni si può procedere alla rimozione del plugin.
In base al plugin e alla configurazione in errore il metodo di rimozione può leggermente cambiare, adesso prendiamo in considerazione un esempio che può essere un buon punto di partenza anche per altre casistiche.
Es.
Avevo un problema con il plugin filter_image_lazy_load a causa di un aggiornamento a Drupal 10 andato male.
La query precedente ha restituito queste configurazioni:
filter.format.full_html
filter.format.restricted_html
Con il servizio config.factory ho caricato le configurazioni e ho verificato dove è presente il problema. Dopo si può procedere alla rimozione del plugin in questo modo:
$config = Drupal::service(‘config.factory’)->getEditable($configName);
$filters = $config->get(‘filters’);
unset($filters[‘filter_image_lazy_load’]);
$config->set(‘filters’, $filters)->save()
Puoi fare la stessa identica cosa con drush config:get filter.format.basic_html e drush config:set filter.format.basic_html oppure in un colpo unico con drush config:edit filter.format.basic_html
Dopo aver pulito le configurazioni esegui un drush cache:rebuild e l’errore dovrebbe essere risolto!
