У мене є файл csv, який я хочу вставити, що складається з ~ 1500 рядків і 97 стовпців. Для повного імпорту потрібно близько 2-3 годин, і я хотів би покращити це, якщо є спосіб. В даний час для кожного рядка я роблю $ post_id = wp_insert_post, а потім add_post_meta для 97 асоційованих стовпців із кожним рядком. Це досить неефективно ...

Чи є кращий спосіб зробити це таким чином, щоб атрибут post_id міг зберігати зв’язок між публікацією та її значеннями post_meta?

Зараз я пробую це на своїй локальній машині з wamp, але він буде працювати на VPS

У мене були подібні проблеми колись тому зі спеціальним імпортом CSV, але я закінчив, використовуючи якийсь спеціальний SQL для масової вставки. Але я ще не бачив такої відповіді:

Оптимізувати вставку та видалити повідомлення для масових операцій?

використовувати wp_defer_term_counting()для включення або відключення підрахунку термінів.

Також якщо ви перевірите джерело плагіна імпортера WordPress, ви побачите ці функції безпосередньо перед масовим імпортом:

wp_defer_term_counting( true );
wp_defer_comment_counting( true );

а потім після масової вставки:

wp_defer_term_counting( false );
wp_defer_comment_counting( false );

Так що це може щось спробувати ;-)

Імпорт публікацій у вигляді чернетки замість публікації також пришвидшить роботу, оскільки пропускається повільний процес пошуку унікального для кожного з них. Можна, наприклад, опублікувати їх пізніше, але зазначити, що такий підхід повинен якось позначати імпортовані публікації, тому ми не просто публікуємо будь-які чернетки пізніше! Це потребує ретельного планування та, швидше за все, певного кодування.

Якщо є, наприклад, безліч подібних заголовків публікацій (однакових post_name), які потрібно імпортувати, то вони wp_unique_post_slug()можуть стати повільними, завдяки ітерації запитів циклу, щоб знайти доступний слизь. Це, можливо, може генерувати величезну кількість db запитів.

Оскільки WordPress 5.1 pre_wp_unique_post_slugфільтр доступний, щоб уникнути ітерації циклу для слизи. Дивіться основний квиток № 21112 . Ось приклад:

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
);

Якщо спробувати, наприклад $override_slug = _truncate_post_slug( $slug, 200 - ( strlen( $suffix ) + 1 ) ) . "-$suffix" з " $suffixas" $post_id, то зауважимо, що $post_idце завжди 0для нових постів, як очікувалося. Однак існують різні способи генерування унікальних чисел у PHP uniqid( '', true ). Але використовуйте цей фільтр з обережністю, щоб переконатися, що у вас є унікальні кулі. Ми можемо, наприклад, запустити запит підрахунку групи після цього, post_nameщоб бути впевненим.

Іншим варіантом буде використання WP-CLI, щоб уникнути тайм-ауту. Дивіться, наприклад, мою відповідь, опубліковану для створення 20000 повідомлень або сторінок за допомогою .csv-файлу?

Тоді ми можемо запустити наш спеціальний сценарій імпорту PHP за import.phpдопомогою команди WP-CLI:

wp eval-file import.php

Також уникайте імпорту великої кількості ієрархічних типів публікацій, оскільки поточний інтерфейс wp-admin не справляється з цим. Див., Наприклад, Спеціальний тип публікації - список публікацій - білий екран смерті

Ось чудова порада від @otto:

Перед масовими вставками вимкніть autocommitрежим прямо:

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

Після масових вставок запустіть:

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

Я також думаю, що було б непогано зайнятися господарством на зразок:

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

Я не перевіряв цього на MyISAM, але над цим слід працювати InnoDB .

Як згадував @kovshenin, ця порада не працюватиме для MyISAM .

Вам потрібно буде вставити публікацію, щоб отримати свій ідентифікатор, але $wpdb->postmetaтаблиця за структурою дуже проста. Можливо, ви можете використовувати прямий INSERT INTOвислів, наприклад, з документів MySQL:INSERT INTO tbl_name (a,b,c) VALUES(1,2,3),(4,5,6),(7,8,9);

У вашому випадку ...

$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}");

Це не стосується жодного кодування, серіалізації, виходу, перевірки помилок, дублювання чи будь-чого іншого, але я б очікував, що це буде швидше (хоча я не намагався).

Я б не робив цього на виробничому майданчику без ретельного тестування, і якби мені довелося це робити лише один-два рази, я б користувався основними функціями і довго обідав, коли речі імпортували.

Мені довелося додати це:

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

Майте на увазі, що це буде пропущено do_all_pings, що обробляє пінгбеки, корпуси, трекбеки та інші пінг (посилання: https://developer.wordpress.org/reference/functions/do_all_pings/ ). Я розумію, як дивитись на код, полягає в тому, що відкладені пінгбеки / трекбеки / корпуси все одно будуть оброблені після видалення цього remove_actionрядка, але я не зовсім впевнений.

Оновлення: я також додав

    define( 'WP_IMPORTING', true );

Крім того, я використовую:

    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 );

Важлива примітка про 'SET autocommit = 0;'

після встановлення, autocommit = 0якщо скрипт припиняє виконання (з якоїсь причини, наприклад exit, фатальної помилки чи т. д. ...), ваші зміни НЕ будуть збережені в БД!

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

update_option("something", "value");     

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

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

В цьому випадку update_option в БД не буде збережено!

Отож, найкраще порадити - COMMITзареєструватися у shutdownфункції як попередній вихід (у випадку, якщо трапиться якийсь несподіваний вихід).

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