Generate module configuration cache via command line

[weierophinney]

Related to PR zendframework/zend-modulemanager#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?

---

Originally posted by @roelvanduijnhoven at zendframework/zend-modulemanager#54

[weierophinney]

@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.

---

Originally posted by @Ocramius at zendframework/zend-modulemanager#54 (comment)

[weierophinney]

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.

---

Originally posted by @roelvanduijnhoven at zendframework/zend-modulemanager#54 (comment)

[weierophinney]

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
zendframework/zend-modulemanager#54 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakNvX2kHszCd1XGZnWJ46PiTSnAw4ks5rdZWdgaJpZM4MENnD
.

---

Originally posted by @Ocramius at zendframework/zend-modulemanager#54 (comment)

[weierophinney]

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?

---

Originally posted by @roelvanduijnhoven at zendframework/zend-modulemanager#54 (comment)

[weierophinney]

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)

---

Originally posted by @Ocramius at zendframework/zend-modulemanager#54 (comment)