Tengo un archivo csv que quiero insertar que consta de ~ 1,500 filas y 97 columnas. Se necesitan entre 2 y 3 horas para realizar una importación completa y me gustaría mejorar esto si hay alguna manera. Actualmente para cada fila estoy haciendo un $ post_id = wp_insert_post y luego un add_post_meta para las 97 columnas asociadas con cada fila. Esto es bastante ineficiente ...

¿Hay una mejor manera de hacer esto de una manera que pueda obtener un post_id para mantener la relación entre post y sus valores post_meta?

En este momento estoy probando esto en mi máquina local con wamp pero lo tendré funcionando en un VPS

Hace algún tiempo tuve problemas similares con una importación CSV personalizada, pero terminé usando un SQL personalizado para la inserción masiva. Pero no había visto esta respuesta para entonces:

¿Optimizar la inserción y eliminación de publicaciones para operaciones masivas?

para wp_defer_term_counting()habilitar o deshabilitar el conteo de términos.

Además, si revisa la fuente del complemento importador de WordPress, verá estas funciones justo antes de la importación masiva:

wp_defer_term_counting( true );
wp_defer_comment_counting( true );

y luego después de la inserción masiva:

wp_defer_term_counting( false );
wp_defer_comment_counting( false );

Entonces esto podría ser algo para probar ;-)

Importar publicaciones como borrador en lugar de publicar también acelerará las cosas, ya que se omite el lento proceso de encontrar una babosa única para cada una. Uno podría, por ejemplo, publicarlos más tarde en pasos más pequeños, pero tenga en cuenta que este tipo de enfoque necesitaría marcar las publicaciones importadas de alguna manera, ¡así que no publicaremos ningún borrador más adelante! Esto necesitaría una planificación cuidadosa y muy probablemente una codificación personalizada.

Si, por ejemplo, se importan muchos títulos de publicaciones similares (iguales post_name), wp_unique_post_slug()puede volverse lento, debido a la iteración de la consulta de bucle para encontrar una babosa disponible. Esto posiblemente puede generar una gran cantidad de consultas db.

Desde WordPress 5.1, el pre_wp_unique_post_slugfiltro está disponible para evitar la iteración del bucle de la babosa. Ver boleto principal # 21112 . Aquí hay un ejemplo:

add_filter( 'pre_wp_unique_post_slug', 
    function( $override_slug, $slug, $post_id, $post_status, $post_type, $post_parent ) {
        // Set a unique slug value to shortcircuit the slug iteration loop.
        // $override_slug = ...

        return $override_slug;
    }, 10, 6
);

Si uno intenta, por ejemplo, $override_slug = _truncate_post_slug( $slug, 200 - ( strlen( $suffix ) + 1 ) ) . "-$suffix"con $suffixas $post_id, entonces notaríamos que $post_idsiempre es 0para nuevas publicaciones, como se esperaba. Sin embargo, hay varias formas de generar números únicos en PHP, como uniqid( '', true ). Pero use este filtro con cuidado para asegurarse de tener babosas únicas. Podríamos, por ejemplo, ejecutar una consulta de recuento grupal después post_namepara estar seguros.

Otra opción sería usar WP-CLI para evitar el tiempo de espera. ¿Ve, por ejemplo, mi respuesta publicada para Crear 20,000 publicaciones o páginas usando un archivo .csv?

Luego podemos ejecutar nuestro script de importación PHP personalizado import.phpcon el comando WP-CLI:

wp eval-file import.php

También evite importar una gran cantidad de tipos de publicaciones jerárquicas, ya que la interfaz de usuario actual de wp-admin no lo maneja bien. Ver, por ejemplo, tipo de publicación personalizada - lista de publicaciones - pantalla blanca de la muerte

Aquí está el gran consejo de @otto:

Antes de las inserciones masivas , deshabilite el autocommitmodo explícitamente:

$wpdb->query( 'SET autocommit = 0;' );

Después de las inserciones masivas, ejecute:

$wpdb->query( 'COMMIT;' );

También creo que sería una buena idea hacer algunas tareas de limpieza como:

$wpdb->query( 'SET autocommit = 1;' );

No he probado esto en MyISAM pero debería funcionar en InnoDB .

Como mencionó @kovshenin, este consejo no funcionaría para MyISAM .

Deberá insertar la publicación para obtener su ID, pero la $wpdb->postmetatabla tiene una estructura muy simple. Probablemente podría usar una INSERT INTOdeclaración directa , como esta de los documentos de MySQL:INSERT INTO tbl_name (a,b,c) VALUES(1,2,3),(4,5,6),(7,8,9);

En tu caso...

$ID = 1; // from your wp_insert_post
$values = '($ID,2,3),($ID,5,6),($ID,8,9)'; // build from your 97 columns; I'd use a loop of some kind
$wpdb->query("INSERT INTO {$wpdb->postmeta} (post_id,meta_key,meta_value) VALUES {$values}");

Eso no se ocupará de ninguna codificación, serialización, escape, verificación de errores, duplicaciones o cualquier otra cosa, pero esperaría que fuera más rápido (aunque no lo he intentado).

No haría esto en un sitio de producción sin una prueba exhaustiva, y si solo tuviera que hacerlo una o dos veces, usaría las funciones principales y tomaría un largo almuerzo mientras las cosas se importan.

Tuve que agregar esto:

    remove_action('do_pings', 'do_all_pings', 10, 1);

Tenga en cuenta que esto saltará do_all_pings, lo que procesa pingbacks, recintos, trackbacks y otros pings (enlace: https://developer.wordpress.org/reference/functions/do_all_pings/ ). Según remove_actiontengo entendido al mirar el código, los pingbacks / trackbacks / recintos pendientes aún se procesarán después de eliminar esta línea, pero no estoy completamente seguro.

Actualización: también agregué

    define( 'WP_IMPORTING', true );

Más allá de eso estoy usando:

    ini_set("memory_limit",-1);
    set_time_limit(0);
    ignore_user_abort(true);

    wp_defer_term_counting( true );
    wp_defer_comment_counting( true );
    $wpdb->query( 'SET autocommit = 0;' );

    /* Inserting 100,000 posts at a time
       including assigning a taxonomy term and adding meta keys
       (i.e. a `foreach` loop with each loop containing:
       `wp_insert_post`, `wp_set_object_terms`, `add_post_meta`.)
    */

    $wpdb->query( 'COMMIT;' );
    wp_defer_term_counting( false );
    wp_defer_comment_counting( false );

Nota importante sobre 'SET autocommit = 0;'

después de configurar autocommit = 0si el script detiene la ejecución (por alguna razón, como un exiterror fatal o etc.), entonces sus cambios NO SE GUARDARÁN EN DB!

$wpdb->query( 'SET autocommit = 0;' );

update_option("something", "value");     

exit; //lets say, here happens error or anything...

$wpdb->query( 'COMMIT;' );

¡En este caso update_optionno se guardará en DB!

Por lo tanto, el mejor consejo es haberse COMMITregistrado en shutdownfunción como precaución (en caso de que ocurra una salida inesperada).

register_shutdown_function( function(){
    $GLOBALS['wpdb']->query( 'COMMIT;' );
} );