Turns out I had done it before, but I’ve always used the built in Magento Form widgets, never specified a custom .phtml template and actually tried to write the Form code by hand. It’s a little more tricky than I anticipated, but we struggled through it and finally found the catch.

The “catch”, as it were, is that you have to send a hidden “form_key”. This lets Magento know that you are who you say you are and not some spoofer posting malicious code to your backend.  Let’s get started.

Let’s presume that I’ve got a Module Spinonesolutions_Helloworld in it I’m going to make a block:

/app/code/local/Spinonesolutions/Helloworld/Block/Adminhtml/Adminform.php

class Spinonesolutions_Helloworld_Block_Adminhtml_Adminform extends Mage_Adminhtml_Block_Template {
public function __construct() {
    parent::__construct();
    $this->setTemplate('helloworld/form.phtml');
    $this->setFormAction(Mage::getUrl('*/*/new'));
  }
}

It’s easily seen that I’m referencing a .phtml template within my Block for the presentation so let’s make that file as well:

/app/design/adminhtml/default/default/template/hellworld/form.phtml

<form action="<? echo $this->getFormAction(); ?>" method="POST">
<input type="text" id="var1" name="var1" />
<input type="submit" id="submit" name="submit" />
</form>

Lastly we need a Controller to handle the POST and to render our Block:

/app/code/local/Spinonesolutions/Helloworld/controllers/Adminhtml/AdminformController.php

class Spinonesolutions_Helloworld_Adminhtml_AdminformController extends Mage_Adminhtml_Controller_Action {

public function indexAction() {
  $this->loadLayout();
  $block = $this->getLayout()->createBlock('spinonesolutions_helloworld/adminhtml_adminform','admin_form');
  $this->getLayout()->getBlock('content')->append($block);
  $this->renderLayout();
}

public function newAction() {
  die('here I am!');
}
}

OK, that’s it for the architecture.  Let’s wire it all up with some XML in config.xml.  Note this is partial, not a full module definition:

<blocks>
<spinonesolutions_helloworld>
<class>Spinonesolutions_Helloworld_Block</class>
</spinonesolutions_helloworld>
</blocks>
<admin>
<routers>

<adminhtml>
<args>
<modules>
<Spinonesolutions_Helloworld before="Mage_Adminhtml">Spinonesolutions_Helloworld_Adminhtml</Spinonesolutions_Helloworld>
</modules>
</args>
</adminhtml>
</routers>
</admin>

Now, if you visit */admin/adminform/index you should see your super simple Form.  If you hit submit your Form will certainly post, but instead of seeing the die output you’ll be redirected to the Dashboard.  This because we haven’t sent through the authentication required by Magento’s internal routing system that will validate our form.  Let’s change form.phtml so that we can POST successfully.

<form action="<? echo $this->getFormAction(); ?>" method="POST">
<input type="hidden" name="form_key" value="<? echo $this->getFormKey(); ?>" />
<input type="text" id="var1" name="var1" />
<input type="submit" id="submit" name="submit" />
</form>

That’s all there is to it!  Notice the “form_key” hidden variable.  That’s the key to submitting Forms in the Magento admin.

Unlike just about every other article on this site, for this one we’re going to be considering the folder /lib.  Note that this folder is NOT within local, but resident in the root.  As such changes here should be put within their own sub-folders so that they too will survive an upgrade.

It’s really quite easy to create your class, just follow the usual Magento naming conventions. I’m going to create Spinonesolutions_Devel_FirePHP so all I do is create the file: /lib/Spinonesolutions/Devel/FirePHP.php.  Note the similarity to Model naming.

In here I create my class definition:

<?php
class Spinonesolutions_Devel_FirePHP {
  public static function send($var, $label = "DEBUG", $style = "LOG") {
    if (Mage::getIsDeveloperMode()) {
      $request = new Zend_Controller_Request_Http();
      $response = new Zend_Controller_Response_Http();
      $channel = Zend_Wildfire_Channel_HttpHeaders::getInstance();
      $channel->setRequest($request);
      $channel->setResponse($response);

      /*
      * Start output buffering
      */
      ob_start();

      Zend_Wildfire_Plugin_FirePhp::send($var, $label, $style);

      /*
      Style     Description
      LOG     Displays a plain log message
      INFO     Displays an info log message
      WARN     Displays a warning log message
      ERROR     Displays an error log message that increments Firebug?s error count
      TRACE     Displays a log message with an expandable stack trace
      EXCEPTION     Displays an error long message with an expandable stack trace
      TABLE     Displays a log message with an expandable table
      */

      /*
      * Flush log data to browser
      */
      $channel->flush();
      $response->sendHeaders();
    } else {
      return null;
    }
  }
}

Now I can call Spinonesolutions_Devel_FirePHP:send() anywhere in my project.  Sweet!

The time delta that you set here will be the minimum delta for your Magento jobs.  IE: If your server’s cron  requests /cron.php every ten minutes and you create a cron job within Magento to run every five minutes, you shouldn’t be surprised to see it running every ten minutes instead of every five.

This won’t be a huge deal for all of you who are administering your own box, but for those of you on a shared box; you’ll likely be limited to a certain minimum delta which you’ll want to be aware of.

Setting up a cron job is actually really simple so lets take a look.  The configuration lives in config.xml, which shouldn’t be a surprise for you module developers.  Using my default example module Spinonesolutions_Helloworld:

/app/code/local/Spinonesolutions/Helloworld/etc/config.xml (partial)

<config>
...
<crontab>
<jobs>
<spinonesolutions_helloworld>
<schedule><cron_expr>*/10 * * * *</cron_expr></schedule>
<run><model>spinonesolutions_helloworld/observer::foobar</model></run>
</spinonesolutions_helloworld>
</jobs>
</crontab>
...
</config>

You can do a Google search on cron schedules in order to figure that part out, it’s outside the scope of this article.  The only other piece that deserves explanation is the static method call between the run tag.  As you’d expect my example call is referencing Spinonesolutions_Helloworld_Model_Observer (/app/code/local/Spinonesolutions/Helloworld/Model/Observer.php). This file doesn’t need to contain anything except for a class definition and a static method.

/app/code/local/Spinonesolutions/Helloworld/Observer.php

<?php
class Spinonesolutions_Helloworld_Model_Observer {
  public static function foobar() {
  }
}

That’s it.  Your static method will now be called on the schedule that you set!

The Varien team has provided ways for your module to manage these stores automatically through the “setup” functionality.  Let’s check it out.

First, you have to let Magento know where your setup code is going to live and what version your module is currently at.  You do this in config.xml. As an example I’ll use a module called Helloworld.  You may recognize this Module from the first article.

/app/code/local/Spinonesolutions/Helloworld/etc/config.xml (partial)

<global>
...
<spinonesolutions_helloworld_setup>
<setup>
<module>Spinonesolutions_Helloworld</module>
</setup>
</spinonesolutions_helloworld_setup>
...
</global>

The setup tag is going to cause Magento to look for a folder within the module called ../sql/setup (/Spinonesolutions/Helloworld/sql/setup). We can change the name of the target folder by changing the tag.  Example: <foobar_setup></foobar_setup> would prompt Magento to look for ../sql/foobar_setup.

The files that fall within this folder need to follow a strict naming scheme:

mysql4-install-{version}.php

mysql4-upgrade-{versionFrom}-{versionTo}.php

What happens is that Magento will run each file, in succession, until it reaches the version number specified in your config.xml.

If you ever need to check to see what version of a module Magento THINKS is installed, browse your database for the table core_resource and scan the codes till you find your module’s code.

If you ever need to have Magento re-run your setup scripts, just remove the entry from core_resource and refresh; the module will then be “reinstalled”.

Now lets take a look at some common things to do in a install/upgrade script.  One of the best resources for figuring this stuff out is Varien’s own codebase.  If you go through some modules in ../core/Mage you’ll find all sorts of great material  to copy into your own module.

Install/Update Wrapper

../sql/setup/mysql4-install-1.0.0.php

<?php
$installer = $this;
/* @var $installer Mage_Core_Model_Resource_Setup */
$connection = $installer->getConnection();
/* @var $connection Varien_Db_Adapter_Pdo_Mysql */

$installer->startSetup();
YOUR CODE GOES HERE

$installer->endSetup();

DataBase Table

$installer->run("
DROP TABLE IF EXISTS {$installer->getTable('spinonesolutions_helloworld/foo')};
CREATE TABLE {$installer->getTable('spinonesolutions_helloworld/foo')} (
id int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
created_at DATETIME NOT NULL,
modified_at DATETIME NOT NULL,
store_id int(5) UNSIGNED NOT NULL,
PRIMARY KEY (id)
)
ENGINE = InnoDB;
");

Not much to explain other than the getTable function.  The parameter refers to config.xml -> global -> models -> {resourceModel} -> entities.

/app/code/local/Spinonesolutions/Helloworld/etc/config.xml (partial)

...
<global>
<models>
...
<spinonesolutions_helloworld>
<class>Spinonesolutions_Helloworld</class>
<resourceModel>spinonesolutions_helloworld_mysql4</resourceModel>
</spinonesolutions_helloworld>
<toms_bluehornet_mysql4>
<class>Spinonesolutions_Helloworld_Model_Mysql4</class>
<entities>
<foo><table>spinonesolutions_helloworld_foo</table></foo>
</entities>
</toms_bluehornet_mysql4>
...
</models>
</global>
...

New Attribute

$installer->addAttribute('catalog_product', 'is_recurring', array(
'group'             => 'Recurring Profile',
'type'              => 'int',
'backend'           => '',
'frontend'          => '',
'label'             => 'Enable Recurring Profile',
'note'              => 'Products with recurring profile participate in catalog as nominal items.',
'input'             => 'select',
'class'             => '',
'source'            => 'eav/entity_attribute_source_boolean',
'global'            => Mage_Catalog_Model_Resource_Eav_Attribute::SCOPE_GLOBAL,
'visible'           => true,
'required'          => false,
'user_defined'      => false,
'default'           => '',
'searchable'        => false,
'filterable'        => false,
'comparable'        => false,
'visible_on_front'  => false,
'unique'            => false,
'apply_to'          => 'simple,virtual',
'is_configurable'   => false
));

Mage_Eav_Model_Entity_Setup

Mage_Eav_Model_Entity_Setup has tons of useful methods to call from your setup script.  The installer itself is an object of type Mage_Catalog_Model_Resource_Eav_Mysql4_Setup which extends Mage_Eav_Model_Entity_Setup thus all the instance methods are available from $this or $installer if you use a wrapper like the one shown above.

Questions and comments welcome!

Widgets can basically be thought of as easily customizable blocks.  The main difference between standard blocks and widgets is that widgets can be added to CMS pages through the WYSIWYG editor and they can easily accept parameters, also defined through the WYSIWYG.  Thus a non-programmer can add quasi-dynamic content to their CMS pages, hurrah!

You should reference previous articles if you want more details about creating custom Modules and Blocks.

As an example I’m going to build a super simple slideshow widget called “Glider”.  It’s going to be a widget that takes four static block_id(s) as parameters and then displays each static block, in succession, as a slideshow.  If you let your imagination work a little you should be able to see some cool possibilities for such a thing, given that you extend it a little.

I’m using static blocks as the source material for each slide because this would allow a content manager to change out the content of a slide by either editing the static block that contains the content or by editing the block id being passed to the widget.  Either way it’s manageable through the interface.

Also note that the template (presentation layer) is going to be statically defined in this example, but you could easily make that a parameter and create multiple templates for the content manager to choose from!

Finally, I’ve used jQuery to build the actual slideshow.  I’m not going to go into very much detail about the presentation of the slideshow as that’s not really the focus of this article.  Feel free to write in if you want to see the details on how to implement jQuery (or any other script).

First let’s setup the Module:

/app/etc/modules/Spinonesolutions_WidgetGlider.xml

<?xml version="1.0"?>
 <config>
 <modules>
 <Spinonesolutions_WidgetGlider>
   <active>true</active>
   <codePool>local</codePool>
   <depends>
     <Mage_Cms />
   </depends>
 </Spinonesolutions_WidgetGlider>
 </modules>
 </config>

/app/code/local/Spinonesolutions/WidgetGlider/etc/config.xml

<?xml version="1.0"?>
 <config>
 <modules>
 <Spinonesolutions_WidgetGlider>
   <version>1.0.0</version>
 </Spinonesolutions_WidgetGlider>
 </modules>
 <global>
 <blocks>
   <spinonesolutions_widgetglider>
     <class>Spinonesolutions_WidgetGlider_Block</class>
   </spinonesolutions_widgetglider>
 </blocks>
 </global>
 </config>

OK!  The next thing we need to do is define our widget’s interface.  To do that we create a widget.xml file inside our module’s “etc” folder.

/app/code/local/Spinonesolutions/WidgetGlider/etc/widget.xml

<?xml version="1.0"?>
<widgets>
<glider type="spinonesolutions_widgetglider/glider">
   <name>SpinoneSolutions: Glider</name>
   <description>Displays the given HTML Sections in a Glider Slideshow</description>
   <parameters>
     <section1>
       <required>0</required>
       <visible>1</visible>
       <label>Section1</label>
       <type>text</type>
     </section1>
     <section2>
       <required>0</required>
       <visible>1</visible>
       <label>Section2</label>
       <type>text</type>
     </section2>
     <section3>
       <required>0</required>
       <visible>1</visible>
       <label>Section3</label>
       <type>text</type>
     </section3>
     <section4>
       <required>0</required>
       <visible>1</visible>
       <label>Section4</label>
       <type>text</type>
     </section4>
     <template>
       <visible>0</visible>
       <value>widgetglider/banner.phtml</value>
     </template>
   </parameters>
</glider>
</widgets>

You can define any number of widgets in here.  We’re only creating one so I’ve only got a single entry, glider.

The type attribute tells Magento what class to use when instantiating objects.  I’ve set it as spinonesolutions_widgetglider/glider.  If you go back and inspect the config.xml and remember your Magento naming conventions you can surmise that this is going to cause Magento to try and instantiate an object of type Spinonesolutions_WidgetGlider_Block_Glider.  That class doesn’t exist yet so we should create it.

/app/code/local/Spinonesolutions/WidgetGlider/Block/Glider.php

<?php
class Spinonesolutions_WidgetGlider_Block_Glider extends Mage_Core_Block_Template
implements Mage_Widget_Block_Interface {
  const MAXSECTIONS = 4;
  public $sectionArr = array();

  protected function _construct() {
    parent::_construct();
  }

  protected function _toHtml() {
    for ($i=1;$i <= self::MAXSECTIONS;$i++) {
      if ($this->getData("section$i")) {
        $blockHTML = $this->getLayout()->createBlock('cms/block')->setBlockId($this->getData("section$i"))->toHtml();
        $this->sectionArr[$i] = $blockHTML;
      }
    }
    return parent::_toHtml();
  }
}

Let’s inspect the class from top to bottom.  The first thing to notice is that in the declaration it implements Mage_Widget_Block_Interface.  This is a requirement for Widgets.

Notice my constant MAXSECTIONS is set to 4, the same number of section parameters that I defined in widget.xml.  There’s probably some room for improvement here: one could probably figure out the number of parameters dynamically and then remove the constant.  That would make the widget more flexible for future uses.

I call the _construct function so that everything gets setup the way it’s supposed to.

Finally the real work gets done in _toHtml.  This function will be called automagically by Magento when it goes to render this object to the screen.

What I do is load up each block that gets passed into the widget and I stuff it’s HTML into an array element.  This way the widget can render any block, independently, by referencing a key in the array.

It’s not the classes job to do the rendering, that’s left to the presentation layer.  This class is just gathering everything that the presentation layer needs.

To move on with the tutorial we need to look back at our widget declaration in widget.xml.  I’m sure you noticed the last parameter template that I haven’t discussed yet.  Notice that the attribute visible is set to false.  What this parameter does is define the template that our widget is going to use for presentation.  My value is widgetglider/banner.phtml this template doesn’t exist by default so let’s create it.

/app/design/frontend/default/spinonesolutions/template/widgetglider/banner.phtml

<style>
.slideshow {
  position:relative;
}

.slideshow .items div {
  float:left;
  opacity:0.0;
  position:absolute;
  z-index:8;
}

.slideshow .items div.active {
  opacity:1.0;
  z-index:10;
}
</style>

<script>
function slideSwitch() {
  var active = jQuery('.slideshow .items .active');
  // use this to pull the images in the order they appear in the markup
  var next =  jQuery(active).next().length ? jQuery(active).next() : jQuery('.slideshow .items div:first');
  jQuery(next).css({opacity: 0.0})
  .addClass('active')
  .animate({opacity: 1.0}, 1000, function() {
    jQuery(active).removeClass('active');
  });

  jQuery(active).animate({opacity:0.0}, 1000, function(){
  });
}

// execute your scripts when the DOM is ready. this is mostly a good habit
jQuery('document').ready(function() {
  var active = jQuery('.slideshow .items .active');
  if ( active.length == 0 ) {
    active = jQuery('.slideshow .items div:first');
    active.addClass('active').animate({opacity: 1.0}, 1000);
  }

  jQuery(function() {
    setInterval( "slideSwitch()", 5000 );
  });
});
</script>
<div class="slideshow">
  <div class="items">
    <?php foreach($this->sectionArr as $key => $section) { ?>
    <div class="">
      <?php echo $section; ?>
    </div>
    <?php } ?>
  </div>
</div>

The first part of that path is determined by the theme that you’ve set in Configuration.

Inspecting this file the real takeaway is simply the foreach loop.  All it does it loop over the array that was defined in the Business Layer and output the HTML stored in each element.  The template file does all the presentation.

The reason for doing things this way is that one can easily envision some department manager coming to you and asking for another, different, presentation of the same data for some other location of your website.  Since you’ve done a good job of separating your layers all you have to do is make a new .phtml file, and then change the template parameter of your widget.xml file and viola, you’ve got a new presentation of your data.

That does it for the code, all we need to do now is build a little demo using the interface.

Load up the admin and navigate to CMS -> Static Blocks.  Create four static blocks and put an image file into each one.  If you hover your mouse over the row you’ll see the block_id.  Make note of these as you’ll need them for when you create the widget.  Mine are: 6,8,9,10.

Go to CMS -> Pages and create a new CMS page to hold the widget.  Alternatively you could add the widget to a preexisting page.  Switch to the Content Tab.  Click the add Widget icon to add your widget.

Choose your new widget from the dropdown menu.

Fill in the block_id(s) of your static blocks.

Hit Insert.

As a learning exercise click the “Show/HideEditor” button.

Notice what was generated!  It should be pretty similar to what’s in your widget.xml file.  As the smart and curious type the you are also realize that you can change these parameters right here.  Thus the widget.xml file serves a template for your widget, which can be customized later to suit your specific needs.

Ok, save your CMS page.  That’s it!

You can see my demo here.

As always, questions and comments welcomed!

Magento: Enterprise ver 1.6.0.0

block

Description
Outputs a virgin block or loads a defined block.

Parameters
type : Type of block to be created.
id : Id of block to be created.
output : The block instance method to call after creation.  If blank “toHtml()” will be called by default.
<parameter> : Any additional parameters will get key value pairs set in the block’s Data array.

Usage
{{block type=”cms/block”}}
Results in a virgin static block with no data.

{{block id=”myBlock”}}
Results in an instance of myBlock.

{{block id=”myBlock” param1=”foo” param2=”bar”}}
Results in an instance of myBlock with a data array containing key value pairs param1=>”foo” param2=>”bar”.

{{block id=”myBlock” output=”myMethod”}}
Results in an instance of myBlock after it has called member method myMethod.

Note that if you already HAVE a block with this particular ID than it will be loaded.  This is great if you want to include a static block into a CMS page or into another static block!  Just create the block in the CMS section of admin and use the ID that you set.

Any parameter that your block class is sensitive too will work as well.  For example:

{{block id=”myBlock” template=”customfolder/customTemplate.phtml”}}
Results in an instance of myBlock using a custom template.

layout

Description
Outputs the contents of the defined layout.

Parameters
area : The area to load.  If blank the layout’s default area will be used.
handle : The layout handle to load.
<parameter> : Any additional parameters will get key value pairs set in the layout’s Data array.

Usage
{{layout handle=”default”}}
Outputs the default layout handle.

skin

Description
Outputs the url for a resource in the current skin.

Parameters
url : The url to reference within the current skin directory.
<parameter> : Any additional parameters will be passed to the getSkinUrl() method.

Usage
{{skin url=”images/myimage.gif”}}
Outputs: http://www.mydomain.com/skin/frontend/default/default/images/myimage.gif
Note: This assumes the current theme and skin are default.

media

Description
Outputs the Base Media URL.

Parameters
url : The url to prefix with the base media url.

Usage
{{media url=”images/myimage.gif”}}
Outputs: http://www.mydomain.com/media/images/myimage.gif
Note: This assumes Base Media URL is set to http://www.mydomain.com/media (See Admin->Configuration->Web)

store

Description
Outputs the store specific Base URL.

Parameters
direct_url : The url to prefix with the Base URL.  Note this method does NOT assume internal routing.
url : The url to prefix with the Base URL.  Note this method DOES assume internal routing.
<parameter> : Any additional parameters will be passed to the getSkinUrl() method.

Usage
{{store direct_url=”images/myimage.gif”}}
Outputs: http://www.mydomain.com/images/myimage.gif

{{store url=”mens”}}
Outputs: http://www.mydomain.com/mens/

Note that the Base URL can be different in a multistore setup.

htmlescape

Parameters
var : The string to be html escaped.
allowed_tags : Tags to be allowed in the escaped string

Usage
{{htmlescape var=”<a href=’#'>Click Here</a>”}}
Outputs: <a href=’#'>Click Here</a>
Note: The string is escaped so that the browser does not interpret it as HTML, instead it’s displayed as a human readable string.

var

Description
Outputs template variables.

Parameters
variable : The variable being requested

Usage
{{var myVariable}
Outputs: Value stored in myVariable

protocol

Description
Outputs the proper protocol (HTTP or HTTPS) depending on current context OR outputs the desired url based on the current protocol.

Parameters
store : The desired store
url : The url to prefix with the proper protocol
http : The url to use if the current protocol is HTTP
https: The url to use if the current protocol is HTTPS

Usage
{{protocol url=”www.mydomain.com/images/checkout/cart.gif”}}
Outputs: http://www.mydomain.com/images/checkout/cart.gif IF current protocol is HTTP
Outputs: https://www.mydomain.com/images/checkout/cart.gif IF current protocol is HTTPS

{{protocol http=”http://unsecure.mydomain.com/images/checkout/cart.gif” https=”https://secure.mydomain.com/images/checkout/cart.gif”}}
Outputs: http://unsecure.mydomain.com/images/checkout/cart.gif IF current protocol is HTTP
Outputs: https://secure.mydomain.com/images/checkout/cart.gif IF current protocol is HTTPS

All of these directives are defined in Mage/Core/Model/Email/Template/Filter.php should you want to explore them further.

You want to override a Controller’s action with a custom action.

Magento Enterprise v1.6.0.0

The Solution:

I ran into some issues trying to override a controller’s action yesterday. I think it mainly stems from a version change, but at any rate here’s the “new” way to do it. This comes from a helpful post on the Magento forums.

In this example my custom modules’s namespace is “Spinonesolutions” and I’m going to override the createPostAction in Mage_Customer_AccountController.

Start by creating a bare bones custom module; if you don’t know how to do this check out Magento – Part I : Custom Module.

I’ve only got two files in my custom module; controllers/AccountController.php and etc/config.xml.

config.xml:

<?xml version="1.0" encoding="UTF-8"?>
<config>
<modules>
  <Spinonesolutions_Customer>
    <version>0.0.1</version>
  </Spinonesolutions_Customer>
</modules>
<frontend>
  <routers>
    <!-- This is the frontname to override
    EG: http://mydomainname.com/customer/  -->
    <customer>
      <args>
        <modules>
          <!-- Use the module Spinonesolutions_Customer BEFORE Mage_Customer -->
          <Spinonesolutions_Customer before="Mage_Customer">Spinonesolutions_Customer</Spinonesolutions_Customer>
        </modules>
      </args>
    </customer>
  </routers>
</frontend>
</config>

AccountController.php:

<?php
/**
* Override Customer AccountController
*
* Override the createPost action
*
* @category Mage
* @package Mage_Customer
* @author Will Wright
*/

/*Controllers aren't included automatically, so we include it here so that we can extend it*/
include_once("Mage/Customer/controllers/AccountController.php");
class Spinonesolutions_Customer_AccountController extends Mage_Customer_AccountController {
  public function createPostAction() {
    die('here');
  }
}

That’s it!  You should now have a working override.

You’ve enabled partial refunds in the Authorizenet Model, but it’s not refunding the proper amounts.  This is due to, in my view, a bug in the core which I’ll show you how to patch!

The Solution:

What you need to do is overload the refund method in the Authorizenet model.

Create a new model that extends the original Authorizenet model.  You’ll need to follow the general instructions for how to create a custom module if you don’t already know how to do so.

class Spinonesolutions_General_Model_Paygate_Authorizenet extends Mage_Paygate_Model_Authorizenet {
//Override Mage_Paygate_Model_Authorizenet

protected $_canRefund = true;

public function refund(Varien_Object $payment, $amount) {
  $error = false;
  if ($payment->getRefundTransactionId() && $amount>0) {
    $payment->setAnetTransType(self::REQUEST_TYPE_CREDIT);
    $request = $this->_buildRequest($payment, $amount);
    $request->setXTransId($payment->getRefundTransactionId());
    $result = $this->_postRequest($request);
    if ($result->getResponseCode()==self::RESPONSE_CODE_APPROVED) {
      $payment->setStatus(self::STATUS_SUCCESS);
    } else {
      $error = $result->getResponseReasonText();
    }
  } else {
    $error = Mage::helper('paygate')->__('Error in refunding the payment');
  }

  if ($error !== false) {
    Mage::throwException($error);
  }

  return $this;
}
}

Now all we need to do is let Magento know that we’ve got a custom model.  In config.xml add

<?xml version="1.0"?>
<config>
  <modules>
    <Spinonesolutions_General>
      <version>0.0.1</version>
    </Spinonesolutions_General>
  </modules>
  <global>
    <models>
      ...
      <paygate>
        <rewrite>
          <authorizenet>Imagistic_General_Model_Paygate_Authorizenet</authorizenet>
        </rewrite>
      </paygate>
      ...
    </models>
  </global>
</config>

That should do it!  Questions and comments welcome.

You’ve built a custom grid and the source collection has an ambiguous column in the where clause when applying a filter.

The Solution

I recently ran into this problem while I was building a custom grid.  The situation should be familiar to many of you.  I have a custom table storing addresses; for the region and country I store a region_id and country_id, respectively.  For display of the grid however I want to do a lookup to show the user the friendly names for both region and country.  To accomplish that I do an inner join on the original collection which yields the full dataset.

However, this also introduces a douplicate column into the collection which was causeing an ambigous column error in my SQL statement whenever I applied a filter (a WHERE clause).  Lets take a look at an example.

My tables:

retailer

• id
• street
• city
• postcode
• country_id
• region_id

directory_country_region

• region_id
• country_id
• code
• default_name

Now lets take a look at my _prepareCollection method.

protected function _prepareCollection() {
  $collection = Mage::getResourceModel('spinonesolutions_storelocator/retailer_collection');
  $collection->getSelect()
    ->join(array('dcr' => 'directory_country_region'),'dcr.region_id = main_table.region_id')
    ->reset(Zend_Db_Select::COLUMNS)
    ->columns(array('id','name','street','city','country_id'))
    ->columns(array('default_name'),'dcr');
  $this->setCollection($collection);
  return parent::_prepareCollection();
}

This will result in a collection containing all the data that I need for a friendly presentation.  However, if I want to filter by country_id (which I do!) then I’m going to get an ambiguous column error in my SQL if I simply add “WHERE country_id = ?”.  That’s because country_id is in both tables.

The solution is the “filter_index” property.  Here’s a snippet from _prepareColumns which generates the country column and uses filter_index.

$this->addColumn('country_id', array(
  'header' => Mage::helper('spinonesolutions_storelocator')->__('Country'),
  'width' => '100px',
  'index' => 'country_id',
  'filter_index' => 'main_table.country_id',
  'type' => 'country', ));

Now when the SQL statement is generated the ambiguous column error will be fixed since I’ve provided enough specificity.  Simple!

Questions and comments welcome!

You want to issue a refund, electronically, through your payment gateway from Magento.

The Solution:

By default, the community edition of Magento has refunds disabled in the Paygate Models.  In order to enable them you need to create a custom Model and overwrite a protected variable.  Refer to Part IV: Extending Models for more details on extending a Model.

First, lets take a look at the native Model so that you can understand what’s standing in the way.  I’m going to use the Authorize.net gateway as my example.

The top portion of Mage_Paygate_Model_Authorizenet (/Mage/Paygate/Model/Authorizenet.php)

class Mage_Paygate_Model_Authorizenet extends Mage_Payment_Model_Method_Cc
{
    const CGI_URL = 'https://secure.authorize.net/gateway/transact.dll';

    const REQUEST_METHOD_CC     = 'CC';
    const REQUEST_METHOD_ECHECK = 'ECHECK';

    const REQUEST_TYPE_AUTH_CAPTURE = 'AUTH_CAPTURE';
    const REQUEST_TYPE_AUTH_ONLY    = 'AUTH_ONLY';
    const REQUEST_TYPE_CAPTURE_ONLY = 'CAPTURE_ONLY';
    const REQUEST_TYPE_CREDIT       = 'CREDIT';
    const REQUEST_TYPE_VOID         = 'VOID';
    const REQUEST_TYPE_PRIOR_AUTH_CAPTURE = 'PRIOR_AUTH_CAPTURE';

    const ECHECK_ACCT_TYPE_CHECKING = 'CHECKING';
    const ECHECK_ACCT_TYPE_BUSINESS = 'BUSINESSCHECKING';
    const ECHECK_ACCT_TYPE_SAVINGS  = 'SAVINGS';

    const ECHECK_TRANS_TYPE_CCD = 'CCD';
    const ECHECK_TRANS_TYPE_PPD = 'PPD';
    const ECHECK_TRANS_TYPE_TEL = 'TEL';
    const ECHECK_TRANS_TYPE_WEB = 'WEB';

    const RESPONSE_DELIM_CHAR = ',';

    const RESPONSE_CODE_APPROVED = 1;
    const RESPONSE_CODE_DECLINED = 2;
    const RESPONSE_CODE_ERROR    = 3;
    const RESPONSE_CODE_HELD     = 4;

    protected $_code  = 'authorizenet';

    /**
     * Availability options
     */
    protected $_isGateway               = true;
    protected $_canAuthorize            = true;
    protected $_canCapture              = true;
    protected $_canCapturePartial       = false;
    protected $_canRefund               = false;
    protected $_canVoid                 = true;
    protected $_canUseInternal          = true;
    protected $_canUseCheckout          = true;
    protected $_canUseForMultishipping  = true;
    protected $_canSaveCc = false;

    protected $_allowCurrencyCode = array('USD');

The variable that we’re interested in is _canRefund.  The game plan is to create a custom Model that overrides Mage_Paygate_Model_Authorizenet and in that Model, override _canRefund.  If you’re thinking, why not just change false to true right here, right now!  Well my friend, you certainly could, but you’d certainly break your upgrade path too, check out Part IV: Extending Models and Part I: Custom Module.

I’m going to create the class: Spinonesolutions_Paygate_Model_Authorizenet (/local/Spineonesolutions/Paygate/Model/Authorizenet.php) and extend Mage_Paygate_Model_Authorizenet.  Now I just override _canRefund and we’re halfway there.

<?php
class Spinonesolutions_Paygate_Model_Authorizenet extends Mage_Paygate_Model_Authorizenet
{
 //Override Mage_Paygate_Model_Authorizenet
 protected $_canRefund = true;
}
?>

If you read Part IV: Extending Models you’ll know that there’s one last step, and that is to modify config.xml so that our custom Model overrides the native Model.

/Spinonesolutions/Paygate/etc/config.xml

<global>
  <models>
  ...
    <paygate>
      <rewrite>
        <authorizenet>Spinonesolutions_Paygate_Model_Authorizenet</authorizenet>
      </rewrite>
    </paygate>
  ...
  </models>
</global>

That should do it!  If you’ve got everything else setup correctly this should enable the Model to post refunds electronically to your gateway.  Of course, if you want to enable more than one gateway, or perhaps a gateway that’s not Authorize.net you can do that by just following the same steps above with the Model for the gateway of your choice.

As always, questions and comments are welcome!

Update: From Commenter Cindy

Afer doing the above (and not forgetting to fill in app/etc/modules/MyNameSpace_All.xml to activate the new module), I still wasn’t getting authorize.net to really refund the cc.

I found that I needed to add the CC to the request, and then add the actual amount to be refunded. Now issuing a credit memo on the invoice will cause authorize.net to issue a refund to the CC.

Also, it appears that the ‘refund’ button only shows up if you click credit memo from an invoice – it doesn’t show up if you click credit memo on an order (only ‘refund offline’ shows up then).

Anyway, this is the code to make this work for me:

//
// Override Mage_Paygate_Model_Authorizenet
//    enable online refunds via credit memos
//    enable partial refunds
//
class Sbr_Paygate_Model_Authorizenet extends Mage_Paygate_Model_Authorizenet {
  protected $_canCapturePartial = true;
  protected $_canRefund = true;

  //
  // override _buildRequest to fill in the CC number as it is required yet not set peviously
  //
  protected function _buildRequest (Varien_Object $payment) {
    if (($payment->getAnetTransMethod() == self::REQUEST_METHOD_CC) &&($payment->getCcLast4()))
      $payment->setCcNumber($payment->getCcLast4());
   
      return parent::_buildRequest($payment);
  }

  // Override refund in order to fill out the amount
  //
  public function refund(Varien_Object $payment, $amount) {
    $error = false;
    if ($payment->getRefundTransactionId() && $amount>0) {
      $payment->setAnetTransType(self::REQUEST_TYPE_CREDIT);
      $request = $this->_buildRequest($payment);

      // set the amount (beginning of changes)
      $order = $payment->getOrder();
      $request->setXAmount($amount,2);
      $request->setXCurrencyCode($order->getBaseCurrencyCode());
      // (end of changes)

      $request->setXTransId($payment->getRefundTransactionId());
      $result = $this->_postRequest($request);

      if ($result->getResponseCode() == self::RESPONSE_CODE_APPROVED) {
        $payment->setStatus(self::STATUS_SUCCESS);
      } else {
        $error = $result->getResponseReasonText();
      }
    } else {
      $error = Mage::helper(’paygate’)->__(’Error in refunding the payment’);
    }

    if ($error !== false) {
      Mage::throwException($error);
    }

    return $this;
}