MageTool v0.3.0 now includes:

• Improved feedback when running commands for mage-core-resource
• Added commands to query and run the Magento indexer
• Added commands to query and run the Magento compiler
• Improved mage-core-cache commands
• Added functionality to run individual module setup classes directly
• Added functionality to dispatch Magento events to test your observers

All of these commands are intended to make development of Magento extensions easier and more streamlined. If you have feature requests please let me know. Or if you wish feel free to fork the project on GitHub and add the command that you need.

If you find and bugs with MageTool please raise a ticket on GitHub.

Related Articles

• October 10, 2010 -- Magento command line tools MageTool
• March 26, 2011 -- Package and Install your latest Magento 1.5+ extension
• March 15, 2011 -- Testing Magento Checkout
• July 29, 2009 -- How to: Magento eCommerce help and tutorials

Many development frameworks or other open source projects have tool that can be used by developers to issue commands quickly and easily. Magento however does not have any built in tools to improve the development workflow. This is where MageTool fits in!

MageTool

How can MageTool help? Well hopefully in a number of ways. MageTool extends the existing Zend Framework command line tool zf, adding new commands that are specific to Magento development workflow. Rather then navigating the Magento admin system to clear cache or the enable or disable caching you can issue a simple command in your terminal window and achieve the same results. You can also modify the Magento configuration quickly or issue commands that will selectively update many configuration values.

In my standard development practices I maintain a number of Magento installs on different servers. These are used for Development, Staging and UAT each using different domains to access the stores. This means however that I often need to move databases between servers, resulting in the ‘base_url’ configuration being incorrect. This can be easily updated if you have database access and is fairly simple if you only have a couple of sites setup. However if you have more sites setup this can become very very difficult to maintain and calls into question the idea of working with many environment servers during development.

MageTool can help again in any situation where you need to move a Magento install and then update the ‘base_url’ configuration. You can construct a command that will quickly and easily update all URLs in the Magento config.

Install

First install ZF:

sudo pear channel-discover pear.zfcampus.org
sudo pear install zfcampus/zf

Then install MageTool:

sudo pear channel-discover pear.magetool.co.uk
sudo pear install magetool/magetool

Once you have installed ZF and MageTool you will need to create configuration for your user by creating the following file:

vim ~/.zf.ini

Add the following lines to load the additional MageTool commands making them available to zf:

basicloader.classes.1 = "MageTool_Tool_MageApp_Provider_Manifest"
basicloader.classes.2 = "MageTool_Tool_MageExtension_Provider_Manifest"

After the install has completed successfully if you run zf you will see the additional commands available for Magento.

 MageAdminUser
    zf show mage-admin-user
    zf create mage-admin-user username email password firstname[=Admin] lastname[=User]

  MageCoreCache
    zf clear mage-core-cache
    zf enable mage-core-cache
    zf disable mage-core-cache

  MageCoreResource
    zf show mage-core-resource
    zf delete mage-core-resource path

  MageCoreConfig
    zf show mage-core-config path scope
    zf set mage-core-config path scope value
    zf replace mage-core-config match value path scope

  MageApp
    zf version mage-app

  MageExtension
    zf create mage-extension code-pool vendor-name extension-name

Example Usage

Cache

To clear the entire Magento cache simply run the following command from within the Magento project root directory:

zf clear mage-core-cache

To disable the entire Magento cache:

zf disable mage-core-cache

Core Config

MageTool provides commands to show existing configuration values and to set their values. It also has an additional command that can be used to perform a str_replace on the config values. This can be used if you have moved the database from another server with a different domain to update the config values in a single command:

zf replace mage-core-config --match www.current-domain.com --value shop.new-domain.co.uk

This will update all the config value that include the string “www.current-domain.com” and substitute it for “shop.new-domain.co.uk”. This can also be further refined to only affect specific config paths or scopes.

Core Resource

During the development of a new extension you sometimes need to remove the resource from the internal registry to force it to re-run the install scripts. MageTool can help you first see which versions of each extensions are installed:

zf show mage-core-resource --code mage_log

You can also remove specific entries:

zf delete mage-core-resource --code mage_log

Admin User

If you inherit a Magento project you may need to create a new admin user to gain access to the system. MageTool can list existing admin users and email addresses or it can create a new user for you to use.

zf create mage-admin-user --username newadmin --email newadmin@project.com --password newpassword

Roadmap

I plan to add additional functionality to create skeleton files for new extensions or themes, removing the repetitive creation of directories and configuration files when creating new extension.

If you have additional suggestions please let me know or alternatively you can fork the MageTool project on github and add the commands before sending me a pull request.

Feedback and Bugs

If you have any problems using MageTool or if you have any feedback or suggestions please submit them here.

Related Articles

• February 9, 2011 -- MageTool Update v0.3.0
• March 26, 2011 -- Package and Install your latest Magento 1.5+ extension
• March 15, 2011 -- Testing Magento Checkout
• July 29, 2009 -- How to: Magento eCommerce help and tutorials

In a previous post I described some of the reasons why you would want to store your session data in an alternate location to temporary files on your server. I explained the setup of database session storage using Doctrine and how this would allow you to take advantage of storing session data in a database. However depending upon your application requirements storing your session data in a database may cause excessive load on you database. You could of course use a separate dedicated database server to store your session data. However there is an alternate setup that will allow you to centralise your session storage ready for horizontal scaling of your hosting e.g. adding additional web servers.

symfony provides a very easy way for you to configure your application to use a number of alternate session storage strategies. In this article I will explain the steps needed to setup your application to use first APC as your session storage and then Memcache. Both of these strategies result in the session data being stored in volatile memory on your server and a cookie is stored on the client to maintain reference to the session data. You can set the lifetime of the cookie to control your session timeout.

Install APC and Memcached modules

First we need to ensure that your server has the required packages installed. I am using Ubuntu 9.04 in this example but the packages are available for your preferred linux distro. To install the required packages run the following commands.

Install the required PHP modules and the correct version of apache to successfully install APC, then install the Pecl APC module.

sudo apt-get install php5-dev php-pear apache2-threaded-dev
sudo pecl install apc

Install memcache

sudo apt-get install memcached

Configure APC session storage

Once you have your server setup with the required packages you need to configure symfony to use your preferred session storage strategy. To do this you simply need to modify the factories.yml file for you application. You need to modify the section of the factories.yml that defines your application storage strategy e.g.

Amend your factories.yml to include the following settings then change the parameters to reflect you setup such as the domain and session name.

all:
  storage:
    class: sfCacheSessionStorage
    param:
      session_name: sfproject #[required] name of session to use
      session_cookie_path: / #[required] cookie path
      session_cookie_domain: example.com #[required] cookie domain
      session_cookie_lifetime: +30 days #[required] liftime of cookie
      session_cookie_secure: false #[required] send only if secure connection
      session_cookie_http_only: true #[required] accessible only via http protocol
      cache: 
        class: sfAPCCache #[required] define the cache strategy
        param: ~ #[required] this empty key is required or you will get warnings

Once you have made this change clear the symfony cache and try your application. You will not see any noticeable difference unless you check the symfony toolbar and look for the additional cookie stored on the client.

This example defines the use of sfAPCCache as the session storage strategy. APC stores the session data in memory on your web server making it quicker to access than reading a file or database record.

Configure Memcache session storage

To setup memcache session storage it is almost as simple. Amend your factories.yml to include the following settings then change the parameters to reflect your setup including any specific values for your memcache server if you set it up differently.

all:
  storage:
    class: sfCacheSessionStorage
    param:
      session_name: sfproject #[required] name of session to use
      session_cookie_path: / #[required] cookie path
      session_cookie_domain: example.com #[required] cookie domain
      session_cookie_lifetime: +30 days #[required] liftime of cookie
      session_cookie_secure: false #[required] send only if secure connection
      session_cookie_http_only: true #[required] accessible only via http protocol
      cache: 
        class: sfMemcacheCache #[required] define the cache strategy
        param:
          servers: # Array of servers
            localserver:
              host: localhost # hostname or IP of mamcache server
              port: 11211 # default memcache port

Once you have made this change clear your symfony cache and test your application.

Memcache is a volatile storage strategy very similar to RAM in you PC or Mac. It is very quick to access as the session data is held in the server memory rather than in a file or database. Memcache can also be centralised onto a dedicated memcache server allowing your application to be scaled. The example above uses localhost as the memcache server but the host value of the configured server could be modified to be an alternate dedicated memcache server.

I will be running some performance tests using these strategies and also compare the default file based session storage and also the database session storage strategy. If you have already run these tests I would be keen to see your results.

I hope these examples prove useful. If you have any queries or questions please leave a comment.

Related Articles

• November 25, 2009 -- symfony Doctrine database session storage
• October 8, 2009 -- Propel doUpdate update multiple records in a single statement

Why use database session management?

Sessions allow you maintain persistence within PHP applications. With every HTTP request a PHP application must re-assign every variable and object needed in your application. Sessions allow you to store data that is required to persist past each HTTP request allowing it to be easily retrieved and used.

Sessions are commonly used when  creating a secure application, used to store the state of a user e.g. if they are logged in or credentials to control access to content.

By storing session data in a database table you are able to create an application interface that will show information about the users that are logged in. This for example could show the number of users logged into the application or show administrators who is logged in.

If you  need to scale your application by adding more than one server, saving your session data in temporary files can lead to major problems. By using database storage you can optimise and unify the session storage, ensuring that session data is always available and consistent.

Obviously there are other solutions for scalable session storage such as APC or MemCache but these solutions are for another post.

How to setup Doctrine database session storage

You first need to add a table to you database schema that will be used to store your session data. Although you can create this table manually, adding it to your scheme also created the model classes that you can later use to interact with the table data.

Session:
  columns:
    id: { type: string(32), primary: true, notnull: true }
    data: { type: string(4000), notnull: true }
    time: { type: integer(4), notnull: true }

Once you have added the table to your schema you can build your model and database:

./symfony doctrine:build-all

You then need to configure your symfony application to use this table to store all session data. To do this you need to modify the factories.yml file for your application. Update your file to include the following lines:

all:
  storage:
    class: sfPDOSessionStorage
    param:
      db_table: session # Name of the table storing the sessions
      db_id_col: id # The primary key column
      db_data_col: data # The column where the session data will be stored
      db_time_col: time # The column where the timestamp of the session will be stored
      database: doctrine # Name of the database connection to use

Once you have modifies your factories.yml file you will need to clear the symfony cache. After that your application should run exactly as it did before except that your users session data will be stored in the database table.

The data column stores all the session data in a serialised form this is deserialized each time a user requests the data. There are many uses for this type of session storage and I hope this brief explanation helps you.

Subscribe to my RSS feed or follow me on twitter to find out about setting up symfony to use APC or MemCache session storage.

Related Articles

• November 30, 2009 -- symfony APC cache and Memcache session storage
• October 8, 2009 -- Propel doUpdate update multiple records in a single statement

This task is simple in SQL but after a while using any abstraction layer you may find like me you forget about the simple solutions as you spend you day working with complex objects and trying to hydrate custom objects. Blah blah blah…

The complex solution to a simple problem:

// Obtain the connection configured
$conn = Propel::getConnection(YourObjectPeer::DATABASE_NAME);
// Create a Criteria object that will select the correct rows from the database
$selectCriteria = new Criteria();
$selectCriteria->add(YourObjectPeer::COLUMB_TO_SELECT, 'value_to_match');
// Create a Criteria object includes the value you want to set
$updateCriteria = new Criteria();
$updateCriteria->add(YourObjectPeer::COLUMB_TO_CHANGE, 'value_to_be_set');
// Execute the query
BasePeer::doUpdate($selectCriteria, $updateCriteria, $conn);

Thats it! I hope it helps…

Related Articles

• November 30, 2009 -- symfony APC cache and Memcache session storage
• November 25, 2009 -- symfony Doctrine database session storage

Magento is an Open Source eCommerce platform developed using the Zend Framework by Varien. It is a fabulously customizable and extendible platform that once mastered can allow you to develop feature rich eCommerce solutions for your clients quickly and effectively. However for some mastering the Magento platform may not be that easy.

Magento uses common design patterns such as MVC, Application Controller and Two Step View to structure the application and provide mechanisms to extend and override the functionality and presentation. The platform has a huge number of files and directories that can cause confusion for newcomers to the platform. However this extended folder structure clearly defines where the platforms core files exist and where you can place your custom code and modules. Allowing you to extend the platform without modifying the core and breaking the upgrade process.

However daunting the platform appears or skeptical you may be due to the unfamiliar concepts, invest a small amount of time with the platform and it will soon start to payoff. This list of tutorials and resources will help you get up to speed quickly.

Magento eCommerce Tutorials and Resources

I have compiled the following list of resources that have helped me while developing for the Magento platform.

Developing Themes

• Learning to Design and Code for Magento Themes
• Designer’s Guide to Magento
• Configuring Templates, Adding a Product Grid in Magento
• Magento Template Advices

Custom Code and Modules

• Writing a custom module in Magento, detailed walktrough
• How To Write Magento Custom Module: Cash On Delivery Payment Method
• Magento Design and Magento Development blog
• snippi | MAGENTO CODE SNIPPETS
• Create Payment Method Module
• HOWTO: Repackageable custom extension development in magento

API Documentation

• Magento Documentation (phpdoc)

Tips and Advice

• MageTips
• Top 3 mistakes by Magento beginners

Related Articles

• March 26, 2011 -- Package and Install your latest Magento 1.5+ extension
• March 15, 2011 -- Testing Magento Checkout
• February 9, 2011 -- MageTool Update v0.3.0
• October 10, 2010 -- Magento command line tools MageTool