Недійсні типи блоків


9

Я отримую таке повідомлення про помилку кілька разів на день, і мої знання про внутрішню роботу Magento CE 1.9.0.1 є досить тонкими, що я не знаю, чи це нормальна, консультативна поведінка від Magento, або якщо вона говорить зі мною у мене погана проблема.

Ось повідомлення:

Один або кілька типів кешу недійсні: блокує вихід HTML. Натисніть тут, щоб перейти до кешування керу та оновити типи кешу.

Оновлення певного кешу змушує проблему відійти на пару годин.

Я зараз не редагую макети, продукти тощо, взагалі нічого.

Що не так і як це можна виправити?


Я отримую це щодня, коли прокидаюся та входжу на Magento v1.9.2.2 - Один чи більше типів кешу недійсні: Блокує вихід HTML. Натисніть тут, щоб перейти до кешування керу та оновити типи кешу. Я ніколи не використовував це для попередніх версій, якщо я справді щось не робив. Це якась помилка?
Ніл Харт

Відповіді:


6

По-перше, важливо зрозуміти, що це не помилка, це лише повідомлення.

Причин може бути недійсним кеш-пам'ять блоку від оновлень до продуктів, зміни правил у каталогах і розширень сторонніх розробників. Також виконання cronjobs також може призвести до недійсності блоків кеш-пам'яток.

Доступні розширення спільноти (перелічені нижче), які оновлюють ваші блоки, коли вони стають недійсними.

https://github.com/tomasinchoo/Inchoo_InvalidatedBlockCacheFix

https://github.com/mklooss/Loewenstark_InvalidCache


2

Це помилка.

Існує проблема завдання CRON (пост. 1.9?), Яка запускає та визнає недійсним кеш HTML, який створює проблеми (наприклад, у моєму випадку не вдалося перенести знижку на ціну до кошика - тому з клієнта стягується неправильна сума).

Нам не потрібно запускати розширення, щоб виправити проблему, яка була введена!


Я маю таку саму поведінку на CE 1.9.2.2, щоранку вихід HTML-блоків потрібно оновлювати і думати про проблему роботи з хроном. @Brian, ти міг би дати докладніші відомості про це завдання щодо cron?
Марк

Я думаю, що ти думаєш, проте назад: Справа не в тому, що "ціна не перейшла в кошик", а скоріше, щоб ціна на сторінці була додана в кеш, перш ніж оновлення пройшло, і тому кеш був неправильним , при цьому правильна ціна показана у кошику. Хоча для покупця вони, ймовірно, думають, що будь-яка ціна нижча, є "правильною".
Eric Seastrand

@Brian, Не могли б ви дати детальнішу інформацію про завдання cron, яке скасовувало ваші блоки?
Хаїм

0

Це стандартна операція Magento від 1.6.xx і далі. Завжди щось викликає виправдання випадкового кеша блоку html-блоку.

Я просто встановив спостерігача, який спрацьовує на періодичній роботі з крон, встановлюючи будь-який інтервал, який здається підходящим.

Observer.php

<?php

/************************
 * Find invalidated cache types and refresh
 *
 * Set Cron Time for refresh in config.xml
 *
 */

class Fiasco_Rcache_Model_Observer {

    public function refreshCache() {

        try {

            $types = Mage::app()->getCacheInstance()->getInvalidatedTypes();

            foreach($types as $type) {

                Mage::app()->getCacheInstance()->cleanType($type->getId());

            }

            Mage::log('Invalid Cache Types Refreshed');

        } catch (Exception $e) {

            Mage::logException($e);

        }
    }
}

config.xml

<?xml version="1.0"?>
<config>
    <modules>
        <Fiasco_Rcache>
            <version>0.5.0</version>
        </Fiasco_Rcache>
    </modules>
    <global>
        <models>
            <refresh_cache>
                <class>Fiasco_Rcache_Model</class>
            </refresh_cache>
        </models>
    </global>
    <crontab>
        <jobs>
            <refresh_cache>
                <!-- Min Hour Day Month DoW -->
                <schedule><cron_expr>0 */3 * * *</cron_expr></schedule>
                <run><model>refresh_cache/observer::refreshCache</model></run>
            </refresh_cache>
        </jobs>
    </crontab>
</config>

0

Цей недійсний показник кешу, ймовірно, пов'язаний з кроном dailyCatalogUpdate. Він несе відповідальність за застосування / оновлення правил каталогу.

Раз на день дзвонить Mage::getSingleton('catalogrule/rule')->applyAll();.

Всередині коду цього методу є виклик $this->_invalidateCache(), який , в свою чергу , викликає $this->_app->getCacheInstance()->invalidateType()на block_htmlкеш.

Проблема полягає в тому, що він визнає недійсним кеш, не роблячи жодних перевірок, щоб визначити, чи може він насправді все-таки дійсний. Для мене це краще , ніж НЕ недійсності кешу, тому що тоді ви можете принаймні , знати , що це може бути недійсним, і використовувати що - щось на зразок того, що Fiasco Labs запропонували промивати (потенційно) недійсними кешированниє дані.

Потім вирішується питання про те, чи потрібно помилка на стороні:

A) Показати клієнтам неправильну ціну, але зберігаючи кеш і, таким чином, менше завантажуючи сервер

або

В) Показати правильну ціну, але мати більше пропусків кешу, а отже, і більшу завантаженість сервера.

У інформатиці є дві важкі речі: іменування речей та вимкнення кешу .


0

дивіться тут рішення: https://magento.stackexchange.com/a/72687

В основному змініть функцію dailyCatalogUpdate з app / code / local / Mage / CatalogRule / Model / Observer.php на

        $collection = Mage::getResourceModel('catalogrule/rule_collection')
        ->addFieldToFilter('is_active', array('neq' => 0));
    if ($collection->getSize() == 0) {
        return $this;
    }
    parent::dailyCatalogUpdate($observer);
    $types = Mage::getConfig()->getNode('global/catalogrule/related_cache_types')->asArray();
    foreach (array_keys($types) as $type) {
        Mage::app()->getCacheInstance()->cleanType($type);
    }
    return $this;
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.