So in this case, we’ll have omitScriptNameInUrls => true for all environments, but we’ll have devMode => false for example.com, and devMode => true for v. The * is a special wildcard that applies to all environments. The key in the top level of this array is the CRAFT_ENVIRONMENT constant, which by default is set to the hostname of the server. All of the files in the craft/config directory are multi-environment friendly - including third party plugin config files. Thankfully, the fine folks at Pixel & Tonic have built a nice multi-environment config right into Craft CMS. The problem compounds itself when you have multiple people working on a single project, especially with contractors that might have a different local dev setup than your own.
But you definitely do not want that same behavior in live production.Įach environment also might have a different database & password, a different location in the file system, and a host of other unique settings. For example, in local dev, you’d want to have devMode on, you’d want to disabled template caching, and so on, to make the website easier to debug. The reason for a multi-environment config is that the same website project may be running in a very different environment with different desired behaviors for each location. local - the local development environment where you develop and debug the site.staging - a pre-production environment where your client can view, test, and approve changes.live - the production environment that is public-facing.In a typical workflow, you might have a number of environments in which your website projects need to run:
Multi-Environment Configs let you easily run a Craft CMS project in a variety of environments, without painful setup or coordination. If you’re using Craft 3, use the principles outlined in the Flat Multi-Environment Config for Craft CMS 3article instead. N.B.: This article describes multi-environment configs for Craft CMS 2.
0 kommentar(er)
