Enables developers to modify Magento installations (configuration, data, ...) based on the given environment using n98-magerun.
Latest Release
Development Branch
- version: 1.2.0
- extension key: LimeSoda_EnvironmentConfiguration
- extension on GitHub
- PHP >= 5.3.0
- Mage_Core
- n98-magerun
- Magento >= EE 1.13.0.2 (should also work on older and CE versions)
- Install the extension via modman or Composer.
- Add names to your environments.
- Configure environments.
After configuring your environments (see below) call n98-magerun like this:
n98-magerun.phar ls:env:configure [environment]
Configure the environment of the environment in your XML. Most of the time you will want to put this in local.xml as this file doesn't get shared between copies of the shop in most setups.
<config>
<global>
<limesoda>
<environment>
<name>dev</name>
</environment>
</limesoda>
</global>
</config>
Create a new extension (or use an existing one) and add a global > limesoda > environments node to your config.xml:
<?xml version="1.0"?>
<config>
<global>
<limesoda>
<environments>
<default />
</environments>
</limesoda>
</global>
</config>
Congratulations, you created your "default" environment!
Calling
n98-magerun.phar ls:env:configure default
will execute the actions you specified for this environment.
Next we create a command. You create a commands node beneath your environment node. To add a command, you choose a
unique node name and add the n98-magerun command as the value:
<?xml version="1.0"?>
<config>
<global>
<limesoda>
<environments>
<default>
<commands>
<cfg_wubu>config:set "web/unsecure/base_url" "http://www.domain.tld/"</cfg_wubu>
</commands>
</default>
</environments>
</limesoda>
</global>
</config>
You can replace hard-coded strings (e.g. URLs) with variables. Add variables for your environment as children of a
variables node. Then you can insert the values into commands using the notation ${variable_name}.
<?xml version="1.0"?>
<config>
<global>
<limesoda>
<environments>
<default>
<variables>
<unsecure_base_url><![CDATA[http://www.domain.tld/]]></unsecure_base_url>
</variables>
<commands>
<cfg_wubu>config:set "web/unsecure/base_url" "${unsecure_base_url}"</cfg_wubu>
</commands>
</default>
</environments>
</limesoda>
</global>
</config>
In the first two examples we set a value for System > Configuration using the normal config:set syntax. If you have
to do this for many values and different scopes this can get confusing.
Alternatively you can use a special system_config node for setting values. It supports scopes the same way you know
it from the default, websites and stores nodes in config.xml.
Use encrypt="true" to set an encrypted configuration value.
<?xml version="1.0"?>
<config>
<global>
<limesoda>
<environments>
<default>
<variables>
<unsecure_base_url><![CDATA[http://www.domain.tld/]]></unsecure_base_url>
</variables>
<system_configuration>
<default>
<web>
<unsecure>
<base_url>${unsecure_base_url}</base_url>
</unsecure>
</web>
</default>
</system_configuration>
</default>
</environments>
</limesoda>
</global>
</config>
Define values on website and store view scopes the same way. You can use the website and store code instead of the numeric ids. If you for whatever reason prefer the ID you also can use this one instead.
<?xml version="1.0"?>
<config>
<global>
<limesoda>
<environments>
<default>
<variables>
<unsecure_base_url><![CDATA[http://www.domain.tld/]]></unsecure_base_url>
</variables>
<system_configuration>
<default>
<web>
<unsecure>
<base_url>${unsecure_base_url}</base_url>
</unsecure>
</web>
</default>
<websites>
<first_website>
<web>
<unsecure>
<base_url>${unsecure_base_url}</base_url>
</unsecure>
</web>
</first_website>
<second_website>
<web>
<unsecure>
<base_url>http://seconddomain.tld/</base_url>
</unsecure>
</web>
</second_website>
</websites>
<stores>
<third_store>
<web>
<unsecure>
<base_url>http://thirddomain.tld/</base_url>
</unsecure>
</web>
</third_store>
<4>
<web>
<unsecure>
<base_url>http://fourthdomain.tld/</base_url>
</unsecure>
</web>
<4>
</stores>
</system_configuration>
</default>
</environments>
</limesoda>
</global>
</config>
In the first two examples all commands were placed in the commands node. As we just mentioned you can use
system_configuration to put all system configuration settings in its own node and make big configurations clearer.
You still may have many commands left which have to be specified in commands and have a hard time sorting them in the
right way by being creative with the names of the XML nodes.
To help a little bit with that you can use two custom stages, pre_configure and post_configure, which are executed
before and after the operations in commands are processed.
<?xml version="1.0"?>
<config>
<global>
<limesoda>
<environments>
<default>
<variables>
<unsecure_base_url><![CDATA[http://www.domain.tld/]]></unsecure_base_url>
</variables>
<commands>
<cfg_wubu>config:set "web/unsecure/base_url" "${unsecure_base_url}"</cfg_wubu>
</commands>
<post_configure>
<cd>cache:disable</cd>
<cf>cache:flush</cf>
</post_configure>
</default>
</environments>
</limesoda>
</global>
</config>
The settings from system_configuration are applied in the commands stage. This means the commands will be added in
the following order:
- pre_configure
- commands
- system_configuration
- post_configure
Using variables is nice but the most you will profit if you nest environments. This means you can create a base
definition for commands and variables and expand them in other environments. You do this by specifying the parent in
your environments base node: <dev parent="default">.
A typical setup could be:
- default
- dev
- developer 1
- developer 2
- developer 3
- test
- qa
- staging
- live
- dev
If you want to re-build this setup for the environment configuration, your XML will look like this:
<?xml version="1.0"?>
<config>
<global>
<limesoda>
<environments>
<default />
<dev parent="default" />
<dev01 parent="dev" />
<dev02 parent="dev" />
<dev03 parent="dev" />
<test parent="default" />
<qa parent="default" />
<staging parent="default" />
<live parent="default" />
</environments>
</limesoda>
</global>
</config>
If you define a command or variable in a parent environment, the child environment will inherit them.
By specifying commands and variables on different levels, you can save yourself some typing and maintenance work. In the next example we disable and flush the cache for all environments while setting a different URL for every environment.
<?xml version="1.0"?>
<config>
<global>
<limesoda>
<environments>
<default>
<variables>
<unsecure_base_url><![CDATA[http://www.domain.tld/]]></unsecure_base_url>
</variables>
<commands>
<cfg_wubu>config:set "web/unsecure/base_url" "${unsecure_base_url}"</cfg_wubu>
</commands>
</default>
<dev parent="default">
<variables>
<unsecure_base_url><![CDATA[http://dev.domain.tld/]]></unsecure_base_url>
</variables>
<commands>
<cd>cache:disable</cd>
<cf>cache:flush</cf>
</commands>
</dev>
<dev01 parent="dev">
<variables>
<unsecure_base_url><![CDATA[http://dev01.domain.tld/]]></unsecure_base_url>
</variables>
</dev01>
<dev02 parent="dev">
<variables>
<unsecure_base_url><![CDATA[http://dev02.domain.tld/]]></unsecure_base_url>
</variables>
</dev02>
<dev03 parent="dev">
<variables>
<unsecure_base_url><![CDATA[http://dev03.domain.tld/]]></unsecure_base_url>
</variables>
</dev03>
</environments>
</limesoda>
</global>
</config>
You can use this config.xml skeleton as a starting point for your environment configuration.
<?xml version="1.0" encoding="UTF-8"?>
<config>
<modules>
<YourCompany_YourModule>
<version>0.0.1</version>
</YourCompany_YourModule>
</modules>
<global>
<limesoda>
<environments>
<default>
<variables>
</variables>
<commands>
</commands>
</default>
<dev parent="default">
<variables>
</variables>
<commands>
</commands>
</dev>
<developer1 parent="dev">
<variables>
</variables>
<commands>
</commands>
</developer1>
<testing parent="default">
<variables>
</variables>
<commands>
</commands>
</testing>
<staging parent="default">
<variables>
</variables>
<commands>
</commands>
</staging>
<live parent="default">
<variables>
</variables>
<commands>
</commands>
</live>
</environments>
</limesoda>
</global>
</config>
###ls:aoe:scheduler:job:status
Enables and disables cron jobs as used by Aoe_Scheduler >= 1.0.0.
<commands>
<example>ls:aoe:scheduler:job:status "[jobcode]" "[status]"</example>
</commands>
All arguments are required.
- jobcode: The Magento cron job code (e.g.
core_email_queue_send_all) - status:
0for inactive,1for active.
Example:
<commands>
<example>ls:aoe:scheduler:job:status "core_email_queue_send_all" "0"</example>
</commands>
You will get an output like Job 'example_cron': set status to '0'. which makes it easier to identify changes to the
crons.
###ls:ess:m2epro:channel:status
Sets the channel status for Ess_M2ePro. The extension has to be installed and enabled.
<commands>
<example>ls:ess:m2epro:channel:status "[name]" "[status]"</example>
</commands>
###ls:ess:m2epro:license:key
Sets the license key for Ess_M2ePro. The extension has to be installed and enabled.
<commands>
<example>ls:ess:m2epro:license:key "[key]"</example>
</commands>
Navigate to System > Environment Configuration to get a list of all configured environments.
Click on an environment to get a list of the commands that will be executed. Variables not defined for the environment are highlighted.
You can enable an header bar in System > Configuration > Advanced > Admin > Environment Configuration > Display environment name above admin header.
To make it easier for you to differentiate between environments you can configure the font and background color per environment:
<environments>
<mz>
<settings>
<color>#fff</color>
<background_color>#090</background_color>
</settings>
</mz>
</environments>
Just like any other modman or Composer installed extension. No database tables or other additional files are created.
If you have any issues with this extension, open an issue on GitHub.
Any contribution is highly appreciated. The best way to contribute code is to open a
pull request on GitHub. Please create your pull request against
the dev branch.
Matthias Zeis
http://www.limesoda.com
@mzeis
OSL - Open Software Licence 3.0
(c) 2014-2015 LimeSoda Interactive Marketing GmbH
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent