Поддержка Плагины WP Super Cache не кэширует с локальных адресов

  • Решено xrayboy

    (@xrayboy)


    Заходишь с телефона, то кэширует.
    Заходишь с ПК дома, где 192.168 … НЕ кэширует.
    Не работает функция «Общий кэш» ( у них реализовано через wp_remote_get($url …) 127.0 …) ни «Режим предзагрузки», ни через cron php, который запускаю через cron linux wget …

    Почему он это делает и где копать?

Просмотр 8 ответов — с 1 по 8 (всего 8)
  • Модератор Yui

    (@fierevere)

    ゆい

    вообще-то ему все равно на адреса,
    скорее всего у вас просто есть куки о входе и включена настройка не кешировать страницы для известных пользователей (это правильная в большинстве случаев настройка)

    Автор xrayboy

    (@xrayboy)

    Тут какой-то иной бздик, ибо:
    1. я не залогирован.
    2. почистил куки.
    3. если заходишь на страницу, где копия сделана, то в комментах документа
    «<!— Dynamic page generated in 1.447 seconds. —>»
    «<!— Cached page generated by WP-Super-Cache on 2018-11-18 10:47:23 —>»
    4. если заходишь на страницу где копии нет, то копии физически не создаёт. И сколько не перезагружай, то надписи как в пункте 3 не увидишь.
    5. «Режим предзагрузки» не должен зависить от coockie, как и через cron.

    Автор xrayboy

    (@xrayboy)

    Решил пилить код и как бы не пришлось делать костыли.
    Обнаружилось, что функция is_dir не всегда определяет папку как папку когда символы пути кириллицей (/home/wp/www/wp-content/cache/supercache/<домен>/product/%d0%bc%d0%bd%d0%be%d0%b3%d0%be%d1%80%d0%b0%d0%b7%d0%be%d0%b2%d1%8b%d0%b9-%d1%86%d0%b2%d0%b5%d1%82-%d0%b2%d0%be%d0%bb%d0%be%d1%81-%d0%ba%d0%be%d0%bb%d0%bf%d0%b0%d1%87%d0%be%d0%ba-s-%d1%86%d0%b2%d0%b5/) и проходит отторжение через фукцию wpcache_do_rebuild( $dir ) {

    if ( !is_dir( $dir ) ) {
    wp_cache_debug( «wpcache_do_rebuild: exiting as directory is not a directory: $dir» );
    return false;
    }

    }
    Возможный костыль:
    Плохо, что получение значения папки ($dir) копий разбросано во многих местах и будет трудновато собрать все места преобразование пути, чтобы преобразовать условную данность в преобразованный путь.

    У меня на сайте более 200к страниц. Поэтому 200к копий размещённые в единственной папке какой-то тихий ужас.

    • Ответ изменён 3 года назад пользователем xrayboy.
    Модератор Yui

    (@fierevere)

    ゆい

    не на венде сервер случаем?

    функция is_dir не всегда определяет папку как папку когда символы пути кириллицей

    опять же юниксовые фс достаточно спокойно переваривают по 200к файлов на папку.
    ext4 в частности.

    • Ответ изменён 3 года назад пользователем Yui.
    Автор xrayboy

    (@xrayboy)

    Узкое место это самое медленное устройство чем и явлен HDD. При охеренном количестве объектов в папке опрос содержания папки у жёсткого диска вызывает длительные судороги.
    Пока нет возможности всё это барахло пихнуть в оперативную память.

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

    200к это не граница, будет 2,5кк+. В день добавляется около 2к страниц. И чем дальше тем больше судороги у жёсткого диска.

    Модератор Yui

    (@fierevere)

    ゆい

    а обязательно ли вообще кеширование при таком огромном количестве страниц?
    неужели на них на все заходят с таким трафиком, что серверу сложно становится просто заново страницу сгенерировать?
    Вполне достаточно установить кеширование на короткое время, чтобы в кеше жили самые посещаемые, их не должно быть уж очень много.

    И да, уточните, у вас именно страницы или все-таки записи? Если страницы, то WP плохо переваривает базу с огромным количеством страниц, в отличие от записей

    Автор xrayboy

    (@xrayboy)

    На счёт страницы или листы, то все оные лежат в единственной таблице wp_posts и выскрёбывание от туда чего либо с сортировкой занимает много времени. Поэтому мне пришлось изменить код WP и после обновления приходится постоянно менять код. Сортировка делается раз в сутки и лежит всё это в таблицах на движке MEMORY (в оперативной памяти). При обращении WP к получению чего либо идёт перехват и подсовывание отсортированных данных из «быстрых» таблиц.

    У меня слабое железо, чтобы думать о «в реальном времени». Генерация страницы занимает около 2 секунды. Раньше было больше 3 секунд и поисковик (робот-паук) ругался.
    Если брать готовые копии, то сайт начинает отдавать страницы за миллисекунды (2-30).

    На счёт «волшебности» is_dir оказывается она и простые пути не может адекватно воспринять: «<!— wp_cache_debug wpcache_do_rebuild: exiting as directory is not a directory: /home/wp/www/wp-content/cache/supercache/<домен>/page/2/ 1 —>»

    Если «/home/wp/www/wp-content/cache/supercache/<домен>/page/2/» не папка, то что?
    Чем дальше в «лес» тем суровее «партизаны».

    Автор xrayboy

    (@xrayboy)

    Виновником «отключения» кэширования оказался плагин «Advanced lazy load».
    Расследование:
    дебаг показал что «Page not cached by WP Super Cache. No closing HTML tag. Check your theme.»
    Согласно файла темы footer.php вывод документа полноценно заканчивался закрывающими тегами «</body></html>». Я даже поэкспериментировал те ли это закрывающие теги, поставив после них «</body></html>12345». После обработки на выходе получалось «… 12345 …</body></html>» (вот это кувырки!).
    Обнаружилось, что наш WP_Super_Cache не первый хотелец пооперировать с буфером вывода. И кроме его запуска в виде
    ob_start( ‘wp_cache_ob_callback’ );
    было ещё
    ob_start(«Advaced_lazyload»);
    ob_start( ‘nxs_ogtgCallback’ );
    В итоге выходило, что при каких то условиях:
    if (!is_admin() and (!wp_is_mobile() or get_option(‘cb_adlzylad_mobile’)==»on»)){

    if (!strposa($currURL, explode(«\n», $skipURL_value))) {
    ob_start(«Advaced_lazyload»);
    }

    }
    Callback-функция «Advaced_lazyload» отваливалась и «не мешала». В итоге WP_Super_Cache находил нужные для него закрывающие теги и начинал кэшировать страницу.
    Теория:
    Из-за разных манипуляций с выводом какой-то плагин, их может быть много, запускает ob_start ([callback])(включает буферизацию вывода).
    Кто последний запустил буферизацию с callback функцией, то та callback-функция последняя получит буфер.
    Каждая функция кувыркает буфер как может и как знает, то есть насколько кривые руки и мозг был у программиста, то настолько криво и будет работать на выходе.

    ЗЫ: Программисты данного плагина в некоторых логах пишут так, что могут ввести в заблуждение.

Просмотр 8 ответов — с 1 по 8 (всего 8)
  • Тема «WP Super Cache не кэширует с локальных адресов» закрыта для новых ответов.