Modifica il formato di input per oltre 3000 nodi

Ho molti nodi che devono cambiare il loro formato di input: potrei farlo a mano, ma poi non lo farò prima di Natale 2014.

Dove sta memorizzando tali informazioni Drupal? Come posso cambiare il formato di input in una frazione di secondo, con una query SQL?

Ho intenzione di prefigurare questa risposta dicendo che fare questo in massa presenta un potenziale rischio per la sicurezza, specialmente se stai cambiando il formato in un set di filtri più indulgente. I formati di testo modificano l'output del campo durante la visualizzazione, non durante il salvataggio. Quindi, ad esempio, qualsiasi HTML o PHP con escape precedente inviato a un campo verrà visualizzato / eseguito in modo corretto se si imposta accidentalmente o intenzionalmente il filtro su codice HTML o PHP completo.

È per questo motivo che Drupal non aggiorna automaticamente tutti i nodi esistenti quando si modifica un formato di testo. Il comportamento dei formati di testo in scenari simili è ancora un problema aperto .

Quindi di nuovo: attenzione, ci sono draghi.

Detto questo, ogni campo memorizza il testo come una colonna denominata field_foo_format, dove si field_footrova il nome della macchina del campo. Dovrai aggiornare quella colonna sulle tabellefield_revision_field_foo e field_data_field_foo.

Il valore per la colonna è un nome macchina definito come colonna formatnella filter_formattabella. Quindi, l'aggiornamento di tutti i campi sarebbe una questione di una query come:

UPDATE field_revision_foo SET field_foo_format = 'new_format';
UPDATE field_data_foo SET field_foo_format = 'new_format';

per ogni campo che deve essere modificato.

È possibile determinare il new_formatvalore qui: http://YOURSITE.com/admin/config/content/formats - configura collegamento - il numero o la stringa nell'URL è la new_format.cache vuota dopo l'aggiornamento.

Prova in questo modo, creando un ciclo per tutti i nodi di un determinato tipo:

$node = node_load(nid);
$node->body[$node->language][0]['format'] = 'full_html'; // plain_text
node_save($node);

Si è appena imbattuto nella stessa situazione di Morten qui, con un aggiornamento D6 => D7 che apparentemente non ha finito i formati di input.

Ha adottato un approccio più rozzo rispetto alle risposte già qui e ha scritto un modulo che correva attraverso lo schema del DB e ha aggiornato tutte le colonne che contengono la stringa "formato", sostituendo i valori del formato D6 (1, 2, 3) con i nomi di macchine D7 ( filtered_html, full_html,plain_text ).

https://gist.github.com/xurizaemon/9824872

Hardcoded per supportare la mappatura di

1 => filtered_html, 
2 => full_html,
3 => plain_text,

Potresti anche provare a riscrivere i campi che sono chiamati 'format' (es. "Date_format", ma se hai un formato data con valore '2', questo è il tuo problema).

Per me, ha funzionato:

update `field_revision_body` set `body_format` = 'new_body_forma' WHERE `bundle` = 'node_type'
update `field_data_body` set `body_format` = 'new_body_forma' WHERE `bundle` = 'node_type'

Ovviamente devi cambiare new_body_forma e node_type

È possibile utilizzare il seguente codice, se è installato entity.module.

// I'm using node_save($node); 
$wrapper = entity_metadata_wrapper('node', $node->nid); 
$wrapper->body->set(array('value' => body_text, 'format'=>'full_html'));

Presumibilmente vorrai sapere quali campi devono essere aggiornati, possibilmente per fare un po 'di registrazione o controlli sui dati. Per fare ciò, ottieni tutti i nomi di tabelle e colonne che contengono una _formatcolonna:

select distinct TABLE_NAME, column_name
from information_schema.columns
where TABLE_SCHEMA = 'my_drupal_database_name' and column_name like '%_format';

Grazie a questi dati è possibile creare query separate da tali valori. Controllare prima l'output; potrebbe essere necessario rimuovere alcune voci che non riguardano contenuti / revisioni. Consiglio di utilizzare un editor in grado di regex per creare le query. Ho trasformato i dati in un grandeselect [...] union affermazione e quindi eseguito le query di aggiornamento su di esso.

L'uso di questo approccio mi ha permesso di risparmiare parecchio tempo quando avevo bisogno di aggiornare migliaia di nodi / revisioni. Ricorda di cancellare la cache dei campi (NON coperta da drush cc all!):

field_cache_clear();

O con drush:

drush sqlq "truncate table cache_field;"

Rimozione anche del filtro di testo

Se stai anche ritirando un filtro di testo, successivamente dovrai modificare il formato di testo predefinito per i CT che avevano campi che lo utilizzavano. In caso contrario, i tuoi utenti riceveranno messaggi di autorizzazione negata all'interno dei campi che hanno utilizzato il old_format. Ho fatto questa domanda per trovare i colpevoli:

select * from field_config_instance where `data` LIKE '%old_format%';

Per apportare le modifiche, ho trovato più semplice utilizzare l'interfaccia per visitare ciascuna pagina delle impostazioni del campo e premere Salva (i dati sono memorizzati come longblob ed erano poco maneggevoli da cercare e sostituire a causa delle migliori iniezioni di dati del modulo formati). Anche i campi in cui l'elaborazione del testo era impostata su Plain textcontenevano il vecchio_formato! Per i campi in cui l'elaborazione del testo è impostata suFiltered text (user selects text format) , sarà inoltre necessario selezionare un nuovo valore predefinito e premere Salva.

Dovresti cancellare la cache del filtro dopo aver rimosso un filtro (di nuovo, non coperto da drush cc all!):

cache_clear_all('*', 'cache_filter', TRUE);

O con drush:

drush sqlq "truncate table cache_filter;"

update field_revision_body set body_format = 'full_html' WHERE bundle IN ('book','page');
update field_data_body set body_format = 'full_html' WHERE bundle IN ('book','page');

ha fatto il trucco per me. Non dimenticare di cancellare le cache