Magento как очистить кэш

Обновлено: 07.07.2024

Я хотел бы знать, есть ли какая-либо предпочтительная процедура для следующего:

  1. Очистка кэша Magento
  2. Включение / отключение компилятора Magento

1. Очистка кэша Magento

Здесь есть несколько вариантов, а именно:

  • Проверка позиций и отправка обновления из Actions выпадающего списка
  • Нажав на Flush Magento Cache кнопку, и
  • Нажав на Flush Storage Cache кнопку

Есть ли предпочтительный порядок, в котором это сделать? В чем разница между кешем Magento и кешем хранения?

2. Включение / отключение Magento Compiler

а) Включение компилятора

Когда дело доходит до включения компилятора Magento, нужно ли включать все кэши хранилища? Или вы должны активировать кэши только после включения компилятора и запуска процесса компиляции? После того, как вы включили компилятор, вы должны обновить все кэши? И если да, то включает ли он очистку кеша и кеша хранения Magento (как упоминалось выше)

б) Отключение компилятора

Что касается отключения компилятора Magento, следует ли сначала отключить все кэши, а затем снова включить их после того, как он был отключен?

Есть ли разница между включением кэшей и отключением / включением компилятора? Какое влияние на производительность это вызывает?

Любой вклад будет высоко ценится

Его легко запомнить. Не очищайте кэш в производственном магазине. Не включайте кеш в магазине разработки. И если очистка кеша в вашем производственном хранилище приводит к сбою сайта, вы не провели достаточного тестирования на промежуточном сервере, и какой-то плохой код прошел, поэтому «Не включайте кеш в хранилище разработки». Очистка кеша никогда не должна вызывать сбой Magento. Ошибка CBR (выполнить до готовности)

Flush Magento Cache - очищает кэш (var / cache) от всех предметов, которые Magento знает, что он создал.

Flush Cache Storage - очищает все в var / cache, независимо от того, как были созданы эти файлы.

Итак, если вы хотите быть в безопасности, вы очищаете все, вы можете выбрать « Flush Cache Storage », который по существу очистит var / cache.

Для компилятора я бы рекомендовал очистить кеш Magento после включения компиляции и запуска процесса компиляции. Это гарантирует, что кэш очищен от любых не скомпилированных данных.

При отключении компиляции я сначала отключил бы ее, а затем очистил кэш Magento. Это снова гарантирует, что кэш очищен от любых скомпилированных данных.

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

Скорее всего, было бы лучше использовать такие вещи, как кэш кода операции в PHP, правильное кэширование запросов MySQL, объединение файлов css / js, сжатие gzip, расширение Full Cache и правильные настройки кэширования файлов в браузере.

Кеш Magento ничем не отличается. Начиная с основ, можно просмотреть параметры кэша, перейдя к

в бэкэнде. Вы можете увидеть различные области кэширования, которые можно включить / отключить, такие как любые конфигурации, layout.xml, блоки, полная страница и файлы API. Очевидно, что в идеале все они должны быть включены, как только сайт заработает.

Отсюда также можно очистить или очистить кэш. Нажатие кнопки с меткой “Flush Magento Cache” очистит все файлы кэша, которые соответствуют определенному набору встроенных тегов по умолчанию, которые использует Magento. Это «более безопасный» способ очистки кэша, поскольку он не очищает абсолютно все. Если вы используете какие-либо дополнительные типы кеша, то щелчок “Flush Cache Storage” гарантирует, что вы очистили кеш, так как он очищает ВСЕ. Две другие кнопки, которые вы видите на странице администратора, будут очищать javascript, css и каталог изображений.

Альтернативный и немного менее безопасный способ очистки кэша - переход к

и вручную удалив все файлы. То же самое касается

websiteroot / вар / full_page__cache

если у вас включен полный кеш страниц.

Полный кеш страниц, доступный в Enterprise Edition, ускоряет ваш сайт в 10 раз, но важно знать об этом немного, на случай, если вы заметите, что любой динамический контент кэшируется. Интересный файл для просмотра

websiteroot / приложение / код / ​​ядро ​​/ Enterprise / кэш страниц / и т.д. / cache.xml

Здесь вы можете увидеть, что кэшируется FPC, имя блока, имя контейнера и время жизни сеанса. Если вы обнаружите, что абсолютно необходимо отредактировать или удалить какой-либо из этих блоков из кэша, вы можете сделать это, создав модуль, зависящий от модуля PageCache, и разместив там любые изменения.

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

Компиляцию Magento можно найти в разделе

Когда Magento компилирует свой исходный код, фреймворк делает несколько вещей. Будучи либо срабатывает через администратор или shell, see shell/compiler.php , все компиляции выполняются одним классом: Mage_Compiler_Model_Process . В этом классе вы найдете следующий фрагмент, который на самом деле представляет собой весь процесс с высоты птичьего полета.

Стартовало по $this->_collectFiles(); вызову, Magento копирует все PHP файлы как

и каталоги lib для

каталог. Как вы можете видеть из фрагмента ниже: во время этого процесса Magento рекурсивно перебирает все файлы и каталоги. Эти пути в конечном итоге используются в качестве имени файла. Когда рекурсивный процесс попадает в файл, он проверяет расширение PHP и, если он найден, файл копируется в каталог компилятора. Другие типы файлов остаются нетронутыми.

Как пример: путь для класса Mage_Catalog_Model_Category был

Приложение / код / ​​ядро ​​/ Mage / Каталог / Модель / category.php

но с включенной компиляцией теперь стало

включает / SRC / Mage_Catalog_Model_Category.php

Контролеры получают другое лечение. Все каталоги контроллеров копируются в

но хранятся в каталоге, который имеет имя связанного с ним пространства имен, подумайте: Mage, Enterprise или ваше собственное пространство имен.

В этих каталогах пространства имен контроллеры хранятся в каждом модуле, а структура каталогов контроллера остается неизменной. То же самое касается имени файла, это просто точная копия. Всю эту логику можно найти в следующем методе $this->_copyControllers($path);

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

По умолчанию Magento создает четыре разных файла области:

__default.php, __catalog.php, __checkout.php и __cms.php

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

Когда все файлы на месте и скомпилированы, Magento готова включить функцию компиляции для использования.

И последнее, но не менее важное: настройка, связанная с компиляцией Этот файл можно найти по адресу includes/config.php и содержит следующие две константы. После включения компиляции строка, касающаяся COMPILER_INCLUDE_PATH, не комментируется и, таким образом, готова к действию.

Код, отвечающий за настройку файла конфигурации, можно найти в методе registerIncludePath объекта Mage_Compiler_Model_Process class .

Во время начальной загрузки файл конфигурации компиляции включается в index.php file (around line 44) . Это делает константы include_path доступными во всей структуре. Параметр collect_path можно включить только вручную, чтобы получить дополнительную статистическую информацию об использовании ваших скомпилированных файлов. Это не должно быть включено в прямом эфире.

С этого момента Magento проверит, включен ли режим компиляции, с помощью следующего оператора. Просматривая кодовую базу (используя 'grep'), вы заметите, что большая часть этой логики находится в lib/Varien/Autoload.php файле.

Другое место, чтобы искать это Mage_Core_Controller_Varien_Action . В этом классе вы найдете preDispatch() метод, который запускается для каждого метода действия контроллера перед его отправкой. В этой части исходного загрузочного класса Magento вызывается класс Varien_Autoload для загрузки определенного файла области компиляции.

При работе в режиме компиляции Magento имеет только один путь включения, includes/src/ каталог, поэтому каждый файл находится непосредственно с первой попытки. Благодаря значительному количеству файлов, которые есть у Magento, это экономит довольно много времени. Нижний фрагмент взят из

Когда PHP включает файл, содержимое компилируется в код операции. Это процесс, который необходимо выполнять каждый раз, когда файл включен. Чтобы еще больше повысить производительность вашего магазина, вы можете установить APC на свой сервер. APC кэширует версии кодированных файлов, делая их доступными для последующих запросов. Итак, при следующем запросе: файл будет считан из кэша APC, вместо того, чтобы снова проходить тот же процесс и снижать производительность.

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

В сегодняшней статье мы рассмотрим рекомендации, которые основаны на лучших практиках при разработке на Magento. Эти рекомендации помогут как новичкам, так и более опытным разработчикам Magento 2.

Учитывайте стандарты кодирования

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

Следуя стандартным соглашениям, вы придаете своему коду профессиональный вид и облегчаете его чтение. Убедитесь, что ваши стандарты кодирования Magento основаны на стандартах кодирования Zend, PSR1, PSR2 и PSR4.

Советы при разработке модуля

Magento состоит из системного (core) кода и дополнительных компонентов, которые улучшают или заменяют основной код. Для Magento 2 доступно довольно большое количество готовых компонентов в виде модулей, тем и языковых пакетов. Архитектура Magento позволяет вносить улучшения, разрабатывать собственные компоненты.

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

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

Если вы не знаете, как что-то сделать, посмотрите на исходный код Magento. Этот код довольно часто является источником вдохновения.

Понимание фреймворка Magento 2

По сравнению с Magento 1 в новой платформе произошли значительные изменения. Обязательно изучите возможности и стандарты платформы Magento 2. Ниже приведены лишь некоторые из важных особенностей:

  • Вместо создания новых пользовательских валидаторов, реализуйте \Magento\Framework\Validator\ValidatorInterface .
  • Создание соединения с базой данных может быть затратным и ненужным. Magento предоставляет модели ресурсов для выполнения SQL команд (обратите внимание на Persistence Layer – Слой сохраняемости).
  • Подумайте об использовании соглашений фреймворка Magento вместо низкоуровневых или PHP-функций.
  • Используйте класс Magento\Framework\Data\Collection для получения коллекции отфильтрованных объектов вместо непосредственного запроса к базе данных.

И будьте осторожны при использовании сторонних модулей, прежде чем внедрять их в производстве, уделите некоторое время изучению их кода.

Всегда используйте git для создания версий своего кода, используйте локальную виртуальную машину для разработки (Vagrant или Docker могут быть хорошими инструментами).

Создавайте код, который можно использовать повторно

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

Код, который вы пишете, должен быть небольшим, целенаправленным и обеспечивать общее решение. Это позволит вам повторно использовать эту функциональность в будущем.

Избегайте создания вспомогательных (helper) классов

Вспомогательные или служебные классы – это классы, заполненные статическими методами, которые мало где применяются. Эти классы считаются анти-паттернами и противоречат принципам объектно-ориентированного программирования. Если у вас есть SomeClass и SomeClassHelper со статическими функциями, которые работают с SomeClass , вы должны рассмотреть возможность рефакторинга этих функций в SomeClass .

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

Советы по переопределению наблюдателя (observer)

Наблюдатели могут изменять поведение приложения Magento, поскольку они динамически внедряются в поток выполнения. Плохо спроектированные и закодированные наблюдатели могут вызывать проблемы, нестабильность или иным образом нарушать работу приложения.

Как сделать наблюдатель эффективным:

  • Старайтесь, чтобы ваш наблюдатель был маленьким и эффективным, избегая сложных вычислений, если это возможно. Это особенно важно, когда ваш наблюдатель слушает событие, которое часто отправляется. Сложные вычисления в вашем наблюдателе могут замедлить процессы приложения.
  • Не включайте бизнес-логику. Ваш наблюдатель не должен содержать логику, кроме той, которая необходима для его работы. Бизнес-логика должна быть заключена в другие классы, которые использует ваш наблюдатель.
  • Объявляйте наблюдателя в соответствующей области видимости. Сделайте своего наблюдателя настолько конкретным, насколько это необходимо. Это означает, что если ваш наблюдатель имеет дело только с внешними событиями, вы должны объявить своего наблюдателя в файле /etc/frontend/events.xml вместо глобального файла /etc/events.xml .
  • Избегайте замкнутых циклов событий. Циклические события происходят, когда ваш наблюдатель вызывает метод объекта, который отправляет событие, запускающее цепочку событий, что в конечном итоге отправляет то же начальное событие, которое выполняет ваш наблюдатель повторяющимся образом. Убедитесь, что ваш наблюдатель не отправляет событие, которое он немедленно слушает или будет слушать следующую цепочку событий.
  • Не полагайтесь на порядок вызова. Ваш наблюдатель не должен делать предположений относительно порядка, в котором он будет вызываться, и не должен полагаться на выполнение другого наблюдателя. Наблюдатели, слушающие одно и то же событие, могут вызываться в любом порядке, когда это событие отправляется.

Макет XML

В платформе произошли серьезные обновления в определении макетов, чтобы ограничить изменения, которые вы можете делать в файлах шаблонов (которые были возможны в предыдущей версии). Были добавлены новые теги container , referenceBlock , referenceContainer , move , update и argument .

Вот пример родительского и дочернего контейнеров:

Доступ к значениям аргументов, установленным в файле макета, можно получить в шаблонах с помощью методов get() и has() . Последний возвращает логическое значение, определяющее, есть ли какое-либо установленное значение. получается из атрибута name следующим образом: для получения значения имени метода используется getSomeString() .

Установка значения css_class в файле макета приложения /code/Magento/Theme/view/frontend/layout/default.xml :

Получение значения css_class в app/code/Magento/Theme/view/frontend/templates/html/title.phtml :

Рекомендуется не изменять базовые файлы дизайна, а вместо этого следовать стандартам кодирования и расширять или переопределять макет для любой модификации.

  • Расширить макет. Вместо того, чтобы копировать обширный макет страницы или код конфигурации страницы, а затем изменять то, что вы хотите изменить, в системе Magento вам нужно всего лишь создать расширенный файл макета, содержащий требуемые изменения. Например, чтобы настроить макет, определенный в /view/frontend/layout/catalog_product_view.xml , вам нужно добавить файл макета с тем же именем в свою пользовательскую тему, например: /Magento_Catalog/layout/catalog_product_view.xml
  • Переопределить макет. Не все настройки макета могут быть выполнены путем расширения существующих макетов. Если количество настроек велико, вы можете использовать функцию переопределения для нужного файла макета. Это означает, что новый файл, который вы помещаете в тему, будет использоваться вместо файла макета родительской темы файла базового макета.

Очищение кэша

Если вы забудете очистить или отключить кэширование, это может вызвать головную боль при разработке. Рекомендуется очищать кэш перед выполнением визуальной проверки вашей темы, чтобы убедиться, что отображаемое содержимое корректно.

Пока вы разрабатываете компоненты Magento (модули, темы и языковые пакеты), ваша быстро меняющаяся среда требует от вас периодически очищать определенные каталоги и кэши. В противном случае ваш код не будет работать должным образом.

Следуйте приведенным ниже инструкциям о том, когда и как очищать определенные каталоги кеша. Убедитесь, что вы находитесь в корневом каталоге вашей установки Magento.

Чтобы очистить только каталоги и не выполнять другие действия, войдите на сервер Magento как владелец файловой системы Magento и очистите каталоги с помощью команды, подобной следующей.

Для обновления базы данных и схемы всякий раз, когда происходят изменения в классе или изменения, приводящие к генерации фабрик, изменению в любом файле di.xml или добавлению/удалению любого модуля, запускайте следующую команду. Она очистит эти каталоги: var/di , var/generation .

После выполнения вышеуказанной команды необходимо сгенерировать скомпилированный код:

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

Чтобы отразить последние изменения на CMS странице, в кэшируемом блоке или изменить конфигурацию в админке, необходимо выполнить следующую команду:

В чем разница между «Flush Magento Cache» и «Flush Cache Storage» в управлении кэшем magento?

enter image description here

Иногда расположение кэша (например, /tmp/ ) или службы (например, Memcache) используется совместно с другими приложениями. «Flush Magento Cache» удаляет только те записи, которые Magento надежно отслеживает как свои собственные. «Flush Cache Storage» очищает все, но может повлиять на другие приложения, если они его используют.

Обычно это папка var/cache/ в папке Magento, поэтому она не является общей. Безопасно использовать любую кнопку. Иногда (редко) записи не имеют четкой пометки или Magento теряет их, и только вторая кнопка влияет на них. Я склонен использовать вторую кнопку, когда мне трудно отследить причину проблемы.

Flush Magento Cache

Удаляет все элементы в кэше Magento по умолчанию (var/cache) и кэше var/full_page, которые имеют тег Magento

Flush Cache Storage

Удаляет все элементы в кэше. Это эквивалентно удалению всего содержимого папки кэша на сервере. Если ваша система использует альтернативное расположение кэша, все кэшированные файлы, используемые другими приложениями, будут удалены.

Ниже вы найдете разницу между «Flush Magento Cache» и «Flush Cache Storage»:

Flush Cache Storage: эта функция в основном очищает весь кеш, все теги кеша. Это вызывает функцию «flush ()» в модели «ядро/кеш».

Flush Magento Cache: эта функция очищает теги кеша «MAGE» и «CONFIG». Этот класс выполняет функцию «clean ()» в модели «ядро/кэш».

Magento Cache: Удалить все элементы в кэше Magento по умолчанию (var/cache). Согласно связанному тегу Magento.

Flush Cache Storage: Удалить все элементы из кэша независимо от тега Magento. Если вы использовали другое местоположение, используемое другим приложением, будут удалены в этом процессе.

В качестве практического примера, если вы используете кеш magento для своих собственных устройств, например;

Вам нужно будет использовать очистить кэш-память , чтобы очистить это, если вы сделаете обновление.

В моем случае это для динамически генерируемого 3 уровня меню холста.

Необходимо очистить кэш-память, если вы измените столбцы таблицы (добавьте или удалите столбец), потому что magento выполняет запрос mysql DESCRIBE , а затем сохраняет результат в кэш-памяти. Этот кеш не очищается, если вы нажмете только кнопку «Flush Magento Cache».

Как правило, cache: clean удаляет весь включенный кеш, связанный с magento, тогда как cache: flush удаляет все хранилище кеша, будь то его кеш magento или любой сторонний кеш (включен или выключен)

Flush Magento Cache Используется для удаления кеша, сгенерированного по умолчанию magento var/cache и var/full_page .

Flush Cache Storage Используется для удаления всех типов кеша. Кэш, сгенерированный по умолчанию magento или внешним кешем, созданным другими внешними провайдерами.

Вот ответ на ваш запрос:

Flush Magento Cache При выполнении этого действия содержимое, имеющее тег Magento в var/cache и var/full_page_cache, удаляется.

Я использую Magento ver1.6.1. Мне нужно программно очистить кеш Magento.

Я использовал приведенный выше код, но он не очистил кеш.


4 ответы

Это то, что вам нужно:

Вот как вы сделаете это автоматически:

Если вы используете Magento Enterprise (я использую 1.13), приведенного выше кода в вышеупомянутых ответах кажется недостаточно для очистки полного кеша страницы.

Мне потребовалось некоторое время, чтобы понять, что происходит, но есть несколько методов, которые срабатывают в результате событий при использовании веб-интерфейса, которые не будут охвачены при использовании приведенного выше кода. Решающее значение имеет cleanCache метод Enterprise_PageCache_Model_Observer .

Надеюсь, это кому-то сэкономит время!

ответ дан 20 авг.

Чтобы решить вашу проблему, вы можете написать сценарий bash, который очищает кеш и данные сеанса.

Magento Cache Syrup - простой сценарий bash для очистки кеша Magento, сеанса, отчетов и временных данных с помощью системного администратора, чтобы убедиться, что ваш сайт Magento работает лучше.

Этот скрипт очищает кеш и данные сеанса от установки Magento на сервере Linux (ubuntu), чтобы убедиться, что он устраняет ошибку Magento пустой белой страницы, вызванную кешем и данными сеанса, и обеспечивает более быструю работу вашего веб-сайта Magento. Войдите на свой сервер как root и создайте файл с именем magento_cache_syrup.sh и вставьте следующий код.

Убедитесь, что вы изменили путь в приведенном выше коде и указали его на свою установку magento. Для абсолютных новичков просто замените «/ var / www / sl60» на путь к каталогу вашего веб-сайта Magento.

После исправления пути вы можете просто запустить указанный выше сценарий, вызвав его из терминала.

Это должно очистить все данные в каталогах cache, session, tmp и reports в вашей установке Magento. Но на этом проблема не заканчивается. Нам нужно убедиться, что мы делаем это каждый раз, прежде чем дойдем до пустой белой страницы. Чтобы решить эту проблему, мы включим задание cron на сервере, которое запускает сценарий bash (magento-cache-syrup) каждые 12 часов.

Читайте также: