Package the extension

First of all I would recommend reading the following wiki page;

• Packaging a Magento Extension in 1.5+

Note – If your planning to upload your module to Magento Connect ensure the package name and the name you enter on Magento Connect match

Installing a module from a local package

Internally Magento uses a localised and enhanced version of Pear to manage packages and to distribute and install extensions. Since version 1.4.* the internal pear script has been renamed to mage. In order to use the mage script to run any of the commands it provides you first need to ensure that the executable bit is set for your user.

$ sudo chmod 775 ./mage

Once your user has permission to execute this script you can run it without any arguments to see a full list of commands;

$ ./mage

This will list all of the available commands. You can use this script to install remote extensions from Magento Connect or to install local packages such as the one you have just built. To install the local package you need to use the following command, changing the path and package name for the extension to the location of your files.

$ ./mage install-file var/connect/PackageName-0.1.12.tgz

Thats it your done… Or at least you should be. If you are testing the package in the version of Magento you used to build the package remember to remove the original files first or you will get a bunch of errors. The error output is generally very helpful, simply do what is suggested and try the install again.

Related Articles

• March 15, 2011 -- Testing Magento Checkout
• February 9, 2011 -- MageTool Update v0.3.0
• October 10, 2010 -- Magento command line tools MageTool
• July 29, 2009 -- How to: Magento eCommerce help and tutorials

Using Mage-Test you can easily create integration tests for the checkout process. This will allow you to ensure that your store still functions correctly after you have made any modifications.

Automated Integration Test

The example test method below is run within a Mage-Test controller test case.

    /**
     * @author Alistair Stead
     * @test
     */
    public function magentoCheckoutIntegrationTest()
    {
        // Add the product to the basket
        $this->request->setMethod('POST')
            ->setPost(
                array(
                    'product' => '16',
                    'related_product' => '',
                    'qty' => '1'
                )
            );
        // Set an initial cookie so that the Magento cookie validation passes
        $this->request->setCookie('mage-test', true);
        $this->dispatch('/checkout/cart/add/');
        $this->assertResponseCode('302', '/checkout/cart/add/ has not redirected to the cart');
        $this->assertRedirectRegex("/^.*checkout.*$/", 'We are not directed to the checkout as expected');
        $this->reset();

        // Set the checkout as guest
        $this->request->setMethod('POST')
            ->setPost(
                array(
                    'method' => 'guest'
                )
            );
        $this->dispatch('/checkout/onepage/saveMethod/');
        $this->assertResponseCode('200', '/checkout/onepage/saveMethod/ has not responded as expected');
        $this->reset();

        // Save billing address
        $this->request->setMethod('POST')
            ->setPost(
                array(
                    'billing' => array(
                        'address_id' => '',
                        'firstname' => 'Authorize',
                        'lastname' => 'Capture',
                        'company' => '',
                        'email' => 'user@mage-test.co.uk',
                        'street' => array('Flat 14b', 'Baker Street'),
                        'city' => 'London',
                        'region_id' => '',
                        'postcode' => 'W1B OW3',
                        'country_id' => 'GB',
                        'telephone' => '+44 1234 123456',
                        'fax' => '+44 1234 123456',
                        'customer_password' => '',
                        'confirm_password' => '',
                        'save_in_address_book' => '1',
                        'use_for_shipping' => '1'
                    )
                )
            );
        $this->dispatch('/checkout/onepage/saveBilling/');
        $this->assertResponseCode('200', '/checkout/onepage/saveBilling/ has not responded as expected');
        $this->reset();

        // Set shipping method
        $this->request->setMethod('POST')
            ->setPost(
                array(
                    'shipping_method' => 'flatrate_flatrate'
                )
            );
        $this->dispatch('/checkout/onepage/saveShippingMethod/');
        $this->assertResponseCode('200', '/checkout/onepage/saveShippingMethod/ has not responded as expected');
        $this->reset();

        // Save payment
        $this->request->setMethod('POST')
            ->setPost(
                array(
                    'payment' => array(
                        'method' => 'paypal_direct',
                        'cc_type' => 'SM',
                        'cc_number' => 'XXXXXXXXXXXXXXX',
                        'cc_exp_month' => '1',
                        'cc_exp_year' => (date('Y') + 6),
                        'cc_cid' => '444',
                        'cc_ss_issue' => '1',
                        'cc_ss_start_month' => '1',
                        'cc_ss_start_year' => (date('Y') - 2)
                    )
                )
            );
        $this->dispatch('/checkout/onepage/savePayment/');
        $this->assertResponseCode('200', '/checkout/onepage/savePayment/ has not responded as expected');
        $this->reset();

        // Save order
        $this->request->setMethod('POST')
            ->setPost(
                array(
                    'payment' => array(
                        'method' => 'paypal_direct',
                        'cc_type' => 'SM',
                        'cc_number' => 'XXXXXXXXXXXXXXX',
                        'cc_exp_month' => '1',
                        'cc_exp_year' => (date('Y') + 6),
                        'cc_cid' => '444',
                        'cc_ss_issue' => '1',
                        'cc_ss_start_month' => '1',
                        'cc_ss_start_year' => (date('Y') - 2)
                    )
                )
            );
        $this->dispatch('/checkout/onepage/saveOrder/');
        $this->assertResponseCode('200', '/checkout/onepage/saveOrder/ has not responded as expected');
        // Decode the JSON response so that we can evaluate the success
        $data = json_decode($this->response->getBody());
        $this->assertTrue(
            $data->success,
            "Unexpected status expected result :: {$data->error_messages}"
        );
    }

You can use a PHPUnit data provider to supply a set of data fixtures to be used for credit card numbers, address information and other values. Using a data provider you can test for not only the successful checkout but also the error handling within the checkout process.

Related Articles

• March 26, 2011 -- Package and Install your latest Magento 1.5+ extension
• February 9, 2011 -- MageTool Update v0.3.0
• October 10, 2010 -- Magento command line tools MageTool
• July 29, 2009 -- How to: Magento eCommerce help and tutorials

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

YAHOO.util.Event.addListener(forms, 'submit', this._onFormSubmit, this);

_onFormSubmit: function(e, o)
{
  YAHOO>util.Event.preventDefault(e);
  // Set the form
  YAHOO.util.Connect.setForm(e.currentTarget);
  // Configure the callback object
  callBackObj = {
    success: o._loadRemoteFormSubmissionTemplateComplete,
    failure: o._loadRemoteFormSubmissionTemplateFailed,
    argument: {
      objType: objType, 
      region: regionObj,  
      mode: submitbutton.value}
  }
  // Make the request
  YAHOO.util.Connect.asyncRequest('POST', e.currentTarget.action, callBackObj);
}

With non multi-part forms you can hijack the submit event of the form and create an asynchronous request. However once you try with multi-part data no matter how you set this up and attempt to cancel the form submit action the form will still make an HTTP request in the main window.

The YUI Multi-Part Data Solution

The solution is very simple once you find it but it is easy to overlook! In order to use YUI connect to create an asynchronous request you must remove the ‘submit’ button and replace it with a ‘button’ then assign it an eventListener that will create the asyncRequest.

var alternateButton = document.getElementById('alternateButtonId')
YAHOO.util.Event.addListener(alternateButton, 'click', this._onFormSubmit, this);

_onFormSubmit: function(e, o)
{
  YAHOO.util.Event.preventDefault(e);
  // Set the form
  YAHOO.util.Connect.setForm(e.currentTarget);
  // Configure the callback object
  callBackObj = {
    success: o._loadRemoteFormSubmissionTemplateComplete,
    failure: o._loadRemoteFormSubmissionTemplateFailed,
    argument: {
      objType: objType, 
      region: regionObj,  
      mode: submitbutton.value}
  }
  // Make the request
  YAHOO.util.Connect.asyncRequest('POST', e.currentTarget.action, callBackObj);
}

When trying to use multi-part data YUI Connection Manager will create an iframe in the document that your form will submit the data to. If you try and use the submit handler YUI currently does not change the target value of the submit event.

The YUI examples do all show the use of alternate buttons rather than a standard submit button however it can be easily overlooked. I hope this helps someone!

Related Articles

• No Related Post

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

I don’t think I’m alone in the fact that over the past twelve months I have been learning Cocoa specifically Cocoa Touch for the iPhone. Apps and tutorials will follow! However I have also been looking at Cappuccino (http://cappuccino.org/) a direct port of Cocoa to JavaScript. The intention of Cocoa and Cappuccino is to make the development of applications a quick, simple and fun exercise, however if like me you are approaching this from a web development standpoint those first steps can be a little hard.

However I have found a set of resources that will be invaluable if you too are trying to get to grips with Cocoa or Cappuccino.

Cocoa & Objective-C

Cocoa is an Object Orientated MVC framework build in Objective-C a superset of C. It is the framework used to develop the native applications for Mac and the iPhone. It is a well proven framework created and supported by Apple with a vast developer community.

Cappuccino & Objective-J

Cappuccino is and Object Orientated MVC framework built in Objective-J a superset of JavaScript. It is a direct port of Cocoa by the guys behind (http://www.280north.com/). It runs directly in any JavaScript enabled web browser. Cappuccino has been used in a number of applications such as:

• http://280slides.com/
• http://almost.at/

Where do you start?

Cocoa has vast amounts of very very high quality documentation on the Apple site (http://developer.apple.com/) however it is not the most accessible read. It is amazing once you have made those first steps but there are not many step by step tutorials or lesson based examples. However after a lot of searching and reading I have found some great starting points:

• http://andymatuschak.org/articles/2007/09/09/getting-started-with-cocoa-a-friendlier-approach/
• http://cocoadevcentral.com/
• http://www.teachmecocoa.com/

Cappuccino when compared to Cocoa is in it’s infancy. As such the documentation is not as complete, however you can transfer a lot of knowledge from the Cocoa documentation. Again here is a list of the resources I have found when learning Cappuccino:

• http://www.littletreesoftware.com/blog/
• http://cappuccino.org/learn/tutorials/
• http://cappuccino.org/learn/documentation/

Conclusion

These frameworks can be very daunting at first and the syntax alien but after I while using them they can be a very intuitive and expressive languages. The Cocoa community is very large with a wealth of knowledge however it appears that not may developers pass on the experiences online so it can be very hard to find good examples online. Cappuccino opens the door for existing Cocoa developers to move to building for the web. This hopefully will lead to much more content being made available for people new to the language.

I have found the learning Cappuccino and Cocoa together very helpful and the examples I have found transfer very well. I look forward to seeing the rich web applications that will come out of the meeting of these two communities and technologies.

Related Articles

• No Related Post