zendframework
Generate module configuration cache via command line
Related to PR https://github.com/zendframework/zend-modulemanager/pull/53.
On a production running website one would ideally have the module-config-cache.php file generated before launching a new version. It would help if a command line utility would exist for this. This could work like the autoloader could be generated beforehand: https://framework.zend.com/manual/2.2/en/modules/zend.loader.classmap-generator.html.
Any thoughts on this?
@roelvanduijnhoven module config generally is applied with any CLI command execution (due to it caching-style transparent API), so a "hello world" action in your app should be sufficient in order to generate all cache config.
Another issue about this is that the CWD must match in order for many configs to actually work as expected.
Mm. True. Config depending on $_SERVER will break for example. And although you should not do so; some people most likely are using it that way. So I guess what I propose won't really work.
Maybe close this one; and properly fix locking.
Agree that they shouldn't do that 😥.
Maybe a validation CLI command that verifies generated config is idempotent, before dumping it somewhere?
On 17 Feb 2017 1:42 p.m., "Roel van Duijnhoven" [email protected] wrote:
Mm. True. Config depending on $_SERVER will break for example. And although you should not do so; some people most likely are using it that way. So I guess what I propose won't really work.
Maybe close this one; and properly fix locking.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/zendframework/zend-modulemanager/issues/54#issuecomment-280639177, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakNvX2kHszCd1XGZnWJ46PiTSnAw4ks5rdZWdgaJpZM4MENnD .
If you use a timestamp as a cache key somewhere in your configuration; you get two config files that are not idempotent. But that is a valid usecase, right? So idempotent is not important IMO.
The thing is that the config generated via CLI should work on web in an ideal world. But I am almost sure that this won't be true in a lot of real-world use cases.
If you really want to warm up your cache you should expose an end-point on the web; that will trigger the config generation. But that is outside of the scope of this repo, right?
But that is a valid usecase, right? So idempotent is not important IMO.
It is EXTREMELY important, because that already shows that you can't cache config.
The thing is that the config generated via CLI should work on web in an ideal world. But I am almost sure that this won't be true in a lot of real-world use cases.
That's where the validation would simply make the generator crash. It wouldn't prevent the user from caching configs, but at least it would say "You're on your own, buddy! You're doing things that I don't want to be held responsible for.".
If you really want to warm up your cache you should expose an end-point on the web; that will trigger the config generation. But that is outside of the scope of this repo, right?
Yes, that's out of scope and it also opens a can of worms when it comes to security issues (DDoS related, specifically)
This repository has been closed and moved to laminas/laminas-modulemanager; a new issue has been opened at https://github.com/laminas/laminas-modulemanager/issues/5.
