Andrew Pisarevsky
Ответы в темах
-
Сайт не переносили?
Форум: Проблемы и решения
Тема: Вставка php-формы в поле виджетаСмотри как создаются виджеты в ВордПресс и подключай код формы в контент виджета. Ну и виджет нужно добавить в нужный сайдбар
Попробовал использовать константу но не вышло чего задумывалось. Я так понимаю константа define( ‘COOKIE_DOMAIN’, ‘example.com’ ); задает домен example.com как основной и куки на поддомены *.example.com не будут создаваться, а будут браться example.com?
И я не ошибаюсь в принципе работы кук, если что поправьте меня. Если зарегистрировать куку для *.example.com то она будет одна и для example.com и для test.example.com итд?
- Ответ изменён 6 лет, 4 месяца назад пользователем Andrew Pisarevsky.
Спасибо!
- Ответ изменён 6 лет, 4 месяца назад пользователем 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' );
ничего не нашел
- Ответ изменён 6 лет, 11 месяцев назад пользователем 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 (на хуки повесил).Что вы скажите по этому поводу. Целесообразное решение?
- Ответ изменён 6 лет, 11 месяцев назад пользователем Andrew Pisarevsky.
Да исходники, или может советы по реализации чего то CUSTOM на wp. Просто не видя чужих исходников, сложно оценить делаешь ты верно или нет.
Форум: Плагины
Тема: w3 total cache время кеширования страницПопробовал транзитный кеш кешировать на минуту, 2, 3. После 30-40сек кеш сбрасывается при включенном объектном кешировании. Вообще непонятно по каким принципам работает плагин. Время жизни объектного кеширования стоит 3600, а сборка мусора 6000.
Форум: Плагины
Тема: w3 total cache время кеширования страницСпасибо за развернутый ответ. Garbage collection interval — у меня стоит 1 час, время жизни самой страницы истекло, но мусор не удаляется пока я не обновлю именно эту страницу, довольно странно плагин работает,
так же время кеширования объектов имеется, но файлы удаляются через 30сек, вне зависимости от указанного вермени
не указал Template: name
в style.css