Cambiar el formato de entrada para más de 3000 nodos

Tengo muchos nodos que necesitan cambiar su formato de entrada; podría hacerlo a mano, pero no terminaré antes de Navidad de 2014.

¿Dónde está Drupal almacenando esa información? ¿Cómo puedo cambiar el formato de entrada en una fracción de segundo, con una consulta SQL?

Voy a prefacio esta respuesta diciendo que hacer esto en masa presenta un riesgo potencial de seguridad, especialmente si está cambiando el formato a un conjunto de filtros más indulgente. Los formatos de texto modifican la salida del campo durante la visualización, no durante el guardado. Entonces, por ejemplo, cualquier HTML o PHP previamente escapado enviado a un campo se renderizará / ejecutará directamente si accidental o intencionalmente configura el filtro en HTML completo o código PHP.

Es por esta razón que Drupal no actualiza automáticamente todos los nodos existentes cuando cambia un formato de texto. El comportamiento de los formatos de texto en escenarios similares sigue siendo un problema abierto .

Así que de nuevo: cuidado, habrá dragones.

Dicho esto, cada campo almacena el texto como una columna llamada field_foo_format, donde field_fooestá el nombre de la máquina del campo. Deberá actualizar esa columna en las tablas field_revision_field_fooy field_data_field_foo.

El valor de la columna es un nombre de máquina definido como la columna formaten la filter_formattabla. Entonces, actualizar todos los campos sería cuestión de una consulta como:

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

para cada campo que necesita cambiar.

Puede determinar el new_formatvalor aquí: http://YOURSITE.com/admin/config/content/formats - configure link - el número o la cadena en la URL es su new_format.caché Clear después de la actualización.

Pruebe de esta manera, haciendo un ciclo para todos los nodos de cierto tipo:

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

Me encontré con la misma situación que Morten hizo aquí, con una actualización D6 => D7 que aparentemente no terminó los formatos de entrada.

Tomó un enfoque más crudo que las respuestas ya aquí, y escribió un módulo que ejecutó el esquema de base de datos y actualizó todas las columnas que contienen el 'formato' de cadena, reemplazando los valores de formato D6 (1, 2, 3) con nombres de máquinas D7 ( filtered_html` full_html` plain_text).

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

Codificado para admitir el mapeo de

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

También podría intentar reescribir campos que se denominan 'formato' (por ejemplo, "formato de fecha", pero si tiene un formato de fecha con el valor '2', ese es su problema).

Para mí, lo siguiente funcionó:

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'

Por supuesto, debe cambiar new_body_forma y node_type

Puede usar el siguiente código, si tiene instalado 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'));

Presumiblemente, querrá saber qué campos necesitan actualizarse, posiblemente para realizar algunos registros o verificaciones de los datos. Para hacer esto, obtenga todos los nombres de tabla y columna que contengan una _formatcolumna:

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

Armado con estos datos, puede crear consultas separadas a partir de esos valores. Verifique la salida primero; Es posible que deba eliminar algunas entradas que no pertenecen al contenido / revisiones. Recomiendo usar un editor con capacidad para expresiones regulares para construir las consultas. Convertí los datos en una gran select [...] uniondeclaración y luego ejecuté consultas de actualización en su contra.

El uso de este enfoque me ahorró bastante tiempo cuando necesitaba actualizar miles de nodos / revisiones. Recuerde borrar el caché de campo (¡NO cubierto por drush cc all!):

field_cache_clear();

O con drush:

drush sqlq "truncate table cache_field;"

También eliminando filtro de texto

Si también está retirando un filtro de texto, luego deberá cambiar el formato de texto predeterminado para los CT que tenían campos que lo usaron. Si no hace esto, sus usuarios recibirán mensajes de permiso denegado dentro de los campos que usaron old_format. Hice esta consulta para encontrar a los culpables:

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

Para hacer los cambios, encontré que era más fácil usar la interfaz para visitar la página de configuración de cada campo y presionar Guardar (los datos se almacenan como bloque largo y no era fácil de buscar y reemplazar debido a las mejores inyecciones de datos del módulo de formatos). ¡Incluso los campos que tenían el procesamiento de texto configurado para Plain textcontener el formato antiguo! Para los campos que tienen Procesamiento de texto establecido enFiltered text (user selects text format) , también deberá seleccionar un nuevo valor predeterminado y presionar Guardar.

Debería borrar el caché del filtro después de eliminar un filtro (de nuevo, ¡no está cubierto por 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');

hizo el truco para mí No olvides limpiar cachés