Стандартное расположение плагина для сохранения/кэширования файлов?


Существуют ли официальные рекомендации о том, где плагин должен кэшировать файлы?

Если нет, то есть ли лучшая практика, которой я могу следовать?

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

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

Мой инстинкт подсказывает положить их в подкаталог wp-content/uploads.

Моим вторичным инстинктом было бы хранить файлы в дереве каталогов плагина. Это позволяет сгруппировать данные плагина вместе, но не соответствует (как представляется) архитектуре WordPress, в которой находится пользовательский контент /uploads.

Author: Matthew Bakaitis, 2014-12-29

3 answers

Было бы неплохо, если бы в WordPress был каталог кэша на основе стандартов, но, поскольку это не так, я думаю, что лучший вариант - сохранить его в самой папке плагина.

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

tl;dr: Файлы кэша являются частью функциональности определенного плагин и должен быть упакован вместе с ним.

 7
Author: Wyck, 2014-12-29 16:50:33

Если вам не нужно хранить очень большие данные, вам следует взглянуть на временный API Wordpress:

Http://codex.wordpress.org/Transients_API

Ваши данные будут обрабатываться Wordpress с истекшим сроком действия. Я думаю, что это более "wordpress-способ" кэширования данных.

 1
Author: Andrea, 2015-08-23 15:03:27

Сидит с той же "проблемой". Сначала я думал о том, чтобы сохранить этот кэш в качестве опции, но мой кэш просто был слишком большим, поэтому это не сработало. Так что, возможно, это альтернатива, если ваш кэш никогда не будет действительно большим. Например, если вы общаетесь с API и можете выполнять только несколько запросов в час, а ответный ответ не слишком длинный. :)

 0
Author: gubbfett, 2015-04-20 07:19:29