Modx проблемы с кэшем
Все привет
Клиент из админки наклонировал несколько сотен тысяч ненужных ресурсов
Теперь, возможно, из за этого, когда мы меняем содержимое ресурса или шаблона на сайте - отображается его старая версия, без изменений
Подозреваем что это из за кэша
Вручную из админки обновить кэш не получается, при выборе в меню САЙТ - ОБНОВИТЬ САЙТ консоль зависает
Как это можно сделать скриптом или еще каким-либо способом?
Если скриптом с какой-то функцией модикс - то как он должен выглядеть полностью, с подключенными библиотеками и где он должен размещаться при вызове? Доступа к shell на этом хостинге нет.
Жду ответа, спасибо
Теперь, возможно, из за этого, когда мы меняем содержимое ресурса или шаблона на сайте - отображается его старая версия, без изменений
Посмотрите в настройках, у вас manager_html5_cache включен или выключен? Подобную проблему я видел, когда он включен. Выключаем, значит.
А чтобы общий кэш очистить, достаточно удалить всё из папки core/cache/ через FTP (или SSH).
Спасибо за совет, мы им воспользовались и у нас исчезли все ресурсы, и сайт не работает.
Что может быть и куда смотреть?
Вы удалили core/cache/*, да? Т.е. папка core/cache еще есть, но она пуста.
Значит, проблема была не в кэше.
Дальше надо проверить связь с БД. Откройте core/config/config.inc.php и посмотрите строки 5–12. Попробуйте вручную связаться с БД (с помощью phpMyAdmin например). Сервер, логин, все работает?
А насчет "сайт не работает", можно больше подробностей? Какая ошибка выводится вообще, или на что ругается?
Мы удалили core/cache и сайт после этого перестал работать, а именно при заходе на него выдавать ошибку 500,
при этом админка сайта открывается ну после удаления кэша вкладка ресурсы пустая.
Всё это произошло после очистки папки core/cache.
Сервер базы данных работает без изменений, так как остальные сайты открываются.
Буду благодарен за совет .
Скорее всего наличие кэшированных ресурсов по большей мере маскировало другие, уже существующие проблемы. Ведь что-то было не так и до очистки кэша.
PHP вообще имеет право создавать файлы в core/cache? Если он работает в виде модуля Apache, то скорее всего нужны права 0777. Если fcgi (лучше) то 0755.
А что у вас в логе PHP ошибок?
после очистки папки кэша - исчезнуть ваши ресурсы никак не могли. Присоединяюсь к мнению выше , скорее всего проблема с подключением к БД или с доступами. Судя по постам , я бы порекомендовал обратиться к специалисту , чтобы не нарубить дров.
В лог файле образуются следующие ошибки:
собственно это причина по которой сайт не открывается.
А у вас какая версия MODX? Если 2.2.7 или 2.2.8, то попробуйте отключить настройку cache_alias_map. Если админка более менее работает, то найдете ее в Настройках системы в разделе Core / Кэширование. Значение также можно менять непосредственно в БД если что.
Поскольку у вас несколько сотен тысяч ресурсов, то MODX требует значительно больше памяти чем 64МБ, чтобы сгенерировать этот cache alias map. Выключите его, и требование к памяти снизится на порядок.
А если у вас более старая версия, то либо обновить, либо залезть в БД и поудалить тех несчастных наклонированных ресурсов.
у нас предыдущая версия 2.2.6
хочется удалить, но есть такая проблема - я так понимаю, весь мусор у меня содержится в таблицах modx_site_content (367,812 записей) и modx_site_tmplvar_contentvalues (1,093,939 записей), связанных друг с другом через id контента.
Я решил удалить из базы весь контент (таблица modx_site_content), помеченный как удаленный и TV из второй таблицы (modx_site_tmplvar_contentvalues), привязанные к нему, правильно?
сделал тестовый запрос, который показал, что удаленный контент составляет всего 20 тыс записей из 267 тыс (поле deleted = 1)
тут какой-то подвох, потому что полезных ресурсов на сайте должно быть около тысячи, не больше, остальные должны быть мусором
каким образом вычислить остальные? я думаю насчет поля parent, то есть теоретически если ресурс не помечен как удаленный (deleted = 0), но имеет удаленного родителя (parent) или прародителя, то его тоже не видно, но он сжирает ресурс при генерации кэша, так?
каким алгоритмом, sql запросом или скриптом мне аккуратно почистить контент, учитывая эту путаницу?
In the time it takes to read this, you could start a new site with nothing to download or install.
Don't Be That Guy
Be nice, respectful and patient. Inflammatory or inappropriate posts will get your post nuked and flood your life with bans and bad karma.
Thank the People that Help
Remember, this is an Open Source project and the volunteers here assist out of love for the project and a desire to help others.
Ставим на нашу обычную Ubuntu:
Активируем в настройках MODX:
Опции cache_prefix нет, по умолчанию, ее нужно создать. Это опция контекста, и если у вас на сайте их более одного — нужно писать в настройки контекстов. Также это необходимо, если вы хостите более одного сайта, пускай и с одним контекстом у каждого.
Иначе, все данные будут кэшироваться без уникального префикса, и на одном сайте вылезет кэш от другого. Будет не круто, уверяю.
Использование
Вот тут самое сладкое — ничего. делать не нужно. Вы указали класс-обработчик для кэша, префикс для ключей и дальше MODX работает за нас, как обычно.
Мы можем использовать специальные директивы глобально в apc.ini. Обратите особое внимание на apc.shm_size — это объем памяти для apc.
Некоторые параметры, типа apc.cache_by_default, можно использовать в конфиге определенного сайта php5-fpm.
Еще в комплекте идет полезный скрипт — он находится в /usr/share/doc/php-apc/apc.php.gz. Можете скопировать его в секретную директорию на сайте и разглядывать статистику. Если в файле задать пароль для авторизованного юзера, то можно видеть более подробную информацию и чистить кэш.
Результаты
Сразу после установки php-apc все php скрипты начинают работать быстрее. Но лично я столкнулся с разными глюками при работе с сессией в miniShop — она кэшировались. Поэтому долгое время не пользовался этим прекрасным кэшером, во избежание.
Разгадка крылась в том, что я не включал нужный обработчик, а пользовался стандартным на файлах (xPDOFileCache). Отсюда был глюк — от моей невнимательности.
Помимо прочего, ваши сайты будут кушать меньше оперативки, быстрее отзываться и держать гораздо большую нагрузку.
Советую прочитать вот эту заметку, учитывая, что там есть неточность — данные хранятся не в файлах, а в памяти. Там очень хорошо описан сам принцип opcode-кэшеров.
Кэшируя повторно используемые данные, можно предотвратить множество запросов к базе данных, что приведет к повышению производительности. MODX Revolution предлагает ряд различных функций кэширования на разных уровнях в приложении. Кэширование в MODX в основном обрабатывается базовым классом modCacheManager , который расширяет класс xPDOCacheManager и позволяет использовать обработчики кэша, зависящие от раздела. Реализация по умолчанию записывает кэши в файлы в папке core/cache/ .
Если вы определили пользовательский ключ MODX_CONFIG_KEY , менеджер кэша выполнит запись в core/cache/MODX_CONFIG_KEY/
Обновление кэша MODX Core¶
Чтобы обновить любой из основных разделов кэша MODX, используйте метод modCacheManager->refresh() . Минимальный вызов не имеет параметров и обновит все разделы основного кэша.
Кроме того, вы можете определить массив $providers с разделом элементов key => $partitionOptions .
Второй параметр $results передается по ссылке и будет содержать результаты каждого раздела кэша. В зависимости от раздела это может быть логическое значение или массив с дополнительной информацией о результате обновления определенного раздела. Сама функция возвращает логическое значение, указывающее, вернул ли какой-либо из разделов логическое значение false .
Основные разделы кэша и их краткое описание
MODX Revolution имеет следующие разделы (справочная информация):
action_map Содержит массив всех идентификаторов контроллеров и пространств имён, доступных в менеджере. auto_publish Содержит штамп времени, который определяет момент, при наступлении которого необходимо будет автоматически опубликовать ресурс или снять его с публикации. context_settings Этот раздел используется для хранения настроек контекстов. Каждый контекст в этом разделе имеет свой файл, в котором содержится карта ресурсов (идентификаторы родителей и детей), карта псевдонимов, плагины, используемые в контексте и политика доступа. db Раздел кэша db предназначен для хранения результирующих наборов, запрошенных из базы данных с помощью методов getObject , getCollection и т.п. Этот кэш используется при включении параметра cache_db в настройках системы или тогда, когда данный параметр активирован в настройках контекста.
Этот кэш обычно применяется тогда, когда доступ к базе является более затратным действием, чем использование процессорного времени. includes Данный раздел используется как временное хранилище для исходных кодов php файлов (сниппетов и плагинов). Используется ядром MODX во время их выполнения. Файлы в этом кэше имеют формат: 23.include.cache.php (23 - это id сниппета или плагина). logs Данный раздел используется в качестве хранилища log файлов системы. menu Этот раздел содержит кэш меню менеджера (админки). mgr Данный раздел использует Smarty в качестве своего хранилища для записи в него временных файлов. resource Содержит кэш ресурсов, организованный с учётом контекста и id (файлы в этом кэше имеют формат 7.cache.php (7 - это id ресурса)). Каждый файл содержится метаданные ресурса, его кэшированное представление с не кэшированными тегами (_content), политику доступа для ресурса и элементов, а также их исходные коды (используются в процессе обработки ресурса). rss Данный раздел использует MagpieRSS в качестве каталога для записи своих временных файлов. scripts Содержит исходные коды сниппетов и плагинов, которые впоследствии будут записаны в кэш директорию includes . setup Используется системой MODX при установке. system_settings Содержит настройки системы MODX. Этот раздел загружается первым. Для его обработки нельзя назначить альтернативный кэшер (т.е. всегда используется только xPDOFileCache ).
Чтобы изменить провайдер кэша для определенного раздела кэша, просто создайте новый системный (или контекстный) параметр с именем cache_PARTITION_handler (например, cache_resource_handler - для раздела resource ) и присвойте ему значение обработчика кэша, который вы хотите использовать для его обработки (например, xPDOMemCache ).
Настройка кэширования в MODX Revo
В MODX Revolution управление кэшированием может осуществляться посредством:
- изменения значений системных настроек (область действия - весь сайт);
- кэшированного или не кэшированного (с восклицательным знаком) вызова чанков, сниппетов и плейсхолдеров (область действия - указанный элемент);
- установки или снятия флажка в поле ресурса "Кэшируемый" (область действия - указанный ресурс);
- методов modCacheManager (программное управление кэшированием).
Пример 1: Простое добавление и получение кэша¶
Кэширование базы данных¶
Если вы включите системный параметр cache_db, MODX может автоматически кэшировать наборы результатов базы данных, извлеченные любым экземпляром xPDOCriteria или xPDOQuery . Это включает в себя все наборы результатов, представляющие xPDOObjects или коллекции xPDOObjects , возвращаемые такими методами, как getObject и getCollection .
Эта функция может быть включена в средах, где доступ к базе данных обходится дороже, чем время подключения файлов PHP, например, при использовании внешнего сервера базы данных, или настраивается для сред с доступным memcached , APC или другими системами кэширования. Это отдельный раздел кеша в MODX, поэтому его можно настроить с другими обработчиками кэша. Смотрите xPDO Caching для дополнительной информации.
Как кэширование организовано в MODX Revo
По умолчанию кэш в CMS MODX Revolution находится в файлах и расположен в директории core/cache/ .
Для обработки кэша в MODX используется провайдеры (по умолчанию: xPDOFileCache ). Файлы кэша в данном каталоге находится не в корне, они распределены по разделам.
Раздел - это кэш с данными определённого вида (например, ресурсами). Раздел можно представить как директорию в каталоге core/cache/ .
Разделы созданы не только для удобного представления различных данных кэша, но и для того, чтобы ими можно было управлять посредством различных провайдеров.
Например, одним разделам кэша можно назначить провайдер xPDOFileCache , а другим xPDOMemCache .
В MODX Revolution доступны следующие провайдеры: xPDOFileCache (по умолчанию), xPDOAPCCache (для Alternative PHP Cache), xPDOMemCache (для memcache), xPDOMemCached (для memcached), xPDOWinCache (для WinCache).
Поддержка того или иного кэшера (за исключением файлового xPDOFileCache ) зависит от хостинга и в основном предоставляется только тем, кто арендует виртуальный выделенный сервер.
Кэш менеджеры ( xPDOFileCache , xPDOAPCCache , xPDOMemCache , xPDOMemCached и xPDOWinCache ) являются производными от класса xPDOCache и предоставляют единую API для записи, чтения и удаления кэш записей.
Разделы основного кэша MODX¶
В ядре несколько разделов. Их можно легко определить, просмотрев папку core/cache/ с конфигурацией кэша по умолчанию.
Обычно вам не нужно работать с кэшированными данными напрямую (вместо этого используйте доступные API), но для понимания ядра MODX здесь мы рассмотрим основные разделы и кратко опишем их назначение и содержание.
Как мы обсудим позже, пользовательские провайдеры также могут быть использованы в разработке.
- action_map содержит большой массив всех действий (идентификаторов, ссылающихся на контроллеры и пространства имен), которые могут быть доступны в менеджере. Поскольку действия устарели и больше не используются в 2.3, никогда не полагайтесь на них.
- auto_publish содержит метку времени Unix, которая определяет, когда ресурс должен быть автоматически опубликован или распубликован (см. ModCacheManager.autoPublish() )
- context_settings для каждого контекста на сайте содержит карту ресурсов (идентификаторы родительских и дочерних документов), карту псевдонимов, используемые в контексте плагины и политики доступа.
- db раздел кэша базы данных используется, когда включена системная или контекстная настройка cache_db , и содержит необработанные наборы результатов для запросов xPDO getObject / getCollection . Подробнее об этом ниже.
- includes - на самом деле, это не раздел кэша, но он содержит файлы PHP, где сниппеты и плагины заключены в вызовы функций для легкого выполнения ядром. Смотрите сценарии для раздела кэша для сниппетов и плагинов.
- logs - это также не раздел кэша, но содержит файл error.log и иногда другие файлы журнала (например, журнал установки).
- menu cодержит для каждого языка менеджера многомерный массив верхнего меню менеджера.
- mgr не является настоящим разделом кэша, но используется Smarty и Google Minify в 2.2 для записи файлов кэша.
- registry - это директория по умолчанию для modRegistry, в которую записываются журналы регистрации файлов. Не является настоящим разделом кэша.
- resource содержит организованный по контексту и идентификатору ресурса механизм частичного кэширования ресурсов. Эти файлы кэша содержат метаданные для ресурса, кэшированное представление ресурса (_content) с оставшимися без кэширования тегами, политиками доступа к ресурсу и элементами и их источниками, используемые при обработке ресурса.
- rss не является настоящим разделом кэша, но используется MagpieRSS (виджеты RSS панели) для записи в кеш.
- scripts содержит источник сниппетов и плагинов, которые впоследствии записываются в папку кэша includes.
- setup не является настоящим разделом кэша, но используется инсталлятором MODX для кэширования шаблонов Smarty.
- system_settings содержит глобальную конфигурацию MODX и системные настройки. Этот раздел загружается первым по запросам в MODX. Поскольку альтернативные обработчики кэша для разделов хранятся в системных настройках, этот раздел не может быть загружен из другого обработчика кэша таким образом.
Чтобы изменить обработчик кэша для определенного раздела кэша, просто создайте новый системный (или контекстный) параметр с именем cache_PARTITION_handler (например, cache_resource_handler или cache_scripts_handler ) и присвойте ему значение обработчика кэша, который вы хотели бы использовать. По умолчанию используется xPDOFileCache , однако и другие обработчики доступны для APC , memcache (d) и wincache .
Обратите внимание, что в MODX 2.0.x система кэша довольно сильно отличалась. Доступные разделы были иными, а системные настройки сохранялись в core/cache/config.cache.php . Если вы все еще используете MODX 2.0.x, вам следует потратить больше времени на обновление и меньше времени на чтение этого документа.
Управление кэшированием элементов
Система MODX позволяет управлять кэшированием чанков, сниппетов и плейсхолдеров. Осуществляется это посредством флага (восклицательного знака) в конструкции вызова этого элемента.
Данный флаг является не обязательным. Если его не указывать, то вызов элемента будет кэшированным. Это означает, что при вызове элемента, система MODX будет проверять есть ли результат его работы в кэше. Если он есть, то система MODX просто возьмёт его оттуда. Если же его нет, то этот элемент будет запущен на выполнение. После завершения выполнения система MODX сохранит результат его работы в кэш (для использования в следующих вызовах).
При указании в конструкции вызова элемента восклицательного знака перед именем элемента, он кэшироваться не будет. Это означает то, что данный элемент будет при каждом вызове запускаться на выполнение.
Общая терминология кэширования и поведение¶
MODX использует разные разделы для отдельных типов кэшируемых данных. Упрощенно, раздел - это папка в директории core/cache/ , но настоящая ценность разделов в том, что каждому разделу могут быть назначены разные обработчики кэша. Обработчики кэша являются производными от класса xPDOCache и предоставляют единый API для хранения, чтения и удаления записей кэша.
Обработчик кэша по умолчанию xPDOFileCache записывает кэш в файловую систему в папке core/cache/ , но в ядре доступны также другие обработчики кэша для APC ( xPDOAPCCache ), memcache(d) ( xPDOMemCache , xPDOMemCached ) и WinCache ( xPDOWinCache ).
Пример 2. Добавление и получение кэша из пользовательского раздела¶
Управление кэшированием посредством изменения системных настроек
Общие настройки кэширования, влияющие на весь сайт, устанавливаются в системных настройках. Для этого необходимо нажать в админке MODX (в главном меню) на значок шестерёнки -> выбрать пункт "Системные настройки" -> раздел "Core" -> подраздел "Кэширование".
Название ключей и их назначение:
cache_action_map (по умолчанию: да) Включает кэширование карты контроллеров (для ускорения загрузки страниц панели управления). cache_alias_map (по умолчанию: да) Включает кэширование карты ресурсов (добавление URI ресурсов в кэш контекста). Эту опцию рекомендуется устанавливать в положение "Да" только для небольших сайтов. А для сайтов с огромных количеством ресурсов её отключать. cache_context_settings (по умолчанию: да) Включает кэширование настроек контекстов для более быстрой загрузки страниц. cache_db (по умолчанию: нет) При включении, объекты и необработанные результаты наборов, запрашиваемые посредством SQL запросов будут кэшироваться (используется для уменьшения нагрузки на базу данных). Для хранения этого кэша может потребоваться достаточно большой объём дискового пространства. cache_db_expires (по умолчанию: 0) Время (в секундах) для хранения кэша db. Если установить значение, равное 0, то время жизни кэша будет не ограниченным. cache_db_session (по умолчанию: нет) При включении данной опции и cache_db, сессии, хранящиеся в базе данных, тоже будут кэшироваться. cache_db_session_lifetime (по умолчанию: нет) Время (в секундах), которое определяет период жизни кэша сессий. cache_default (по умолчанию: да) Устанавливает, необходимо ли при создании ресурса, делать его кэшируемым (устанавливать флажок cacheable в положение "Да"). cache_disabled (по умолчанию: нет) Если установить данному параметру значение "Да", то он отключить весь механизм кэширования MODX Revolution (не рекомендуется). cache_expires (по умолчанию: 0) Это значение (в секундах) устанавливает время жизни кэша MODX. Значение 0 задаёт неограниченное время его жизни. cache_format (по умолчанию: 0) Формат хранения кэша. 0 - в формате массива PHP, 1 - в JSON, 2 - в сериализованном виде. cache_handler (по умолчанию: xPDOFileCache) Имя провайдера, используемого по умолчанию для обработки всех разделов кэша. cache_lang_js (по умолчанию: да) При включении данной опции будут использоваться серверные заголовки для кэширования строк лексикона загружаемые в JavaScript и используемые интерфейсом менеджера. cache_lexicon_topics (по умолчанию: да) Когда включено, все темы словарей будут кэшироваться. Это позволит значительно снизить нагрузку при интернациональном использовании системы. MODX рекомендует оставлять эту опцию включенной, иначе работа менеджера может быть сильно замедлена. cache_noncore_lexicon_topics (по умолчанию: да) При отключении данной опции темы словарей дополнений (не принадлежащих ядру) кэшироваться не будут. Эта опция может быть очень полезна при разработке дополнений. cache_resource (по умолчанию: Да) Включает частичное кэширование ресурсов. Будут задействованы только те ресурсы, у которых параметр "Кэшируемый" установлен. Выключение данной опции отключит кэширование всех ресурсов. cache_resource_expires (по умолчанию: 0) Устанавливает период жизни кэша ресурсов (в секундах). Значение 0 позволяет хранить кэш ресурсов неограниченное время. cache_scripts (по умолчанию: да) Если включено, то MODX будет кэшировать все скрипты (сниппеты и плагины) в кэш (файлы) для увеличения скорости их загрузки. MODX рекомендует оставить эту настройку включённой. cache_system_settings (по умолчанию: Да) Если выбрано "Да", то настройки системы будут кэшироваться, тем самым уменьшая время загрузки страниц. MODX рекомендует оставить эту настройку включённой, т.е. в положение "Да". clear_cache_refresh_trees (по умолчанию: Нет) Если включено, то после обновления кэша сайта активные древовидные меню менеджера будут автоматически обновляться. syncsite_default (по умолчанию: Да) Если параметр имеет значение "Да", то сохранение ресурса будет приводить к автоматической очистке кэша.
Программное (пользовательское) кэширование¶
Взаимодействуя с modCacheManager , вы можете легко кэшировать данные любого типа. Есть несколько полезных функций, которые вы можете использовать для поддержания рабочего кэша. Используя modCacheManager с пользовательским разделом (хотя и необязательно), пользователи вашего кода могут изменить обработчик кэша и сохранить данные в экземпляре memcached , APC или WinCache вместо файлового кэша по умолчанию.
ModCacheManager (производный от xPDOCacheManager ) предоставляет следующие полезные методы:
- add($key, $var, $life = 0, $options = array()) используется для добавления значения в кэш, но только если оно еще не существует или срок его действия истек.
- replace($key, $var, $life = 0, $options = array()) используется для замены существующего кэшированного значения другим.
- set($key, $var, $life = 0, $options = array()) используется для установки значения в кэш независимо от того, существует ли оно уже (перезаписывается) или нет (добавляется).
- delete($key, $options = array()) удаляет кэшированное значение из кэша.
- get($key, $options = array()) получает кэшированное значение из кэша.
- clean($options = array()) очищает (удаляет) весь поставщик кэша. Убедитесь, что вы определили xPDO::OPT_CACHE_KEY в массиве параметров.
В общем случае вы можете использовать get($key) и set($key, $value) для получения и установки значений соответственно, но дополнительные методы обеспечивают дополнительный контроль над способом управления данными.
Массив $options может содержать следующие параметры, указывающие раздел кэша для записи, используемый обработчик кэша и время истечения по умолчанию.
- xPDO::OPT_CACHE_KEY - раздел кэша для записи.
- xPDO::OPT_CACHE_HANDLER - используемый обработчик кэша. Как правило, вам не нужно жестко определять этот параметр, но имеет смысл разрешать конкретной реализации обрабатывать обработчик кэша с помощью системных настроек (то есть системных настроек cache_PARTITION_handler ).
- xPDO::OPT_CACHE_EXPIRES - время истечения по умолчанию.
Настройка кэширования ресурсов
В MODX управление кэшированием ресурсов осуществляется:
- посредством изменения системных настроек cache_resource , cache_resource_expires и cache_default (глобальные настройки, влияющие на все ресурсы);
- с помощью флажка "Кэшируемый" (включает или отключает кэш отдельно взятого ресурса).
Кэш ресурсов в MODX расположен в директории /core/cache/resource/ . Он построен с учётом контекста, к которому принадлежит ресурс. Имена файлов в этом кэше имеют следующий формат:
Цифра в начале имени - это значение id ресурса.
Обратите внимание в Revolution 2.0¶
В MODX Revolution 2.0 была другая система кеширования с отличающимися разделами. Чтобы очистить кеш в 2.0, вы должны использовать метод clearCache() , который устарел с 2.1. Лучше обновиться до последней версии, чем продолжать использовать 2.0.
Разработано, построено и написано со всей любовью в мире от сообщества MODX.
Все привет
Клиент из админки наклонировал несколько сотен тысяч ненужных ресурсов
Теперь, возможно, из за этого, когда мы меняем содержимое ресурса или шаблона на сайте - отображается его старая версия, без изменений
Подозреваем что это из за кэша
Вручную из админки обновить кэш не получается, при выборе в меню САЙТ - ОБНОВИТЬ САЙТ консоль зависает
Как это можно сделать скриптом или еще каким-либо способом?
Если скриптом с какой-то функцией модикс - то как он должен выглядеть полностью, с подключенными библиотеками и где он должен размещаться при вызове? Доступа к shell на этом хостинге нет.
Жду ответа, спасибо
Теперь, возможно, из за этого, когда мы меняем содержимое ресурса или шаблона на сайте - отображается его старая версия, без изменений
Посмотрите в настройках, у вас manager_html5_cache включен или выключен? Подобную проблему я видел, когда он включен. Выключаем, значит.
А чтобы общий кэш очистить, достаточно удалить всё из папки core/cache/ через FTP (или SSH).
Спасибо за совет, мы им воспользовались и у нас исчезли все ресурсы, и сайт не работает.
Что может быть и куда смотреть?
Вы удалили core/cache/*, да? Т.е. папка core/cache еще есть, но она пуста.
Значит, проблема была не в кэше.
Дальше надо проверить связь с БД. Откройте core/config/config.inc.php и посмотрите строки 5–12. Попробуйте вручную связаться с БД (с помощью phpMyAdmin например). Сервер, логин, все работает?
А насчет "сайт не работает", можно больше подробностей? Какая ошибка выводится вообще, или на что ругается?
Мы удалили core/cache и сайт после этого перестал работать, а именно при заходе на него выдавать ошибку 500,
при этом админка сайта открывается ну после удаления кэша вкладка ресурсы пустая.
Всё это произошло после очистки папки core/cache.
Сервер базы данных работает без изменений, так как остальные сайты открываются.
Буду благодарен за совет .
Скорее всего наличие кэшированных ресурсов по большей мере маскировало другие, уже существующие проблемы. Ведь что-то было не так и до очистки кэша.
PHP вообще имеет право создавать файлы в core/cache? Если он работает в виде модуля Apache, то скорее всего нужны права 0777. Если fcgi (лучше) то 0755.
А что у вас в логе PHP ошибок?
после очистки папки кэша - исчезнуть ваши ресурсы никак не могли. Присоединяюсь к мнению выше , скорее всего проблема с подключением к БД или с доступами. Судя по постам , я бы порекомендовал обратиться к специалисту , чтобы не нарубить дров.
В лог файле образуются следующие ошибки:
собственно это причина по которой сайт не открывается.
А у вас какая версия MODX? Если 2.2.7 или 2.2.8, то попробуйте отключить настройку cache_alias_map. Если админка более менее работает, то найдете ее в Настройках системы в разделе Core / Кэширование. Значение также можно менять непосредственно в БД если что.
Поскольку у вас несколько сотен тысяч ресурсов, то MODX требует значительно больше памяти чем 64МБ, чтобы сгенерировать этот cache alias map. Выключите его, и требование к памяти снизится на порядок.
А если у вас более старая версия, то либо обновить, либо залезть в БД и поудалить тех несчастных наклонированных ресурсов.
у нас предыдущая версия 2.2.6
хочется удалить, но есть такая проблема - я так понимаю, весь мусор у меня содержится в таблицах modx_site_content (367,812 записей) и modx_site_tmplvar_contentvalues (1,093,939 записей), связанных друг с другом через id контента.
Я решил удалить из базы весь контент (таблица modx_site_content), помеченный как удаленный и TV из второй таблицы (modx_site_tmplvar_contentvalues), привязанные к нему, правильно?
сделал тестовый запрос, который показал, что удаленный контент составляет всего 20 тыс записей из 267 тыс (поле deleted = 1)
тут какой-то подвох, потому что полезных ресурсов на сайте должно быть около тысячи, не больше, остальные должны быть мусором
каким образом вычислить остальные? я думаю насчет поля parent, то есть теоретически если ресурс не помечен как удаленный (deleted = 0), но имеет удаленного родителя (parent) или прародителя, то его тоже не видно, но он сжирает ресурс при генерации кэша, так?
каким алгоритмом, sql запросом или скриптом мне аккуратно почистить контент, учитывая эту путаницу?
In the time it takes to read this, you could start a new site with nothing to download or install.
Don't Be That Guy
Be nice, respectful and patient. Inflammatory or inappropriate posts will get your post nuked and flood your life with bans and bad karma.
Thank the People that Help
Remember, this is an Open Source project and the volunteers here assist out of love for the project and a desire to help others.
Кэширование - это механизм в CMS MODX Revolution и не только, который позволяет сохранить некоторый результат в определённое место (кэш) для того чтобы в будущем (при следующих запросах) его можно было использовать.
В работе сайта кэширование играет значительную роль. Ведь правильно настроенное кэширование позволяет не только более быстро отдавать страницы пользователям, но и значительно сократить нагрузку на процессор и сервер базы данных.
Рассмотрим пример. Допустим у вас на всех страницах сайта в сайдбаре есть блок "Последние статьи". Для того чтобы его вывести на страницу вам необходимо подготовить запрос, получить данные из базы и обработать их. Вся эта операция не происходит мгновенно, на её выполнение требуется время. А если у вас в сутки запрашивается не одна, а сотни или тысячи страниц. То, представьте, сколько раз заново приходится строить один и тот же блок, т.е. при каждом запросе страницы, на которой он есть. Правильно конечно было бы создать блок "Последние статьи" только один раз (при первом вызове) и сохранить его кэш. А затем (при следующих запросах) просто использовать его. Тем самым можно не только увеличить быстродействие (загрузку) страниц, но и значительно уменьшить нагрузку на процессор и сервер баз данных. Последнее действие, которое ещё останется осуществить - это определить момент обновления кэша этого блока. В данном случае в момент выхода (публикации) новой статьи.
Программное управление кэшированием
В MODX работа с кэшем осуществляется посредством modCacheManager , который является расширением класса xPDOCacheManager .
modCacheManager предоставляет следующие методы для работы с кэшем:
- add($key, $var, $lifetime = 0, $options = array()) - необходим для добавления значения в кэш (но только если это значение не существует или срок его хранения вышел);
- replace($key, $var, $lifetime = 0, $options = array()) - используется для замены одного (существующего) кэшированного значения на другое;
- set($key, $var, $lifetime = 0, $options = array()) - используется для установки значения в кэш не зависимого от того есть ли оно в кэше или нет;
- delete ($key, $options = array()) - удаляет кэшированное значение из кэша;
- get ($key, $options = array()) - применяется для получения кэшированное значение из кэша;
- refresh ($key, $options = array()) - предназначен для удаление всех разделов кэша или какого-то конкретного.
Массив $options может содержать следующие ключи:
- xPDO::OPT_CACHE_KEY - указывает раздел кэша;
- xPDO::OPT_CACHE_HANDLER - задаёт провайдер кэша (как правило, данный ключ нет смысла указывать, для назначения провайдера для раздела кэша используйте системные настройки (параметр cache_PARTITION_handler ));
- xPDO::OPT_CACHE_EXPIRES - устанавливает длительность хранения кэша в секундах.
Примеры использования методов modCacheManager :
Удаление всего кэша MODX:
Удаление кэша контекстов web и en из раздела context_settings :
Получить значение кэша по ключу comments_17 из раздела comments :
Сохранить в кэш comments_17 , расположенный в разделе comments , значение переменной $output (время хранения данных в кэше не ограниченное):
Удалить из раздела main_menu кэш menu_11 :
Пример, как можно организовать программное кэширования главного двухуровневого меню на сайте, выполненного с помощью компонента navbar Bootstrap 3.
В примере используется выборочное кэширование, т.е. кэш создаётся только для тех ресурсов сайта, которые присутствуют в меню. Для остальных ресурсов кэш будет подбираться в зависимости от того к какому разделу каждый из них относится.
Чанк tpl.mainMenuOuter (внешняя обёртка главного меню):
Вызов сниппета MainMenu в шаблоне:
После этого в разделе main_menu будет находиться кэши главных меню ресурсов.
Читайте также: