Ldap query: views plugin throwing errors related to "ldap_views_plugin_query_ldap::$where"

Thanks. LDAP views integration is very low on my priority list so it will likely be at the end of the 2.0 Release Candidate sometime in May. In the meantime, any patches are welcomed. Try to use 7.x-1.0-dev for the patches.

Also, which version of views are you using?

I've encountered the same error, and am pretty sure it's caused by the module trying to parse the binary data in the user photo field in ldap (e.g., the "jpegPhoto" ldap field).

So its not a bug, just a case where someone has chosen the wrong fields in the view? Or is it querying for all fields regardless of how the view is setup and colliding with binary fields? Can you attach exports of these views for us to look at using ctools or features?

It's still a bug as far as I can tell, but I haven't traced it. Let me give you the details of my use case:
I use the LDAP module to create a query that pulls all faculty members in the College of Education here at UH Manoa, and then use a view to display these people in a list. Each list item contains:

• the person's name (ldap: displayName)
• position (ldap: title)
• department (ldap: departmentNumber)
• phone (ldap: telephoneNumber)
• email (ldap: email)
• last name, for sorting purposes (ldap: sn)
• cv/resume (ldap custom field: coeCurriculumVitae)
• and a photo of the person (ldap: jpegPhoto)

The jpegPhoto ldap attribute is a weird one, because it stores the actual binary data of the image file. My guess is that the errors reported in this ticket:

• Warning: array_key_exists() expects parameter 2 to be array, integer given in ldap_views_plugin_query_ldap->execute() (line 256 of .../sites/all/modules/ldap/ldap_views/plugins/ldap_views_plugin_query_ldap.inc).
• Warning: array_multisort(): Array sizes are inconsistent in ldap_views_plugin_query_ldap->execute() (line 296 of .../sites/all/modules/ldap/ldap_views/plugins/ldap_views_plugin_query_ldap.inc).
• Warning: htmlspecialchars(): Invalid multibyte sequence in argument in check_plain() (line 1572 of .../includes/bootstrap.inc).

are due to PHP attempting to parse the binary data (either the ldap module, or the views module, or drupal itself). What I've done in other PHP projects is to convert the binary data in jpegPhoto to base64 first, before doing anything else with it. That way all the standard PHP string functions (like htmlspecialchars()) won't choke on them. Here's an example from another project:

  if (ldap_entry_not_empty('jpegphoto',$ldapEntry))
    $person['jpegPhoto'] = "<img src='data:image/jpeg;base64,".base64_encode($ldapEntry['jpegphoto'][0])."' alt='photo' />";
  else
    $person['jpegPhoto'] = "<img src='images/default-avatar.png' alt='No Photo Available' />";

I've also attached an export of the view I've created, if you want to see more details.

i get it now. I also work at a college of education. Looks like the trick will be to figure out which fields are binary data and convert them to base64. When I look at sample users via php ldap in the test form (admin/config/people/ldap/servers/test/) I can certificates and such that appear to be binary. How can you test if its a binary field? Or do we need to make this a configuration option?

Hello, fellow educator! :)

I'm trying to get our sysadmin to chime in on the binary fields question. I've only ever encountered binary data in the jpegPhoto attribute. Here's the documentation on jpegPhoto, which the spec says should always be binary JPEG:

# jpegPhoto 
# Used to store one or more images of a person using the JPEG File 
# Interchange Format [JFIF]. 
# Note that the jpegPhoto attribute type was defined for use in the 
# Internet X.500 pilots but no referencable definition for it could be 
# located.     
attributetype ( 0.9.2342.19200300.100.1.60
    NAME 'jpegPhoto'
    DESC 'a JPEG image'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )

http://www.alvestrand.no/objectid/1.3.6.1.4.1.1466.115.121.1.28.html

I'm not aware of any PHP functions that detect binary strings. I think I'm going to suggest adding a configuration option, that seems the most extensible in case there are other uses. Maybe, in the "Attributes to return" field when editing the query at /admin/config/people/ldap/query/edit/queryname, we could add a flag after binary fields? I'm going to defer to you on this one.

Also, in case I've hijacked this thread (I don't know if the original submitter's issues are caused by binary data), I've included a patch (against 7.x-1.x) that addresses a couple warnings of the original submitter. The patch does not address the array_multisort() error.

Probably overkill to worry about anything besides images for in ldap views for now.

• Will the following take care of this use case?
• If so, can someone verify that it works? I'm not using ldap views now.
• Is there something like feeds tamper for views that this might fit better in. In feeds tamper you would just right a plugin for base64 conversion and UI would be provided by feeds tamper.

at around line 250 of ldap_views_plugin_query_ldap.inc:

    foreach ($entries as $key => &$entry) {
      if (isset($entry['jpegphoto'])) {
        $entry['jpegphoto'][0] = "<img src='data:image/jpeg;base64,".base64_encode($entry['jpegphoto'][0])."' alt='photo' />";
      }
      foreach ($view->field as $field) {

I can verify that the code snippet that converts "jpegPhoto" from binary to base64 works, with slight modification (as written above, I had problems with Views stripping out the html tags, so I did that portion in the "Rewrite Results" section for the jpegPhoto field in my view). Here's the code:

if (isset($entry['jpegphoto'])) {
  $entry['jpegphoto'][0] = "data:image/jpeg;base64,".base64_encode($entry['jpegphoto'][0]);
}

That said, I'm still getting some of the PHP warnings from the OP, so I'll continue to investigate.

I've rolled a patch with the compiled changes in this thread. It takes care of the following:

• Notice: Undefined property: $where (line 140 of ldap_views_plugin_query_ldap.inc)
  
  Warning: Invalid argument supplied for foreach() (line 150 of ldap_views_plugin_query_ldap.inc)
  
  Fix: I initialized the $where variable if it hasn't been set
• Warning: array_key_exists() expects parameter 2 to be array, integer given (line 256 of ldap_views_plugin_query_ldap.inc)
  
  Fix: Added a check to make sure the array exists before checking to see of the array key exists
• Warning: array_multisort(): Array sizes are inconsistent (line 296 of ldap_views_plugin_query_ldap.inc)
  
  Fix: Some LDAP configs (all?) output a "count" variable first in the array, which changes the total array size; if this key exists, I remove it, sort the array, and then add it back in.
• Added automatic encoding of 'jpegPhoto' field to base64.

Let me know if you need any more help on this issue. And thanks for all your amazing work!

Thanks for following through on this. Here's a related issue #1533492: LDAP *: Need method for dealing with binary attributes also. Seems like maybe an ldapAttribute class may be in order. I thought about an ldap attribute field type that has a binary flag, but most of the config forms aren't using entities and fields.

I committed this to the 7.x-1.x branch sometime ago. Am changing to 2.0 so I don't forget to commit it there.

i committed this to the 2.x branch also. thanks.

foreach ($entries as $key => &$entry) {
if (isset($entry['jpegphoto'])) {
$entry['jpegphoto'][0] = "";
}
foreach ($view->field as $field) {

The following code in the plugin is rewriting the HTML and is inserting HTML characters in the code.

Can someone tell me how to fix?

Thanks!

The Views module is pretty strict about what values it allows it fields; for example, it will encode angle brackets as < and >.

The only way I've found to get around this is to use "Rewrite Results" to spit out the actual html bits. If you look at the patch above in #10, you'll notice that the code only spits out the value for the "src" attribute in the image tag, not the image tag itself:
$entry['jpegphoto'][0] = "data:image/jpeg;base64,".base64_encode($entry['jpegphoto'][0]);

When I bring jpegphoto into a view as a field, I go to Rewrite Results, check "Rewrite the output of this field," and use something like the following:
<img src='[attribute]' alt='photo' />
where "[attribute]" is the replacement pattern for your jpegphoto field.

This way, the LDAP module outputs the base64 encoded image, and Views takes care of wrapping it in an image tag. By doing that, I avoided the angle brackets being stripped out and not interpreted as actual html.

Hope that helps!

Hi figureone,

Huge thanks for the response! I actually did understand what you are saying and tried to implement it. One problem I'm having is the jpegphoto field is spitting out the exact rewrite results as text and not bringing in the img src. All I see in that field is photo from the alt text.

Should I use PHP Views instead to get the rewrite results field to read it as straight HTML and not as text?

I've attached a screen shot of the results and also what the html looks like.

Thanks, again, for all of your help!

Pxl

Hi figureone, I've actually been playing with this since this morning.

I've changed line 257 in the ldap views plugin to be your code where you it strip out the < > for the image. I then went and rewrote the results again and everything is working!

$entry['jpegphoto'][0] = "data:image/jpeg;base64,".base64_encode($entry['jpegphoto'][0]);

What's weird is I did this yesterday and cleared the caches and it wasn't working. Now it is. Strange!

Thanks so much for your help!

Pxl

Glad you got it working!

I'd like to be able to give johnbarclay a better solution (since this one forces you to use rewrite rules, which isn't very self-explanatory), but I've yet to find one. Every time I try to output the entire image tag as the field value, Views mangles the angle brackets.