Крупные нестандартные проекты на WP в открытом доступе

Да исходники, или может советы по реализации чего то CUSTOM на wp. Просто не видя чужих исходников, сложно оценить делаешь ты верно или нет.

Меня очень сильно тревожит момент что все мета данные о посте находятся в wp_postmeta и когда я делаю выборку в каталоге товаров по типу, странам, салонам, брендам итд, получается огромный sql запрос, потому что все хранится не в одной таблице в строчку для данного POST_TYPE а в таблице post_meta в столбик. Вместо 1 inner join мы получаем 3-5.
Из-за этого мой сайт стал грузиться очень долго. Порядка 1.5-3 сек за запрос (Это на 4 ядерном сервере, с 8гб озу).
Мы используем плагин ACF pro для создания meta полей к постам. Из-за того что выборки очень долгие.
Я принял решение Создать свои отдельные таблицы для post_type salon, product, product_salon. И реплицировать мета данные при сохранении этих ACF field (на хуки повесил).

Что вы скажите по этому поводу. Целесообразное решение?

• Ответ изменён 7 лет, 10 месяцев назад пользователем Andrew Pisarevsky.

Я так делал каталог продуктов: формальные атрибуты продуктов в отдельной таблице, остальное — штатно в postmeta.

Я так понимаю вы создали свою произвольную таблицу? А обращались вы к ней с помощью $wpdb ?
У нас программист который писал техническое задание категорически запрещает использовать $wpdb ( «говорит что это прямые запросы в БД,и использовать ее нельзя» ), требует все делать через WP_QUERY и через фильтры

add_filter('posts_fields', 'tt_posts_fields');
add_filter('posts_join', 'tt_posts_join');
add_filter('posts_where', 'tt_posts_where');
add_filter('posts_orderby', 'tt_posts_orderby');
add_filter( 'posts_groupby', 'tt_posts_groupby' );

В итоге мы получаем не читаемый код выборки на страницах

    global $mam_global_join, $mam_global_where;
    $mam_global_join = '
        INNER JOIN wp_postmeta AS pm2 ON ( wp_postmeta.post_id = pm2.post_id ) 
        INNER JOIN wp_postmeta AS pm3 ON ( pm2.meta_value = pm3.post_id ) 
    ';
    $mam_global_where = '
        AND pm2.meta_key =  \'tt_sp_salon\'
        AND pm3.meta_key =  \'tt_salon_region\'
        AND pm3.meta_value = ' . $tt_currnet_region['ID_region'] . '
    ';
}

$salon_product_query = new WP_Query( $args );

$mam_global_join, $mam_global_where — они как раз через те фильтры и дополняют запрос.

Я не вижу ничего страшного в использовании $wpdb, при условии что мы используем кеширование запросов.

        $post = wp_cache_get( $post_id, GROUP_CACHE_PRODUCT );
        if( ! $post ) {
            $post = $wpdb->get_row( $wpdb->prepare( 'SELECT * FROM tt_product WHERE post_id = %d LIMIT 1', $post_id ) );
            wp_cache_set( $post_id, $post, GROUP_CACHE_PRODUCT );
        }

Конечно чтобы генерировать хорошие ключи кеша мне кажется должен быть «класс» уже написанный кем-то, чтобы это дело стандартизировать, но такого я не нашел.

Что вы скажете по этому поводу, как правильно реализовывать выборку, является ли $wpdb таким злом.

Спасибо. Насчет ACF мы использовали его, т.к. очень удобно помогает добавлять произвольные поля. Да и чтобы что-то прикрутить равное по интерфейсу ACF в админке, придется неимоверные усилия приложить, или может имеются фреймворки позволяющие легко работать с полями?
А как вы MAIN_QUERY запросы изменяете в тех же архивах, я кроме варианта через

add_filter('posts_fields', 'tt_posts_fields');
add_filter('posts_join', 'tt_posts_join');
add_filter('posts_where', 'tt_posts_where');
add_filter('posts_orderby', 'tt_posts_orderby');
add_filter( 'posts_groupby', 'tt_posts_groupby' );

ничего не нашел

• Ответ изменён 7 лет, 10 месяцев назад пользователем Andrew Pisarevsky.

У нас программист который писал техническое задание категорически запрещает использовать $wpdb ( «говорит что это прямые запросы в БД,и использовать ее нельзя» ), требует все делать через WP_QUERY и через фильтры

Та ну. Это справедливо (с оговорками) для штатных запросов и штатных таблиц. Кастомные на то и кастомные, чтобы обцаться с ними по-своему.

кастомные таблицы я уже ввел, из-за большой потери в выборке.
Изначально все было на штатных таблицах, но чтобы получить достойный запрос с наибольшей скоростью выборки — приходилось прибегать к такому методу

    global $mam_global_join, $mam_global_where;
    $mam_global_join = '
        INNER JOIN wp_postmeta AS pm2 ON ( wp_postmeta.post_id = pm2.post_id ) 
        INNER JOIN wp_postmeta AS pm3 ON ( pm2.meta_value = pm3.post_id ) 
    ';
    $mam_global_where = '
        AND pm2.meta_key =  \'tt_sp_salon\'
        AND pm3.meta_key =  \'tt_salon_region\'
        AND pm3.meta_value = ' . $tt_currnet_region['ID_region'] . '
    ';
}

$salon_product_query = new WP_Query( $args );

Является ли это правильным решением?

Юрий, а с помощью чего вы реализовывали интерфейс добавления полей к постам в админке? Допустим если эти поля пойдут в custom table?