$productIds = array_keys($_products->getItems());
$minimalPriceModel = Mage::getResourceModel('catalogindex/price');
$minimalPriceModel->setStoreId(Mage::app()->getStore()->getId());
$minimalPriceModel->setCustomerGroupId(
  Mage::getSingleton('customer/session')->getCustomerGroupId());
$minimalPrices = $minimalPriceModel->getMinimalPrices($productIds);
foreach ($minimalPrices as $row) {
  $item = $_products->getItemById($row['entity_id']);
  if ($item) {
    $item->setData('minimal_price', $row['value']);
    $item->setData('minimal_tax_class_id', $row['tax_class_id']);
  }
}

There you have it!

This module has been replaced with one that correctly updates the layered navigation counts. See the new version here.

Updated 7/3/09

The in-stock-only module now works properly when multiple websites are in use.

Updated 6/26/09

The in-stock-only module now works with configurable products.

Magento has several criteria for determining if an item should be visible in the store, but one of these is not whether or not the item is in stock. Magento can manage your stock and will set your stock status to “Out of Stock” for you, but what if you want these out of stock items to be hidden from the store.. automatically? Also, in my case I do not want to “disable” the item because the inventory management system will then ignore it. Turns out this was much more difficult to figure out than I expected it to be but the end solution was quite simple.

To hide all out of stock items from Magento’s storefront we are going to create a local module and call it “Lucky_InStockOnly”. This will be a very simple module, so get ready to copy and paste.

Every module needs a config file. Ours is very basic, here it is:

app/code/local/Lucky/InStockOnly/etc/config.xml

<?xml version="1.0"?>
<config>

<global>
  <models>
    <lucky_instockonly>
      <class>Lucky_InStockOnly_Model</class>
    </lucky_instockonly>
  </models>
</global>

<frontend>
  <events>
    <catalog_block_product_list_collection>
      <observers>
        <lucky_instockonly_list>
          <type>singleton</type>
          <class>lucky_instockonly/observer</class>
          <method>addInStockOnlyFilter</method>
        </lucky_instockonly_list>
      </observers>
    </catalog_block_product_list_collection>
  </events>
</frontend>

</config>

As you can see, we declare an event for the frontend that observes the “catalog_block_product_list_collection” event which is dispatched in Mage_Catalog_Block_Product_List in the _beforeToHtml() method. This _beforeToHtml method is called before the corresponding template code is loaded, and the next line after the dispatchEvent loads the collection at which point it is too late to add any further filters, so we’re just in time.

Next, we add the observer code:

app/code/local/Lucky/InStockOnly/Model/Observer.php

<?php

class Lucky_InStockOnly_Model_Observer {

  /**
   * Observes the catalog_block_product_list_collection event
   */
  public function addInStockOnlyFilter($observer){
    $observer->getEvent()->getCollection()
      ->joinField('stock_status','cataloginventory/stock_status','stock_status',
        'product_id=entity_id', array(
          'stock_status' => Mage_CatalogInventory_Model_Stock_Status::STATUS_IN_STOCK,
          'website_id' => Mage::app()->getWebsite()->getWebsiteId(),
        ))
    ;
  }
}

That’s it! That’s it? Like all things Magento, easy for a veteran, not so easy for anyone else; hence, this blog post. All that is left is to enable our module and we’re off!

app/etc/modules/Lucky_InStockOnly.xml

<config>
  <modules>
    <Lucky_InStockOnly>
      <active>true</active>
      <codePool>local</codePool>
    </Lucky_InStockOnly>
  </modules>
</config>

Last thing, you need to refresh your configuration cache so Magento will notice the new module. In the admin backend you can do that under System > Cache Management.

Enjoy!

While modules in Kohana can (and often do) have their own controllers and views, they sit below the application layer in terms of cascading priority, whereas the modules in Zend Framework sit above the main application layer. That is, if a module is specified in the route, classes will be searched for first in the module directory, and then in the default directory. I really like this directory structure and want to apply it to Kohana. Because of the naming conflict, I am calling these sub-application directories components instead of modules. Here is an example of what I am shooting for:

/application
   /cache
   /config
   /controllers
      /template.php (Template_Controller)
      /welcome.php  (Welcome_Controller)
   /libraries
   /models
   /components
      /admin
         /controllers
            /welcome.php (Welcome_Controller)
            /users.php (Users_Controller)
            /posts.php (Posts_Controller)
         /views
            /template.php (overrides /application/views/template.php)
      /blog
         /controllers
            /posts.php (Posts_Controller)
         /views
            /posts.php (from within blog component: new View('posts'))
      /rest
         ...
      /mobile
         ...
      ...
/modules (Traditional Kohana Modules)
   /auth
   /curl
   ...
/system (Kohana Core)

I use the router to determine the current component, implemented inside my branch of the router3 module. The default value can be set for ‘component’ in a route, or the component can be discovered from the uri, or it can fall back to the default component, which by default is the application itself. The default component can also be given a name such as ‘default’ in the config file. To avoid conflicts I have an array in my config file to define the components that are enabled and the router will only attempt to match those components via a regex built into the route.

Hacking the find_file system is not particularly easy, especially when you enable caching because the component is chosen on-the-fly so the results for (‘controller’,'welcome’) will be different from one request to the next. In order to support cascading of all resources in the component directories, the core would have to be hacked. However, I have successfully implemented this as a module which only supports “controllers” and “views” in the component’s directory. Caching of find_file paths is not broken, and components that are not active for the current request are not in the cascading order at all which I believe to be preferable. Any controllers and views that should be shared among all components in the application can go in the application directories, all others can be separated into component directories.

So what does this accomplish? This let’s you easily keep components of your application organized in different directories. I currently do not include the component name in the controller class like Zend does, so your controller class and file names and view paths can be kept short. E.g., for the typical blog example:

/application
/controllers
   /welcome.php (Welcome_Controller for blog frontend)
/views
   /template.php (template for blog frontend)
   /posts.php (render frontend view of blog posts)
/components
   /admin (URLs starting with admin will use this component)
      /controllers
         /welcome.php (Welcome_Controller for admin backend)
      /views
         /template.php (template for admin backend)
         /posts.php (render admin view of blog posts)

Aside from the more compartmentalized directory structure, the template name does not have to be changed for the component’s template to be used, it just works! Also, when instantiating a view, there is no need to specify sub-directories.

// New:
$this->template->content = new View('posts');
// Old:
public $template = 'admin/template';
$this->template->content = new View('admin/posts');

From a code-management standpoint, this could also have some benefits. For example, do you want to revert the admin component back to an older revision but leave all other components alone? Since the admin components files are all contained under one directory, rather than mixed in with every other component this is a simple task.

Update:

The powers that be cannot be convinced that such a directory structure is worthwhile, or that the Kohana class does not have to be “final” so I’ve unfortunately decided to give up and fork Kohana and track it’s progress.. So much for, as the Kohana homepage puts it, “Loosely coupled architecture” and “Extremely easy to extend”… If anyone is interested in a patch that seamlessly adds this feature, let me know!

Update 2 (4/21/09):

It turns out that the Kohana devs have agreed to make Kohana no longer “final” for 2.4, and in fact have moved the Bootstrap.php file into the application directory as well; Icing on the cake! See r4231