Ответы в темах

Просмотр 15 ответов — с 1 по 15 (всего 100)
  • Сайт не переносили?

    Смотри как создаются виджеты в ВордПресс и подключай код формы в контент виджета. Ну и виджет нужно добавить в нужный сайдбар

    Попробовал использовать константу но не вышло чего задумывалось. Я так понимаю константа define( ‘COOKIE_DOMAIN’, ‘example.com’ ); задает домен example.com как основной и куки на поддомены *.example.com не будут создаваться, а будут браться example.com?

    И я не ошибаюсь в принципе работы кук, если что поправьте меня. Если зарегистрировать куку для *.example.com то она будет одна и для example.com и для test.example.com итд?

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

    Спасибо!

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

    получается данные мета полей дублируются и в wp_postmeta и в custom table?

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

    Последнее время — в основном фильтром ‘pre_get_posts’

    Да да перепутал, main_query меняется через этот фильтр, а если нужно сделать запрос вида

    SELECT * FROM wp_posts 
    INNER KOIN custom_table ON custom_table.post_id = wp_posts.ID

    то есть подключить уже CUSTOM таблицу в выборку, в этом случае я писал что использовал бы

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

    Это будет верным решением?

    У нас программист который писал техническое задание категорически запрещает использовать $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 );

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

    Спасибо. Насчет 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' );

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

    • Ответ изменён 5 лет, 1 месяц назад пользователем 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 таким злом.

    Меня очень сильно тревожит момент что все мета данные о посте находятся в 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 (на хуки повесил).

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

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

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

    Попробовал транзитный кеш кешировать на минуту, 2, 3. После 30-40сек кеш сбрасывается при включенном объектном кешировании. Вообще непонятно по каким принципам работает плагин. Время жизни объектного кеширования стоит 3600, а сборка мусора 6000.

    Спасибо за развернутый ответ. Garbage collection interval — у меня стоит 1 час, время жизни самой страницы истекло, но мусор не удаляется пока я не обновлю именно эту страницу, довольно странно плагин работает,

    так же время кеширования объектов имеется, но файлы удаляются через 30сек, вне зависимости от указанного вермени

    не указал Template: name
    в style.css

Просмотр 15 ответов — с 1 по 15 (всего 100)