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.

If you try to read a value from a session that has not been set your Drupal user will be logged out.

Example:

sess_write('myValue',TRUE);
echo sess_read('myValue');

OK

echo sess_read('myValue');

NOT OK, user is logged out.

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!

I ended up writing a super simple module that overrides json_server and corrects the issues.

If you compare the two module’s contents you’ll see I only made a couple of really minor tweaks.

You can download it here.

Install

Download and extract.

Copy the module folder to /sites/all/modules or /sites/{preferred-site}/modules.

Navigate to Site Building -> Modules.

Scroll down to SpinOneSolutions -> JSON Server and Enable.

Hit Save

Developed on Drupal 6.16

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!

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!