IIS.Magento » beginner guide

Using magento configuration data

Richard — Sun, 21 Jun 2009 11:18:13 +0000

The previous post looked at how to add configuration variables to Magento. This Post will show how to set and use the variables.

The naming convention for variables is the path through the xml, section/group/form. So the url variable from the previous post is shipping/mydispatch/url.

The function to retireve the value of the variable is

Mage::getStoreConfig(’shipping/mydispatch/url’)

for a specific store use

Mage::getStoreConfig(’shipping/mydispatch/url’,x)

Where x is id of the store

The default variables can also be set in the config.xml file for your module. For example to set default test values for the mydispatch module one can use the following









test.mydispatch.com/testsystem

Tester1

Password1

Adding configuration variables to Magento

Richard — Sun, 21 Jun 2009 10:18:18 +0000

Configuration variables in Magento control the setup an operation of your store, through the configuration settings in the admin portal. Creating new configuration variables and sections for your own modules is very straight forward.

Looking at the configuration for an existing configuration section, the Locale options in the General section.

So we can write the location of each variable shown as

config/general/locale/timezone
config/general/locale/locale
config/general/ locale/first
config/ general/locale/weekend

I have used only the first word of each name to simplify the path. Conveniently this maps to the xml that is used to build these variables; shown below.




General
general
text
10
1
1
1


Locale options
text
8
1
1
1


Timezone
select
adminhtml/system_config_source_locale_timezone
1
1
1
0


Locale
select
adminhtml/system_config_source_locale
5
1
1
1


First Day of Week
select
adminhtml/system_config_source_locale_weekdays
10
1
1
1


Weekend Days
multiselect
adminhtml/system_config_source_locale_weekdays
15
1
1
1

Looking at the first 4 lines it states that this is configuration data, the section tag shows that the next tag will be at the section level. The general tag is the identifier for the section. Imediately within this are a five tags which configure the section.
Following the section configuration is the groups tag. This indicates that the next blocks are groups. The locale tag is the identifier for the group. as with the section the next 6 tags set the properties for the group.
The fields tag then indicates that the following blocks represent the fields to show. Again the first tag is the idenitifer of the field, followed by tags to configure the field.
The configuration variables at the section and groups levels are

label – The displayed text
tab – which menu tab the section appears within
frontend_type – always text for sections and groups
sort_order – order of display lower number shows higher
show_in_default – Show in the default view
show_in_website – Show in the website level view
show_in_store – Show in the store level view

configuration tags for field

label
frontend_type – field type – text, textarea, select, label, image, multiselect, time, password, allowspecific
source_model – Model class to call for list data
sort_order
show_in_default
show_in_website
show_in_store

Example

The example module acme_mydispatch needs configuration variables to set the url to connect on and the user account details. This logically goes in the shipping section. The xml used is








My Dispatch Connection data
text
50
1
0
0





url
text
10
1
1
1





User ID
text
20
1
1
1





Secret Key
password
30
1
1
1

This creates the configuration settings shown below.

In the next post I’ll look at how to use the new variables we have just created.

Note – creating a new section requires a module to be defined, in version 1.2 this assumes the module is a mage_ module. this make screating custom tabs trciky and a topic for a future post.

Magento Modules

Richard — Thu, 18 Jun 2009 15:48:26 +0000

Magento is built using the MVC model, this provides for clear sepperation of the logic and display. Each part of Magento is constructed as a module which adhears to this convention. When developing new modules you must also adhear to the convention.

Initially the structure can be a little hard to understand, however once over the learning hurdle it becomes very easy to add new features or override exisiting features.

At it’s simplest a module is two files, one to tell the system the module exists and one to detail the features of the module.

A module must follow a simple naming convention, of developer_moduleTitle. The developer will be your name or buisness name, the module title is the descriptive name for the module. For example a business called Acme creating a module to integrate with their dispatch system called mydispatch might create a module acme_mydispatch.

The module name is also the folder path to store all the files for the module. It is important that folder paths follow the naming conventions as paths are determined from class or module names and visa versa.

All modules exist in one of three folders, these are code\core, code\community, code\local

core – used for all magento built in modules. Never edit this folder.
community – used for modules downloaded from the magento community.
local – used for your own developed code. Always place your overrides and modules in this folder.

Magento is written such that folders have a hierachy of local->community->core. Within the local folders the module is structured as developer/module. The folder structure for the example module is shown on the right.

config.xml

config.xml must exist in the etc folder. The file contains xml which tells Magento how to apply the module. This includes

version number
available models
url rewrite rules
url definitions
helpers

The version is used by magento to determine if it should run SQL scripts to update the database for the current version. This means that upgrading the module is a case of dropping in the new files and updating the version number.

Models, url rewrites, url definitions and helpers will be explained more in future posts. Below is an example of the minimum possible XML




0.1.0

acme_mydispatch.xml

Magento needs to know that your module exists. This is done by creating an xml file in app/etc/modules called developer_module.xml. The xml tells magento the activation state and the code pool. In most cases activation state will be true as you want to use the module. The code pool is the code the module should use by default. generally this will be local.

Below is an example of the XML.





true
local

Check the module is loaded

To check the module has loaded, open the Magento admin interface and browse to System/Configuration/Advanced. Expand the Disable modules output section, this lists all loaded modules. Your module should be listed and the active state match that set in your config file.