1.2: Create switch to toggle functionality

We will kick off our module's features by creating the Store Configuration setting that will control whether the order export feature is enabled. Always, always create a feature toggle for custom functionality you build, no matter the requirements and however unlikely you may think the possibility of needing to turn it off!

Technical Blueprint: Create Store Config settings in the Sales section.

Settings for the admin Store Configuration section are defined in etc/adminhtml/system.xml within the module directory. Our blueprint says we want our settings in the existing Sales section. So how do we figure out what taxonomy to use in system.xml?

Before we look to code, our first stop should be simply to visit Store Configuration (Stores > Configuration in the admin) to find the section. We quickly find the Sales section under the Sales tab. To keep our settings cleanly separated, we will create our own group within the section for this module.

Now that you have a good understanding of the section in question, search the vendor/magento directory for all instances of "Sales", limiting the search to files named system.xml. Or pure deduction might lead you to vendor/magento/module-sales/etc/adminhtml/system.xml in the first place. You'll find the Store Config section details there and, most importantly, the id that identifies it:

<section id="sales" ...

We'll use this ID to extend the section.

Create the Store Config group and field

Any existing system.xml file, including the one from the Sales module you've already found, can easily be used to obtain the proper XML format defining a hierarchy of sections, groups, and fields. We'll add such a hierarchy to app/code/SwiftOtter/OrderExport/etc/adminhtml/system.xml.

Our aim is to:

• Add a new group "Order Export" to the Sales section
• Create one field in that group for now: "Enabled"
• Make "Enabled" a drop-down that can be toggled to "Yes" or "No".

Tips:

• The ID we discovered in the Sales module file tells us how to start our hierarchy.
• Because another module already defines the main details of the section, we don't need to repeat any of its attributes except "id", or any child nodes except the new one for our group.
• source_model is the node that controls the values a drop-down field contains, and there is no shortage of "Yes"/"No" style fields. Try searching for system.xml files with Enabledisable or Yesno for an example.

And now a word on scope: All levels of the hierarchy in system.xml (section, group, and field) support attributes showInDefault, showInWebsite, and showInStore. These control what scopes the fields appear for, and you should make sure you are well familiar with the global, website and store scopes; the concept pervades many aspects of Adobe Commerce.

At what scopes an admin user should be able to edit a value is an important consideration for every setting you create. In our case, consider that an order is associated with a specific store. Therefore, it probably makes sense to be able to control our module's settings at any scope, including individual stores. (The scopes of our fields will help determine the appropriate values for our groups and sections too.)

Clear the cache (in the admin, or with bin/magento cache:flush) and visit Stores > Configuration > Sales > Sales to find your newly created group and field.

You might have noticed we have created only one field for now, when our requirements define several more. It's up to you whether to create all config fields at once, but in this course we're tackling things feature by feature, rather than file by file. Remember: Swiftly delivering a first working feature is more valuable than a host of config settings that don't do anything yet!

SEE THE CODE