Thread

I’m using EE 2.1.3 b20101220 and Playa 4.0.5. I created a new playa field for a channel that already contained entries. The exp_channel_data fields for the new custom field contains NULL as the value (as expected with creating a new DB field). It appears that IS_EMPTY doesn’t account for NULL values when used in the exp:channel:entries tags.

I believe my issue is the same as the one documented here: http://ellislab.com/forums/viewthread/165419/

Also, you can see my code and the debugging Brandon Kelly and I have done here: http://help.pixelandtonic.com/brandonkelly/topics/does_is_empty_work_in_a_channel_cntries_search_parameter

Could you please shed some light on this? I think it may be a bug but I could be doing something wrong.

Thanks!

Jesse Bunch

Hi, Jesse.

I honestly don’t know if it is a bug or not.. I’ll be asking the dev team about this. Thanks in advance for your patience.

Just FYI, until this is addressed by your dev team, here’s how I implemented the fix I needed:

For search:field_name=“IS_EMPTY”:

Open up mod.channel.php and beginning at line 2465 or so and change:

if ($term == 'IS_EMPTY')
{
    $sql .= ' wd.field_id_'.$this->cfields[$this->EE->config->item('site_id')][$field_name].' '.$like.' "" '.$andor;
}

to

if ($term == 'IS_EMPTY' && $like == "LIKE")
{
    $sql .= ' wd.field_id_'.$this->cfields[$this->EE->config->item('site_id')][$field_name].' IS NULL OR ';
    $sql .= ' wd.field_id_'.$this->cfields[$this->EE->config->item('site_id')][$field_name].' = "" '.$andor;
} 
elseif ($term == 'IS_EMPTY' && $like == "NOT LIKE")
{
    $sql .= ' wd.field_id_'.$this->cfields[$this->EE->config->item('site_id')][$field_name].' > "" '.$andor;
}

Note: the fix will also have to be implemented for search:field_name=”=IS_EMPTY”. I’m not intimately familiar with the EE core codebase so this may not be the best way to fix the issue and it may cause issues in other use cases, but it seems to do the trick for me.

Thanks for running this down.

Hi Jesse,

Thanks for your update. We’ll update this thread when we get some more information for you.

Cheers

Greg

We originally approached this issue by making sure those fields weren’t null- given the complexity already existing in the search query, we didn’t want to make it more complex.

The entries api should be catching the empties and putting them in as an empty string (or allowing the default in the case of numbers- which should be 0).

if ( ! isset($cust_fields[$field->name]) OR is_null($cust_fields[$field->name]))
{
    $cust_fields[$field->name] = '';
}

I suspect the null values are getting in when the field is added w/already existing entries- they go in as the default (null) without the check that happens when an entry is added.

I think the long term solution is still to clean the data that goes in, rather than add to the search query load- and have entered this as a bug along those lines: bug.

For the short term?  The above hack shouldn’t cause any problems.  And we’ll see about getting those new custom fields setting to empty string rather than null.

Make sense what’s going on there?  We missed the nulls that go in when you create a new field and already have existing entries.  (New entries/edits shouldn’t have a problem.)