Extension, Module

Developer
Supported

EE 1
EE 2
Zenbu

Back to this add-on's main page
View Other Add-ons From Nicolas Bottari

     

You must be logged in to post.

PHP errors when searching

Support Request

GDmac
GDmac

I get some errors when searching for “php” in titles-and-basic-fields.
(was searching for phpmyadmin export leftovers)

A PHP Error was encountered
Severity: Notice
Message: Undefined offset: 1
Filename: fieldtypes/playa.php
Line Number: 227

besides that, a great add-on. Wish i could organize searches a bit and copy them over to other admins.

regards,
GDmac

Nicolas Bottari - Zenbu Studio
# 1
Developer
Nicolas Bottari - Zenbu Studio

Hi GDmac,

Sorry for the delay in my answer. What version of Zenbu are you using? The latest version (1.5.3) has some added tweaks for Playa. :)

GDmac
# 2
GDmac

I downloaded 1.5.3, here from devot-ee (Zenbu_v1.5.3_20120307.zip),
but under add-ons -> modules Zenbu reports version 1.5.2

Nicolas Bottari - Zenbu Studio
# 3
Developer
Nicolas Bottari - Zenbu Studio

That was my mistake, the version wasn’t bumped up to 1.5.3 in the config.php file. The contents of Zenbu are 1.5.3, though.
This has been fixed in the package now, so if you redownload Zenbu, you’ll should have the right displayed. Alternatively, you can modify the config.php file to 1.5.3 :)

Nicolas Bottari - Zenbu Studio
# 4
Developer
Nicolas Bottari - Zenbu Studio

I also can’t reproduce your issue on my side. Does it only happen when searching for “php”?
Also, the “Any title or basic custom field” search is a basic search, which means that Zenbu looks for matches in data stored in exp_channel_data, but doesn’t go deeper into third-party tables.

GDmac
# 5
GDmac

Looking a bit further into this.

I think the issue might be the following.
Zenbu_get.php, line 2062 passes all data to the fieldtype class, method zenbu_get_table_data.

However, from what i can see, without passing the actual field_id for that fieldtype to process.
It just passes entry_ids, and a wide rel_array with all field_id and field-data (of which only one is a playa field)
However, in that fieldtypes/playa class, around line 210, it starts blindly digging deep into
the entry_ids, then rel_array and then if ANY of the field contains a square bracket ‘[’, explodes to array on it.

So when any field contains a square bracket, the loop will bork. See this fictional data i extracted from a var_dump of $rel_array. field_id_21 is a playa field, but because the loop tests ANY field, it borks on the javascript [CDATA in another field.

1759 => 
    array (
size=32)
      
'field_id_27' => string '' (length=0)
      
'field_id_21' => string '[1758] tester - tester' (length=22)
      
'field_id_37' => string '0' (length=1)
      
'field_id_46' => string 'Hello world' (length=0)
      ....
2127 => 
    array (
size=32)
      
'field_id_27' => string '' (length=0)
      
'field_id_21' => string '' (length=0)
      
'field_id_37' => string '' (length=0)
      
'field_id_46' => string 'javascrip <![CDATA ....' (length=0
Nicolas Bottari - Zenbu Studio
# 6
Developer
Nicolas Bottari - Zenbu Studio

Thank you for the details. I can see where this can cause an issue when brackets are involved (even for a related entry whose title contains a bracket). The tweaks introduced in 1.5.3 were mostly for the zenbu_result_query function in the playa.php file, but I’ll see if I can’t extend this to the other functions. Hopefully this will avoid the error you described in the future. :)

GDmac
# 7
GDmac
$rel_ids = array();
  foreach(
$entry_ids as $key => $entry_id)
  
{
   
foreach($rel_array as $key2 => $val2)
   
{
    
foreach($val2 as $f_id => $playa_data)
    
{
     
if(isset($playa_data) && ! empty($playa_data))
     
{
      
// replace all newlines with regex-compatible ones
      
$playa_data str_replace(array("\r\n""\n""\r"), "\n"$playa_data);
      
// match bracketed digit at start of line [123]
      
$count preg_match_all('/^\[(\d+)\]/m'$playa_data$matches);
      if (
$count)
      
{
       
foreach($matches[1] as $playa_id)
         
$rel_data[$playa_id] $playa_id;
      
}
     }
    }
   }
  } 

Could only get this to work with \r\n replacing, but seems to work now.
And still, if someone puts [123] at the beginning of a line in any custom-field, it will match :-(
it is probably better to supply the field_ids for fields that really are playa fieldtypes.

GDmac
# 8
GDmac

Nicolas, did you see above code?
The regex essentially anchors searching for bracketed
digits [123] at the beginning of a line “/^\[(\d+)\]/m”.

But as mentioned, the current implementation of zenbu_get_table_data() has no
way to limit searches to own fieldtypes (like playa), and searches thru all fields.

Nicolas Bottari - Zenbu Studio
# 9
Developer
Nicolas Bottari - Zenbu Studio

zenbu_get_table_data() is a function to retrieve third-party data from third-party tables to avoid making a new query at each entry result row. This is particularly used when doing searches on a specific Playa field, not “Any title or all basic custom fields”.

Actually, “Any title or all basic custom fields” should only be searching for data stored in exp_channel_data. If zenbu_get_table_data() is being called, as we’re observing here, I’ll have to add a check to skip the function and avoid the explode(). There may be other strategies, which I’ll have to consider. :)