ZF: Désactiver le plugin de ressources dans application.ini

Question

Comment puis-je désactiver le cache dans l'environnement cli?

Raison d'être, l'utilisateur du système qui exécute le script n'est pas autorisé à écrire dans le répertoire de cache, ainsi le script est incapable d'exécuter.

Dans mon application.ini je

[production] 

resources.cachemanager.database.frontend.name = Core 
resources.cachemanager.database.frontend.customFrontendNaming = false 
resources.cachemanager.database.frontend.options.lifetime = 7200 
resources.cachemanager.database.frontend.options.automatic_serialization = true 
resources.cachemanager.database.backend.name = File 
resources.cachemanager.database.backend.customBackendNaming = false 
resources.cachemanager.database.backend.options.cache_dir = HTTPDOCS_PATH "/data/cache/database" 
resources.cachemanager.database.frontendBackendAutoload = false 

[cli : production] 

* <] :-)

Answer 1

Essayez

resources.cachemanager.database.frontend.options.caching = false 

Voir la API et la ZF Reference Guide pour la propriété $_options dans Zend_Cache_Core

Answer 2

Comme vous, je ne vois pas de moyen évident de désactiver un plugin dans une section de configuration enregistrée dans une section parent. Ce serait cool si Zend_Config_Ini permettait l'héritage multiple, un peu comme comment un élément HTML peut avoir plusieurs classes CSS dans l'attribut de classe. (Est-ce que je ne devine pas). Ensuite, vous pouvez mettre l'enregistrement du plugin dans une section [myplugsection], permettre [production] d'étendre [myplug] tandis que [cli] n'a pas, un peu comme comment Doctrine a actAs modèles et beahviors. La prochaine meilleure chose pourrait être de créer une section appelée quelque chose comme [core] contenant la plupart de ce que vous avez maintenant dans [production]. Les deux [production] et [cli] pourraient étendre [core], mais [production] enregistrerait le plugin tandis que [cli] ne le ferait pas.

Bien sûr, une alternative serait de déplacer l'enregistrement du plugin dans Bootstrap où vous avez un contrôle plus fin de l'enregistrement du plugin. En particulier, vous pouvez appeler $front->unregisterPlugin(), où $front est le FrontController. Il suffit de penser à haute voix ...

Cheers!