This might be totally just our project related but thought to share this finding.
After applying this patch I noticed that if grid, like orders grid, has some custom filtering which uses filter_condition_callback
setting. This might produce an error. In our case we have a date field and for the grid it has index recurring_billing_dates
and 'filter_condition_callback' => array($this, 'filterRecurringDates');
and that custom callback is just using two different fields from db so the default index shouldn't be used in the filtering at all.
Patch makes the following change:
index 2c8f1623186..52e4f186d05 100644
--- app/code/core/Mage/Adminhtml/Block/Widget/Grid.php
+++ app/code/core/Mage/Adminhtml/Block/Widget/Grid.php
@@ -464,7 +464,7 @@ class Mage_Adminhtml_Block_Widget_Grid extends Mage_Adminhtml_Block_Widget
{
if ($this->getCollection()) {
$field = ( $column->getFilterIndex() ) ? $column->getFilterIndex() : $column->getIndex();
- if ($column->getFilterConditionCallback()) {
+ if ($column->getFilterConditionCallback() && $column->getFilterConditionCallback()[0] instanceof self) {
call_user_func($column->getFilterConditionCallback(), $this->getCollection(), $column);
} else {
$cond = $column->getFilter()->getCondition();
So the change in the if clause might lead one to see error report if the column index isn't same as some column in db and that instanceof self
fails. System ends up in the default path without using the call_user_func and tries to use the index
directly. In our case the custom field is injected through xml sales_order_grid_update_handle
. Now I just probably have to figure out how to change these custom callbacks to work with this patch.
Version we're using is 1.9.4.0.
Edit: Fixed the issue by moving callbacks to another class which extends proper parent class in this case Mage_Adminhtml_Block_Widget_Grid
. In the past custom callback functions could basically be in any class and we had these in plain Helper\Data.php
which just extended Mage_Core_Helper_Abstract
and that didn't work anymore.