Home/ Questions/Q 8939649
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T10:51:57+00:00

I’ve read several tutorial on the subject, but still don’t completely get what’s expected

  • 0

I’ve read several tutorial on the subject, but still don’t completely get what’s expected from the developer wanting to make ZF2 app environment aware:

http://blog.evan.pro/environment-specific-configuration-in-zend-framework-2
http://www.spiffyjr.me/2012/06/17/how-does-configuration-work-in-zf2/comment-page-1/

ZF2 s not aware of environment concept by design – it’s left to a developer to implement. I’m not entirely clear on how it’s supposed to be done…

Reading through Evan’s post it seems like there are 2 mechanism – and preferred one is not to use APPLICATION_ENV constant, just .local, .global files?

How should that work? Could someone describe a process they go though to make ZF2 environment aware? And what you do when code is to be pushed to different environment?

It seems like the idea is right now to have for ex: module1.local.php.dist-testing, module1.local.php.dist-production, module1.local.php.dist-development and when code is moved to different environment the idea is that these should be copy-renamed for that environment and passwords filled in manually? Am I correct?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The idea is that you provide some sensible default configuration with your application, but you do not store anything for a concrete environment with your code, nor in your version control system.

    If you have for example two servers, one for production, one for development, you provide only the configuration details for one single environment in such a .local file. This way, your development server cannot know e.g. the master password for the production database. So it cannot accidentally happen that you get a new development server, and somebody forgets to set APPLICATION_ENV, and you start developing and mess up your production database, because the application knew the passwords.

    Or the other way around, a new production server cannot accidentally access the development database.

    So your application is aware of the environment automatically by reading the file that is present – and there is only one file per environment present that has all the details.

    This puts the burden of ensuring that the correct file is present to the administrator – or the puppet script that configures everything. But the environment specific configuration will not be deployed within the application.

    • 0