35
In Craft 3 you can get the env using the getenv() function:
{% set env = getenv('ENVIRONMENT') %}
{% if env == 'dev' %}
hello dev
{% else %}
hello world
{% endif %}
Or via the app’s config service:
{% set env = craft.app.config.env %}
There's a bit more information about the .env file in the docs for Environmental Configuration.
32
As of Craft 2.4, it is now possible to use the enableTemplateCaching config value.
'enableTemplateCaching' => false,
Simply add that to your local environment in config/general.php, and it'll disable the cache tags entirely.
25
Matt has a point, this is similar to What's the best practice for handling data migration and organization across development environments?, but that question focuses mainly on how to handle the database (definitely see those answers).
More generally speaking...
Multi-Environment Config
Set yourself up with Multi-Environment Configs in both craft/config/...
25
When developing locally on Craft you would most likely have devMode => true set in your config file and set to false for your production config.
app/config/general.php
return array(
'mydevdomain.dev' => array(
'devMode' => true
),
'mylivedomain.com' => array(
'devMode' => false
)
);
So you could test whether craft is in dev mode ...
19
You can get to any of your config variables (including custom ones) like this:
{{ craft.config.xyz }}
The environmentVariables array is no different:
{{ craft.config.environmentVariables.baseUrl }}
See the craft.config documentation.
17
When working with multiple environments you most likely want to disable caching for all but one environment, because Craft saves the absolute URL to entries/assets in the cache.
I achieved this by setting a custom variable in general.php
'craft.dev' => array(
'cache' => true,
'environmentVariables' => array(...),
)
'192.168.178.20' => ...
12
Make sure to change the "Site URL" setting to {siteUrl} in your control panel settings...
Control Panel > Settings > General > "Site URL"
Within your config file, you'll also want to put your siteUrl value inside of an Environment-Specific Variables sub-array:
'mynewcraftsite.dev' => array(
'devMode' => true,
'environmentVariables' => ...
12
In my experience, the order does matter. The array is read in order from top to bottom testing the domain for a match against each criteria (key). If there's a match, that array of settings is used and continues down the list which can possibly overwrite variables that were previously set.
For example, in this configuration...
// Development
'dev.mywebsite....
10
The difference in both size and speed is likely because Sequel Pro (and any other MySQL client) is likely using mysqldump, which is a native CLI command and highly optimized.
Craft can't rely on that for a variety of reasons (PHP might have have exec permissions, the account Craft uses to connect to the database might not have the permissions necessary to ...
9
These are the two approaches I usually choose from:
Option 1: the 'default' Craft 3 way
Create a .env file for every environment you create, and add it to your .gitignore file (if it's not yet in it). In this file, you put all environment-specific details;
Craft, by default, will recognize and use those details.
In your Craft config files, you can use the ...
8
There are multiple ways to set the URLs to your files. I don't know if I got your folder structure right. But let's suppose that your web root is set to
/var/www/craft-portfolio/public/,
your CSS folder is
/var/www/craft-portfolio/public/css/
and your Craft folder (actually not relevant) is
/var/www/craft-portfolio/craft/.
Root-relative URL
Root-relative ...
7
You can set a custom "environment label" variable inside config/general.php:
return array(
// ALL ENVIRONMENTS
'*' => array(
),
// LOCAL
'mysite.local' => array(
'env' => 'local'
),
// DEV
'dev.mysite.com' => array(
'env' => 'dev'
),
// PROD
'www.mysite.com' => array(
'env'...
7
If people don't need to change these through the control panel, I would put them in the general.php config file.
Here's how I would do it:
return array(
'*' => array (
// default to not doing analytics
'doAnalytics' => false,
// all the analytics codes, by locale
'gaCodes' => array(
'fr_fr' => 'UAxxx',
'en_us' =>...
6
I'd recommend you take a look at the excellent existing threads on this:
Git Workflow and Multi Environment - how to approach
What's the best practice for handling data migration and organization across development environments?
as well as the official documentation on Multi-Environment Configs
6
It looks like getenv returns a string (or false if the variable is not set, but it is in this case). So you need to cast the string to a boolean value to make it work. However, (bool)'false' gives true, not false. There are two possible solutions:
Set the variable to 0 instead of false in your .env file:
DEV_MODE=0
AUTO_UPDATE=0
And then in your config:
'...
6
The routes.php config file doesn't support multi-environment setups in the manner that general.php or db.php does – in other words, your example code using a multidimensional array would throw an error.
As a workaround, you can write some PHP in your routes.php file. For simple stuff, a ternary operator may suffice:
return array(
'test' => strpos(...
answered Jul 24 '16 at 8:52
Mats Mikkel Rummelhoff
18.8k3 gold badges26 silver badges59 bronze badges
6
That's the setup we use here. It's ok, but local development runs slowly because the database is off-site - we'll be moving to an internal database server in the new year because of that.
Image transforms we just deal with by manually syncing the folders every now and then. I believe Andrew Welch has a script to help manage that - I've not tried it https://...
5
Multi-environment configs require you to create a '*' config array, even if it’s empty because there aren’t any config settings that you need to set globally. Simply having that '*' array is how Craft is able to determine that this is a multi-environment config, as opposed to '.dev' and '.org' just being normal config settings. (See the warning on http://...
5
I found this post and the answer by @carlcs helpful. However, I find the phrasing unless not in the cache logic a bit hard to wrap my head around. I want to note here an alternative to the syntax above that I found more intuitive:
general.php
return array(
'live' => array(
'cache' => true
),
'local' => array(
'cache' ...
5
I believe you're looking for the 'allowAutoUpdates' config option combined with multi-environment configs.
5
I got the official answer from Brandon, here is the summary for anyone that might be in a similar situation:
I can do what I need with only one pro license
the main portal (acme.com) will run the "en" locale
additional domains will use different locales (en-uk for UK, etc.)
this will work even better in Craft 3.0 - there will be a support for "portal" and ...
5
Unfortunately, this isn't currently possible.
This feature request is very similar to what you're requesting... however, it would still require that all of your environments use the same type of asset source.
4
Did you configure siteUrl in general.php?
return array(
// ...
'siteUrl' => array(
'en' => 'http://example.com/en/',
'de' => 'http://example.com/de/',
),
);
4
You can define CRAFT_ENVIRONMENT in your index.php like so:
switch ($_SERVER['SERVER_PORT']) {
case "8081":
define('CRAFT_ENVIRONMENT', 'TRUNK');
break;
case "8082":
define('CRAFT_ENVIRONMENT', 'BRANCH');
break;
}
And then in general.php and db.php you can:
return array(
'*' => array(
...
),
'TRUNK' => array(
...
)...
4
Short answer, no. You'll want to make sure that your DB user has all of the necessary privileges.
Just because you're not entering your data into the database doesn't mean that Craft isn't writing its own data into the database. There are several tables responsible for handling data which is automatically generated by Craft, and not managed directly by ...
4
What I like to do is explicitly set CRAFT_ENVIRONMENT in my index.php:
switch($_SERVER['SERVER_NAME']) {
case 'domain.dev':
define('CRAFT_ENVIRONMENT', 'LOCAL');
break;
case 'staging.domain.com':
define('CRAFT_ENVIRONMENT', 'STAGING');
break;
case 'www.domain.com':
case 'domain.com':
define('CRAFT_ENVIRONMENT', 'PRODUCTION');
...
4
I wouldn't do it, personally. Especially if your plugin interacts with the database and you'll be creating/deleting tables, altering the schema, needing to restore the database, etc.
Too much risk in breaking the live site and very little benefit.
4
These are the settings I have in place for config.php and .htaccess file.
4
The short answer is yes — you need to use a domain names.
You might also want to have a look at this multi-environment configuration method defined on the craft cookbook website that creates a global php variable called CRAFT_ENVIRONMENT in your main index.php.
I generally use that in combination with Ben Parizek technique as described in this answer.
4
Generally speaking, locales are designed to share the same templates, so craft is not necessarily looking for a /template/[locale]/ folder to find the correct templates to load. You may have to specify the different locale template paths as part of your section settings in that locales database. As far as I know the only automatic locale routing happens in ...
Only top voted, non community-wiki answers of a minimum length are eligible