DEV Community: McAle

Risolvere l’Errore "A non-existent config entity name returned by FieldStorageConfigInterface::getBundles()" in Drupal

McAle — Fri, 23 May 2025 08:41:58 +0000

Quando si lavora con Drupal e si eseguono operazioni di manutenzione o pulizia dei contenuti e dei tipi di entità, può capitare di imbattersi in un errore come questo nel log:

A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): entity type: node, bundle: [BUNDLE_TYPE], field name: [FIELD_NAME]

Cosa significa questo errore?

Questo messaggio di errore indica che Drupal sta tentando di recuperare una configurazione di field associata a un bundle (tipo di contenuto) che non esiste più. In particolare, la configurazione interna dei campi (field_map) mantiene ancora un riferimento a quel bundle fantasma.

Questo accade spesso quando:

Un bundle viene eliminato manualmente dal database (errore).
Un modulo contrib crea e poi elimina un tipo di contenuto.
C'è un'incongruenza tra la configurazione salvata e lo stato reale del sito.

Come risolvere

Per risolvere il problema è necessario rimuovere manualmente il riferimento orfano dalla mappa dei campi (bundle_field_map). Di seguito un semplice script PHP da eseguire in un contesto Drupal (es. via drush php o tramite un modulo custom):

<?php

use Drupal::keyValue;

// Recupera la mappa dei campi per l'entità "node"
$key_value = \Drupal::keyValue('entity.definitions.bundle_field_map');
$field_map = $key_value->get('node');

// Sostituire con i valori effettivi dell'errore
$field_name = '[FIELD_NAME]';
$bundle_to_remove = 'BUNDLE_TYPE';

// Verifica e rimuove il bundle se presente
if (isset($field_map[$field_name]['bundles'][$bundle_to_remove])) {
  unset($field_map[$field_name]['bundles'][$bundle_to_remove]);
  $key_value->set('node', $field_map);
  echo "Bundle rimosso dalla field map: $bundle_to_remove\n";
}
else {
  echo "Bundle non trovato nella field map: $bundle_to_remove\n";
}

Drupal: Rimuovere un plugin fantasma dal database

McAle — Sun, 07 Jul 2024 09:17:04 +0000

Fonte: https://drupal.stackexchange.com/questions/315921/removing-phantom-plugin-from-database/320215#320215

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:

[error]  Drupal\Component\Plugin\Exception\PluginNotFoundException:
         The "name-of-plugin" entity type does not exist.
         in Drupal\Core\Entity\EntityTypeManager->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:

SELECT name FROM config WHERE data LIKE "%name-of-plugin%";

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.basic_html
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:

$configName = 'filter.format.basic_html';
$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!

Come correggere l'errore "Currently using Missing or invalid module"

McAle — Thu, 04 Jul 2024 15:32:11 +0000

Durante lo sviluppo di un sito drupal, può capitare di installare un modulo e poi cancellare i file senza disabilitarlo, oppure durante la disintallazione qualcosa non va a buon fine e il DB rimane sporco.

In questi casi può comparire l'errore:

[error] Currently using Missing or invalid module.
        The following module is marked as installed in
        the core.extension configuration,
        but it is missing:
 * phpass

L'errore normalmente compare se si prova a effettuare drush updatedb, in questo caso non è bloccante ma è solo noioso vederlo.
L'errore diventa bloccante quando si prova a installare o disinstallare un modulo, in quel momento si viene bloccati.

Nell'esempio che ho riportato stavo effettuando test di aggiornamento di un sito da Drupal 9 a 10, ma dopo l'aggiornamento (avvenuto con successo), sono dovuto tornare alla versione 9.
Cambiando versione, senza procedure di rollback guidate che eseguivano le operazioni necessarie, ho causato la problematica; il modulo phpass introdotto in Drupal 10 non era più presente su sito.

Come risolvere l'errore

La risoluzione è molto semplice, basta rimuovere dalla configurazione core.extension il riferimento al modulo, così il sito non vede più il modulo attivo e non lo cerca più.

Il comando da eseguire è questo:

drush config:delete core.extension module.phpass

Dopo averlo eseguito sarete liberi di installare ogni modulo che desiderate!

Git revert commit – Come rimuovere l'ultimo commit fatto

McAle — Sun, 30 Jun 2024 12:51:31 +0000

Fonte: Git Revert Commit – How to Undo the Last Commit

Voglio riportare due metodi per poter ripristinare il proprio codice quando per sbaglio del codice errato è stato commitatto o se si ha sbagliato branch di destinazione.

Il comando `revert`

Il comando revert, dopo aver specificato il commit da dover rimuovere, creerà un altro commit che farà le operazioni opposte alle tue ultime modifiche, ripristinando il codice al suo stato iniziale.
Puoi usarlo in questo modo:

git revert <commit_SHA_to_revert>

Puoi trovare lo SHA del commit che vuoi rimuovere utilizzando git log. Il primo commit che verrà visualizzato è l'ultimo commit che è stato creato. Dopo aver individuato il commit, puoi copiare lo SHA e usarlo nel comando indicato precedentemente.

Il comando `reset`

Il comando reset è più immediato perchè non c'è bisogno dello SHA del commit per eseguirlo, ma devi prestare molta più attenzione a usarlo, perchè verrà cambiata la history dei commit.
L'operazione fatta dal comando reset sposterà il puntamento alla HEAD del branch corrente e scarterà tutto il resto che è stato fatto dopo.
Puoi usarlo in questo modo:

git reset --soft HEAD~1

L'opzione --soft significa che non perderai i cambiamenti non aggiunti a un commit che potresti avere.

Se invece vuoi ripristinare l'ultimo commit rimuovendo anche tutte le modifiche non presenti in un commit puoi usare l'opzione --hard

git reset --hard HEAD~1

Dovresti utilizzare `reset` o `revert`?

Dovresti utilizzare reset solo se il commit che devi rimuovere esiste solo localmente e non hai ancora eseguito un push per caricare il codice nel repository.
Questo comando cambia la history dei commit e potrebbe sovrascrivere delle modifiche importanti per altri membri del team che stanno lavorando sullo stesso progetto.

Viceversa revert crea un nuovo commit che rimuove le modifiche, così se il commit da togliere è già stato caricato nel repository, è meglio utilizzare un revert che non cambia o non rischia di sovrascrivere la history dei commit.

Come correggere l'errore "non-existent config entity name returned by FieldStorageConfigInterface::getBundles()"

McAle — Sun, 16 Jun 2024 17:02:33 +0000

Fonte: How to fix "non-existent config entity name returned by FieldStorageConfigInterface::getBundles()"

Personalmente mi sono imbattuto in questo errore dopo aver aggiornato un sito storico che è nato con Drupal 8, è passato alla versione 9 e adesso ha affrontato l'aggiornamento a Drupal 10.

Nel corso degli anni il sito ha subito numerose aggiunte, modifiche e cancellazione di campi, ogni volta portandosi dietro molta "sporcizia".

Con l'aggiornamento a Drupal 10 ho notato una mole di errori nei log immensa quindi è stato necessario affrontare la problematica cercando.

Grazie alla community sono riuscito a trovare la soluzione citata nel link in cima al post.
Voglio riportare la soluzione per rendere più facile trovare la risposta perchè il post originale è diventato molto lungo e un po' dispersivo.

Per risolvere l'errore ci sono diversi modi:

Utilizzando un HOOK_update:

function YOURMODULENAME_update_10001() {
  ## Fixes:
  ## A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): entity type: paragraph, bundle: text, field name: field_image
  $entity_type = 'paragraph';
  $bundle = 'text';
  $field_name = 'field_image';

  /** @var \Drupal\Core\KeyValueStore\KeyValueFactoryInterface $key_value_factory */
  $key_value_factory = \Drupal::service('keyvalue');
  $field_map_kv_store = $key_value_factory->get('entity.definitions.bundle_field_map');
  $map = $field_map_kv_store->get($entity_type);
  // Remove the field_dates field from the bundle field map for the page bundle.
  unset($map[$field_name]['bundles'][$bundle]);
  // Remove field definition if empty.
  if (empty($map[$field_name]['bundles'])) {
    unset($map[$field_name]);
  }

  $field_map_kv_store->set($entity_type, $map);

  // Remove entity type definition if empty after unsetting.
  if (empty($field_map_kv_store->get($entity_type))) {
    $field_map_kv_store->delete($entity_type);
  }
}

Nel codice precedente viene mostrato come esempio un errore sull'entità di tipo paragraph, sul bundle text dove il campo che causa il problema è field_image.
In questo modo si pulisce la definizione del campo field_image togliendo il suo riferimento al bundle text e se alla fine della pulizia se il campo non ha altri bundle al suo interno si procede all'eliminazione del campo stesso.
Proseguendo con la stessa logica se alla conclusione anche il tipo di entità è vuoto allora procediamo alla sua cancellazione.

Se l'errore è presente su più di un campo si può tranquillamente inserire la funzione in un foreach dove cambiando i parametri $entity_type, $bundle e $field_name.

Creando un modulo personalizzato:

1 - Incomincia creando una cartella chiamato nel modo che preferisci, userò il placeholder [MY_MODULE] per indicare il nome del modulo.

2 - All'interno della cartella, crea un file con nome [MY_MODULE].info.yml e il suo contenuto dovrà essere:

name: My Module
description: Fixes Error - A non-existent config entity name returned by FieldStorageConfigInterface::getBundles().
package: Custom
type: module
core_version_requirement: ^9.4 || ^10

3 - Crea un altro file chiamato drush.services.yml e inserisci dentro questo codice:

services:
  update.commands:
    class: \Drupal\[MY_MODULE]\Commands\UpdateCommands
    arguments:
      - '@keyvalue'
    tags:
      - { name: drush.command }

4 - Crea una cartella src, dentro la quale crea un'altra cartella Commands.

5 - All'interno della cartella Commands, crea il file UpdateCommands.php e inserisci al suo interno questo codice:

<?php

namespace Drupal\[MY_MODULE]\Commands;

use Drush\Commands\DrushCommands;
use Drupal\Core\KeyValueStore\KeyValueFactoryInterface;

/**
 * A Drush commandfile.
 *
 * In addition to this file, you need a drush.services.yml
 * in root of your module, and a composer.json file that provides the name
 * of the services file to use.
 *
 * See these files for an example of injecting Drupal services:
 *   - http://git.drupalcode.org/devel/tree/src/Commands/DevelCommands.php
 *   - http://git.drupalcode.org/devel/tree/drush.services.yml
 */
class UpdateCommands extends DrushCommands {

  /**
   * The key value store to use.
   *
   * @var \Drupal\Core\KeyValueStore\KeyValueStoreInterface
   */
  protected $keyValueStore;

  /**
   * @param \Drupal\Core\KeyValueStore\KeyValueFactoryInterface $key_value_factory
   *   The key value store to use.
   */
  public function __construct(KeyValueFactoryInterface $key_value_factory) {
    $this->keyValueStore = $key_value_factory;
  }

  /**
   * Corrects a field storage configuration. See https://www.drupal.org/project/drupal/issues/2916266 for more info
   *
   * @command update:correct-field-config-storage
   *
   * @param string $entity_type
   *   Entity type
   * @param string $bundle
   *   Bundle name
   * @param string $field_name
   *   Field name
   */
  public function correctFieldStorageConfig($entity_type, $bundle, $field_name) {
    $field_map_kv_store = $this->keyValueStore->get('entity.definitions.bundle_field_map');
    $map = $field_map_kv_store->get($entity_type);
    unset($map[$field_name]['bundles'][$bundle]);

    // Remove field definition if empty.
    if (empty($map[$field_name]['bundles'])) {
      unset($map[$field_name]);
    }

    $field_map_kv_store->set($entity_type, $map);

    // Remove entity type definition if empty after unsetting.
    if (empty($field_map_kv_store->get($entity_type))) {
      $field_map_kv_store->delete($entity_type);
    }
  }
}

6 - Inserisci il modulo nella cartella web/modules/custom/ del tuo sito, attivalo da interfaccia grafica o con drush en [MY_MODULE].

7 - Adesso puoi usare il comando drush custom che è stato appena creato con drush update:correct-field-config-storage [ENTITY_TYPE] [BUNDLE] [FIELD_NAME]. Usando l'esempio di prima otterremmo questo comando drush update:correct-field-config-storage paragraph text field_image.

8 - Dopo aver seguito il comando l'errore dovrebbe essere scomparso e puoi disabilitare il modulo con drush pmu [MY_MODULE] e successivamente rimuoverlo.

Un grande ringraziamento va alla community di Drupal che ha trovato la soluzione che ho leggermente modificato.

Come rimuovere le versioni di Snap per liberare spazio su disco

McAle — Fri, 07 Jun 2024 07:04:35 +0000

Fonte: How to Clean Up Snap Versions to Free Up Disk Space

Sintomi: la partizione contenente /var sta finendo lo spazio presente sul disco
Sistema Operativo: Linux Ubuntu

Questa veloce guida, con uno script, aiuta a fare pulizia delle vecchie versioni di snap e libera dello spazio sul disco.

Snap può consumare una notevole quantità di spazio di archiviazione perché mantiene in memoria le vecchie revisioni di un software per motivi di manutenzione.

Snap salva di default le ultime 3 revisioni del software, compresa la versione attualmente in uso. Questa impostazione può andar bene se non si hanno limitazioni sullo spazio occupato su disco.

Ma spesso per server e in altri casi, questa impostazione può portare a problematiche legate al consumo di memoria.

Tuttavia, puoi facilmente modificare il numero di revisioni salvate con il seguente comando. Il valore deve essere compreso tra 2 e 20.

sudo snap set system refresh.retain=2

Rimuovere le versioni di Snap

In un post sul sito superuser, l'utente Popey, ha fornito un semplice script che rimuove le vecchie versioni di Snap e mantiene l'ultima.

Utilizza nano o il tuo IDE preferito per creare un file nella cartella /bin/:

sudo nano /bin/clean_snap.sh

Questo è il contenuto dello script che utilizzeremo:

#!/bin/bash
#Rimuove le vecchie revisioni di snap
#CHIUDI TUTTE LE ISTANZE DI SNAP PRIMA DI ESEGUIRE QUESTO SCRIPT
set -eu
LANG=en_US.UTF-8 snap list --all | awk '/disabled/{print $1, $3}' |
    while read snapname revision; do
        snap remove "$snapname" --revision="$revision"
    done

Imposta come eseguibile il file:

sudo chmod +x /bin/clean_snap.sh

CHIUDI TUTTE LE ISTANZE DI SNAP e poi esegui lo script per rimuovere le vecchie versioni salvate:

sudo /bin/clean_snap.sh