Tuesday 4 October 2011

Magento File Structure and Workflow


At a very high level, Magento is split into three main sections: skin, templates and code. Files are organized in the file system as follows:

Figure 1. Magento’s File Layout

/magento
   /app
      /code
         /community
            core code (PHP, XML)
         /core
            core code (PHP, XML)
         /local
            extensions, your modules (PHP, XML)
      /design
         /adminhtml
            backend themes (PHTML)
         /frontend
            frontend themes (PHTML)
         /skin
            skin (CSS, JS, images)
As you can see, there are many files in many places used to create functionality in Magento. To organize that functionality, Magento is split into modules, each of which provides a little functionality to the system. A module is comprised of several different types of files: configuration, localization, display information, controller code and information about models (usually database records). These files are also organized, this time according to MVC principles.
What that means effectively is that data, actions and presentation are split up and put into different places to keep them separate. That way, if you change a template in Magento, you don’t need to worry about the data models that make up the objects you use in that template. Here’s where the files for a single module are kept in the Magento tree:

Figure 2. The CatalogSearch module (from /app)

/code
   /core
      /Mage
         /CatalogSearch
            module code (see below)
/design
   /frontend
      /default
         /myTheme
            /layout
               catalogsearch.xml
            /template
               /catalogsearch
                  template files (PHTML)
/etc
   /modules
      Mage_CatalogSearch.xml
/locale
   /en_US
      Mage_CatalogSearch.csv (localization file)
Figure 3. The CatalogSearch module (from /CatalogSearch)

/Block
   Block classes (PHP)
/controller
   Controllers (PHP)
/etc
   Module configuration (XML)
/Model
   Model classes (PHP)
/Helper
   Helpers (PHP)
With files in so many places, it can be confusing trying to find the right file to work on. The best way to get a handle on that problem is to understand what data is in each location and why it’s put there. A module contains the following data:

Block Classes

   PHP Classes which gather data from Models and Helpers and give it to templates.

Controllers

   PHP Classes which define the pages that are available in a module and load the layout for those pages.

Helpers

   PHP Classes which contain common functions needed to retrieve or transform data in the module.

Layout File

   XML File that tells the controller which blocks to use.

Localization File

   CSV file that defines translations for text to allow multiple languages for a module.

Model Classes

   PHP Classes which retrieve data from other sources (like the database) and transform it using business logic.

Module Configuration

   XML file(s) which hook into Magento functionality to define and enable the module.

Module Specification

   XML File which describes module version and its dependencies on other modules.

Template Files

   PHTML files which take data from blocks and output HTML.

We’ll cover how Magento loads a page in more detail later.

Skins, Layouts and Templates

There is a lot of confusion over the terminology used for parts of a Magento design. If you’re used to splicing PDFs and putting the entire HTML in one place, you’ll need to adjust your thought process in order to understand Magento. What we think of as the program interface is known in Magento as a theme, which can be changed or switched out to provide a different user interface during development, or even while running the store. Using themes, it’s possible to create a holiday version of your website and display it to users only during a certain date range. You can also create multiple stores for different purposes and give each one a particular theme.

There are three parts to every theme, some of which we’ve already defined:

Skin

CSS, JS and image files used to style the site.

Layout

XML layout files collected from each module, used to generate blocks.

Templates

PHTML files from each module used to generate actual XHTML output.


So, magento uses layouts to determine which blocks will render templates. Then, the HTML that those templates render is output to a browser and formatted using the CSS, images and Javascript kept in the skin folder.

Magento Page Request Flow


Conclusion
Take a look through your Magento installation and try to identify all the different pieces that go into a page. Later, we’ll define the actual process of building a page, which should help you understand where everything fits. For now, try to use the right vocabulary for each concept and you’ll be on the right track.

Monday 3 October 2011

Import/Export in Magento


The import/export tool is very useful within Magento. Basically you can use the import/export tool to do mass imports of products. It makes it much easier if you would like to add 50 products all at once, you would just create a csv or xml file with the matching fields for the database, add your information and then use the import tool to import the products. You can retrieve a sample csv or xml file, but doing an export.

Doing an export is very easy, and allows you to export all of your products out of your website. You might want to do this, if you are moving your website or need to reinstall or upgrade your website, and need to get the products out.

Magento went one or more steps further than most systems. Effectively any import or export is a conversion. From one medium to another. From database to local file, from FTP server to database, from parsed HTML page to Excel spreadsheet, from Google Spreadsheet to catalog.

Basically, it boils down to loading data from one resource, applying unlimited alterations/reformatting, and saving it to another resource.
Welcome to the world of conversion.

Import/Export Concept
The logical steps are:
  • Load records from database
  • Convert internal identificators into human understandable text
  • Map database fields to our custom file headings (sku ⇒ Part Number)
  • Format data array as Excel XML
  • Save resulting text as local or remote file
This sequence of actions we call a Profile.
Here we have 4 categories of components:
  • Adapter (input/output)
  • Mapper (data value processing)
  • Parser (data format conversion)
  • Validator (data validation)
Adapters
Adapters are anything that can plug in to external resource. This may include:
  • Local files
  • FTP, SFTP servers
  • Database table
  • Soap services
  • Standard input/output
  • HTTP interface
  • HTML source
  • Google Spreadsheets
  • Custom resources (specialized db interface, cache repository, etc.)
Adapters can have 2 methods:
  • load – extract data from resource into internal container.
  • save – save data into resource.
Mappers
Mappers are for processing data without changing it’s format or structure. They’re useful for tasks such as mapping one field to another or apply formulas on values.
Mappers can run one method: map
Parsers
Parsers are for changing format of data. Examples:
  • CSV text ⇒ Grid array
  • Excel XML text ⇒ Grid array
  • Grid array ⇒ Product model collection
Parsers can have 2 methods:
  • parse – usually convert from more human readable data to machine friendly format
  • unparse – the opposite, into human readable format
You might notice that Parsers are separated from Adapters, when usually they are associated as one thing (export to CSV file).

Validators
Validators are created to make sure that conditions are met. The conditions can be applied to processed data or environment variables.
Validators can only validate