wordpressserg

Поковырялся я там немного в том плагине похожих постов – есть там функиция
**get_crp_posts_id()**

Takes a post ID and returns the related post IDs as an object.

Usage: `<?php if ( function_exists( ‘get_crp_posts_id’ ) ) { get_crp_posts_id( array(
<——>’postid’ => $postid,
<——>’limit’ => $limit,
) ); } ?>`

вроде как должна вернуть как раз то что нужно, вопрос как это правильно использовать внутри вашей функции get_related()…

а вот с объектным кэшем не совсем так… добавление нового поста никак не затрагивает другие закешированные посты…

ну так я и говорю зачем мне кеш всего фида, если до момента прихода яндекса он будет сброшен публикацией нового поста – это бессмысленно…

Мне актуально… но вам и самим должно быть интересно… иначе это уже платный запрос получается, а я еще даже не понял нужны ли мне турбо страницы вообще или нет… пока вместо роста вижу падение трафика и дохода… возможно потому что контент копипасат и в турбостраницах это легко отслеживается так как таких страниц сотни…

• This reply was modified 6 years, 1 month ago by wordpressserg.

Я имею ввиду обычный object cache соотвественно не важно во что он кеширует apcu или memcached или еще что… смысл в том что если объект $post запрашивалася то будет закеширован… и повторная генерация фида через 3-5 минут происходит мгновенно… но вот спустя какое то время я вижу что запрос от яндекса висит уже 50-60 секунд… а значит что то где то из каша вымылось – вопрос какого кэша т.к. у меня время жизни гораздо дольше стоит…
вот и вопрос почему так происходит…

а про кеширование всего фида – то понятно что можно, но как раз бессмыссленно если у меня в час 1-2 поста добавляются, а яндекс как раз раз в час обходит…

• This reply was modified 6 years, 1 month ago by wordpressserg.

Ха… если без полнотекстового поиска то обычно берется рандомные посты с теми же метками и из той же категории (ну и различные комбинации меток и категорий)… но тут ключевой момент рандомные (что плохо и медленно)… а если посты подрят то это не “похожие” посты, а просто предыдущие посты…

Установлено 25. Задача не одна и та же так как object_cache в apcu закешировал на сутки те посты данные которых плагин уже запрашивал…

ясно… кеширую в apcu (на сутки), но что то все равно долго после некоторого простоя генерится фид хотя там может всего один пост новый появился….

`И выбираются не случайные посты, а последние посты из таких же катерий что и у текущего поста.
То есть это получается что для поста id=100 выбирается посты с id 99,98,97,96,95,94,93,92,91,90,89 (условно)… тогда это вообще странный подход потому что эти же посты следом будут идти в фиде как основные…

Пока не проверял, хватило добавления в шаблон вывода строки с header… а чем ваш вариант лучше ?

Проблема решается добавлением в шаблон /templates/feed.php
header( 'X-Robots-Tag: index, follow', true );

Вам следует выкинуть этот скрипт и переписать заново, что бы это понять отпрофилируйте ваш скрипт – он один работает дольше чем весь вордперсс с двумя десятками других плагинов 200мс только на работу вашего скрипта норма для него… проблема вероятно в том, что вы постоянно, при любом чихе ВП делаете то, что не нужно делать до осуществления реального взаимодействия с ВК…

А про интерфейс – не смешивайте не смешиваемое и разделите плагин на несколько разных…

Oh I little mistaken de_DE only have

msgstr[0]
msgstr[1]

but ru_RU

msgstr[0]
msgstr[1]
msgstr[2]