2010-2
16

Magento news feed

Category: admin | No Comments

Each timeyou log into the Magento admin interface you will have noticed the notifications which appear to tell you about new magento versions. The notifications system collects the messages to display from an rss feed. As such you can replace the standard feed with your own; or point to a blank source to disable.

The feed location is defined in the config.xml file in code/core/Mage/AdminNotification/etc/config.xml

It is not good practice to change the data in this file, instead either add the config data to the XML configuration file of an existing module or add a new entry to the database to override the value.

All of the configuration data is stored in core_config_data. Add an entry to the table using the SQL,

INSERT INTO core_config_data</pre>
SET(scope='default', scope_id=0, path='system/adminnotification', VALUE='uri')

The RSS must follow the following pattern.

<?xml version="1.0" encoding="UTF-8"?></pre>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>My Custom Notifications</title>
<atom:link href="http://notifications.screenpages.com/?feed=rss2" rel="self" type="application/rss+xml" />
<link>http://mysite.notifications.com</link<!-- Source uri -->>
<description></description>
<copyright>Copyright (c) 2009 My company</copyright>
<webMaster>me@email.com</webMaster>
<language>en</language>
<lastBuildDate>Fri, 19 Jun 2010 16:20:05 +0000</lastBuildDate>
<item>
<title>Title</title>
<link>http://notifications.xxx.com</link><!-- link to the message -->
<severity>3</severity> <!--severity level between 1 and 4 -->
<description><![CDATA[Your content]]></description>
<pubDate>Fri, 19 Jun 2010 16:04:38 +0000</pubDate>

</item>
</channel>
</rss>
2009-6
21

Using magento configuration data

Category: beginner guide, code | 2 Comments

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

<config>

<default>

<shipping>

<mydispatch>

<url>test.mydispatch.com/testsystem</url>

<user>Tester1</user>

<secret>Password1</secret>

</mydispatch>

</shipping>

</default>

</config>
2009-6
21

Adding configuration variables to Magento

Category: beginner guide, code | 1 Comment

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.

configuration_general_locale

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.

<config>
<sections>
<general translate="label" module="core">
<label>General</label>
<tab>general</tab>
<frontend_type>text</frontend_type>
<sort_order>10</sort_order>
<show_in_default>1</show_in_default>
<show_in_website>1</show_in_website>
<show_in_store>1</show_in_store>
<groups>
<locale translate="label">
<label>Locale options</label>
<frontend_type>text</frontend_type>
<sort_order>8</sort_order>
<show_in_default>1</show_in_default>
<show_in_website>1</show_in_website>
<show_in_store>1</show_in_store>
<fields>
<timezone translate="label">
<label>Timezone</label>
<frontend_type>select</frontend_type>
<source_model>adminhtml/system_config_source_locale_timezone</source_model>
<sort_order>1</sort_order>
<show_in_default>1</show_in_default>
<show_in_website>1</show_in_website>
<show_in_store>0</show_in_store>
</timezone>
<code translate="label">
<label>Locale</label>
<frontend_type>select</frontend_type>
<source_model>adminhtml/system_config_source_locale</source_model>
<sort_order>5</sort_order>
<show_in_default>1</show_in_default>
<show_in_website>1</show_in_website>
<show_in_store>1</show_in_store>
</code>
<firstday translate="label">
<label>First Day of Week</label>
<frontend_type>select</frontend_type>
<source_model>adminhtml/system_config_source_locale_weekdays</source_model>
<sort_order>10</sort_order>
<show_in_default>1</show_in_default>
<show_in_website>1</show_in_website>
<show_in_store>1</show_in_store>
</firstday>
<weekend translate="label">
<label>Weekend Days</label>
<frontend_type>multiselect</frontend_type>
<source_model>adminhtml/system_config_source_locale_weekdays</source_model>
<sort_order>15</sort_order>
<show_in_default>1</show_in_default>
<show_in_website>1</show_in_website>
<show_in_store>1</show_in_store>
</weekend>
</fields>
</locale>
</groups>
</general>
</sections>
</config>

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

<config>
<sections>
<shipping>
<groups>

<mydispatch translate="label">

<label>My Dispatch Connection data</label>
<frontend_type>text</frontend_type>
<sort_order>50</sort_order>
<show_in_default>1</show_in_default>
<show_in_website>0</show_in_website>
<show_in_store>0</show_in_store>

<fields>

<url translate="label">

<label>url</label>
<frontend_type>text</frontend_type>
<sort_order>10</sort_order>
<show_in_default>1</show_in_default>
<show_in_website>1</show_in_website>
<show_in_store>1</show_in_store>

</url>

<user translate="label">

<label>User ID</label>
<frontend_type>text</frontend_type>
<sort_order>20</sort_order>
<show_in_default>1</show_in_default>
<show_in_website>1</show_in_website>
<show_in_store>1</show_in_store>

</user>

<secret translate="label">

<label>Secret Key</label>
<frontend_type>password</frontend_type>
<sort_order>30</sort_order>
<show_in_default>1</show_in_default>
<show_in_website>1</show_in_website>
<show_in_store>1</show_in_store>

</secret>

</fields>

</mydispatch>
</groups>
</shipping>
</sections>
</config>

This creates the configuration settings shown below.

shipping_settings
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.

2009-6
18

Magento Modules

Category: beginner guide, code | No Comments

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.

mydispatch_foldersMagento 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

<config>
<modules>
<acme_mydispatch>
<version>0.1.0</version>
</acme_mydispatch>
</modules>
</config>

<strong>acme_mydispatch.xml</strong>

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.

<?xml version="1.0"?>
<config>
<modules>
<acme_mydispatch>
<active>true</active>
<codePool>local</codePool>
</acme_mydispatch>
</modules>
</config>

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.

2009-6
14

Custom API – two approaches

Category: code | No Comments

Creating custom API interface can be done in two very different ways. This can make it very difficult to follow some of the online examples. The two common approaches are:

  • Create a custom module and implement the Zend Framework Soap method
  • Extend the core API More »
2009-6
11

Sucessful email with IIS SMTP and Magento

Category: code | No Comments

When running Magento under IIS most people will want to use the built in SMTP server. Unfortunately this doesn’t work out of the box as Magento sends both the to address and a from name in the email message, which is not correctly handled in the IIS smtp service. Emails will apear to send but will never be delivered. The solution is to override the email template in the magento core with a version which does not pass the username.

to do this copy \app\code\core\Mage\Core\Model\Email\template.php to \app\code\local\Mage\Core\Model\Email\template.php

Modify the section at about line 354 from

</pre>
$mail->setSubject('=?utf-8?B?'.base64_encode($this->getProcessedTemplateSubject($variables)).'?=');
$mail->setFrom($this->getSenderEmail(), $this->getSenderName());
<pre>
to
</pre>
$mail->setSubject('=?utf-8?B?'.base64_encode($this->getProcessedTemplateSubject($variables)).'?=');
$mail->setFrom($this->getSenderEmail());
Add a file called config.xml to code/core/mage/core/etc/config.xml this must contain the following xml
<?xml version="1.0"?>
<config>
<modules>
<Mage_Core>
<version>0.0.1</version>
</Mage_Core>
</modules>
<global>
<models>
<core>
<class>Mage_Core_Model</class>
</core>
</models>
</global>
<span style="font-family: Georgia; line-height: 19px; white-space: normal; font-size: 13px;">
<pre style="font: normal normal normal 12px/18px 'Courier New', monospace;">

Restart PHP.
If emails still don’t work check the following

  • The machine has permisisons to relay – add 127.0.01 to the list of IPs permitted to relay in the SMTP server config
  • Activate logging and check that the server connects to another mail server and doesn’t recieve an error – usually a number 5xx
  • The domain you are sending from has the ip address of the server included in the SPF record.