Adobe Commerce on cloud infrastructure - Development configurations

Transcript

Unit 5, Development. Well, a general term development. We’ll just take a look at specifically Magento Store Configuration. So there’s not much here in this unit that is Cloud specific, but it does get into the Magento Store Configuration features which Magento Cloud relies on heavily.

This is my favorite feature, favorite upgrade from Magento 1. Is the ability to just have these multiple ways to do store configurations. So we’ll take a look at store configurations. And store configurations are just, as a recap. This is when you go into your store configuration area of the Magento admin, all of these choices you have, these are collectively referred to as store configuration. So how does store configuration come about? We’ll take a look at the fallback system that’s in place.

So store configuration is originally defined within a module. And if you’re building a module, and you’d like some store configuration options. Then you’re going to have a config.xml file, which defines those store configurations and also defines some default values for store configuration.

Now, what happens when you’re in the admin of a working site and you set store configuration a certain way, is you’re over here on the left. You’re adding those values to the core config data table in the database. And then those values are effectively overwriting the default values found in config.xml.

So going back to Magento 1, that’s kind of where the system ended. But Magento 2, has a more robust system.

If you haven’t utilized this, I’d highly recommend this. So on top of the database, you have a couple of configuration files where you can store, store configuration. One is app/etc/env.php, and the other is app/etc/config.php. So any store configuration defined in here, will overwrite what’s in the database. So this is as a great place to store environment specific store configuration, like for instance, base URLs.

Your base URLs will be different in each environment. 'Cause each environment has a different URL at which it’s accessed. So instead of going down into the database and adjusting those, it’s much more convenient for a couple of reasons to actually put those in the app/etc/env file, which is an environment specific file that is not committed to the database. So you can have those environments specific values in there that will always be set appropriately for that environment.

Now on top of that as well, we have the Unix environment variables shown here with the dollar underscore ENV prefix, those will overwrite everything. Anything set at that level, that’s the highest, precedents or highest level of hierarchy for store configuration.

So taking a look at something that most Magento developers are familiar with, the Core Config Data Table, which has a configuration path, the value of that is set for that particular configuration. And then also at scope level, because you can set things at three different levels of scope, either the global level, the website level or the store level.

So that’s everything you need to do to define store configuration. If you want something to overwrite that in for instance, the app/etc/config.php file, then what you’re going to do is you’re going to create a php kind of nested array of this nature where you’re starting off in system. And then from there you’re defining your scope, say the default scope.

And then you’ve got the path that you’re trying to set configuration that on different levels here, you’re continuing to next URL until you get all the way down to the value. So this would be genera/locale/code set at the default scope. Backing up to the slide here we can see here, this config ID 3 general locale code set to en US.

This scope or config ID, number 3 here in the database and this in the app/etc/config.php these are the same effectively.

Except that this config.php value is overwriting what is in the database.

If you don’t want to have to write out these big php arrays by hand, which nobody does, there is an ece tools command that will dump all of your store configuration into the config.php file automatically.

And then taking a look at Environment Variables, you’ve got, if you want to set store configuration in environment variables, then you’ll create an environment variable with this format here, it’ll have a stable prefix. You’ll always start with config. and then two underscores. In all of these locations that you see underscores there are two. To separate these different elements of the path. So you’ve got your scope. And then you’ve got once again, the three parts of your path general, locale and time zone.

So a few more examples here.

This middle one is setting a configuration value at the website level. So your scope level is websites and then you put in the short name of your website which you defined when you created the website and then down here at the bottom same thing on here at the store scope level with the store identified as default general locale time zone.

Now that we’ve examined Magento’s configuration scheme, what are all the places in a magento-cloud project where you can set those configurations? Well, it turns out there’s a lot. There’s at least five different places where you can set those store configurations. A lot of options, and it can be confusing that there’s a lot of options. But also all of these options look and feel a little bit different so it just gives you the ability to organize your project a little bit differently.

So one of the places you can set store configuration obviously is the Magento admin. These values will go into the database core config data table.

Another way to do the same thing as here from the bin magento cli, you can do config set. Once again you’ve got your path there. You can set different scope levels with these options. And then the last thing you add is the value that you want to set.

This lock config option will actually… You can use bin magento to put these values either in the database, the config.php table or the env.php file. And there’s an option for each of those values. In this case, we’ve used lock config, which puts these values or sets this configuration in config.php.

Now, if you’ll remember all the way back to our app.yaml file, the unit where we examined this file at the very end of that configuration file, there is a chance to send store configuration in environment variables. There’s the format of the variable and the value that we’re looking for there. Another place is in the cloud UI, there for each environment, you can define a list of these environment variables. So once again, this is putting in store configuration in an environment variable in that environment. And we’re configuring it as such with a prefix of env: you want to remember that a little bit of an eccentricity, but you need this env: prefix when you’re using this cloud UI.

This is a great place for setting environment specific store configuration, because this has the ability to apply to only one environment.

You wouldn’t want to use one of the options where you’re committing a code or committing something to the repository because then that would likely be effective on all the environments.

So this is a great way to put in environment specific store configuration.

And then there is also, this is demonstrating the Magento Cloud CLI also has the same ability to add store configuration to environment variables.

Okay, that’s the end of unit 5… -