Use of exposed filters causes error: html_entity_decode() expects parameter 1 to be string

subscribe

I am having this same error on a bulk-edit report where I wish to filter the nodes by taxonomy term.

Can you please post a patch or tell me the file name where I can apply the change manually.

I would be happy to confirm this fix.

Thanks

I have the same problem after upgrading to the latest views dev version. I got this error when I'm trying to access the page that has taxonomy exposed filters.

Warning: html_entity_decode() expects parameter 1 to be string, object given in decode_entities() (line 429 of /var/www/vhosts/cdm.bild-studio.me/httpdocs/includes/unicode.inc).

My taxonomy filters are all empty. Here the picture:

Quick fix attached that works for me. But I'm not sure if the options shouldn't be prepared before sanitizing with prepare_filter_select_options() function instead...

When will you commit the solution to this bug to dev version?

I'm quite confused why this is an object, this shouldn't be the case.

Dereine:
I used only default seetup of drupal 7 stable version. Make a view taxonomy exposed filter and again received the same message. If you google the net with this message you will see that a lot of sites has the same error message:

https://www.google.com/search?ix=heb&sourceid=chrome&ie=UTF-8&q=html_ent...()+expects+parameter+1+to+be+string%2C+object+given+in+decode_entities

I definitely going back to stable version until this bug is solved. It is causing too many errors in panels, exposed filters etc...The patch attached here solve one of problem but the error is still there.

I couldn't edit my views anymore after applying this patch (tried clearing cache), so I suppose it has some work to go.

The type of exposed filter doesn't really seem to matter. I'm going to be bold and generalize this bug report.

If it helps, this is my dpm($text); from includes/entities.inc::decode_entities().

... (Array, 3 elements)
value (String, 1 characters ) 0
min (String, 0 characters )
max (String, 0 characters )
Krumo version 0.2.1a | http://krumo.sourceforge.net Called from /home/kevin/public_html/finance/includes/unicode.inc, line 431  
... (Array, 3 elements)

value (Array, 1 element)
date (String, 0 characters )
min (Array, 1 element)
date (String, 10 characters ) 2012-02-28
max (Array, 1 element)
date (String, 10 characters ) 2012-03-27
Krumo version 0.2.1a | http://krumo.sourceforge.net Called from /home/kevin/public_html/finance/includes/unicode.inc, line 431

You can basically see that it's the two exposed filters I have. Will try to dig deeper...but I don't have much hope of being able to get my head around this quickly.

Ehh, going back to stable Views fixes this for now, and, for some reason, I don't get the errors on drush cc all that I was before that prompted me to upgrade in the first place. The DB update just changed column size, so not worried about reverting the code for now.

(Fix title spelling.)

Got the same problem, rolling back to views 3.3 solves the problem, but views 3.3 have another critical issue: #1450268: Fatal error: Call to undefined function language_fallback_get_candidates().
Patch from #6 solves this issue, and after that I can edit views and at now find none other problems.

#6 works for me

It would be so helpful if someone could explain a way for me to reproduce the issue.

For example provide a view, which tells the actual filter used there.

Steps to reproduce:

1. Create a taxonomy vocabulary and add some terms.
2. Add a term reference field to a content type (e.g. Basic page) using the vocabulary.
3. Create a node view (and add some basic fields).
4. Add a term filter (doesn't matter whether the generic term filter or the field-specific filter).
   1. Set "Selection type" to "Dropdown".
   2. Check "Show hierarchy in dropdown".
5. Expose the filter.

Expected result: When displaying the view (e.g. in the preview), the exposed filter is shown as a select list with terms listed.

Actual result: Each option in the select list is blank. Furthermore, the option values are incorrect (i.e. numeric array indices).

Additionally, here is a reference to the usage of select options as objects: form_select_options(). The reasons this isn't a problem in 6.x-3.x are (i) there is no views_handler_filter::prepare_filter_select_options() and (ii) views_handler_filter::exposed_translate() never had to call decode_entities().

I have adapted the patch in #6 to emulate the logic in form_select_options().

The patch works for me (7.x-3.3+45-dev), when applied to a User View (with user account including term reference fields). Thank you...

Awesome, just added a small comment about the function in FAPI which is causing that and committed to 7.x-3.x

Patch does not apply against latest dev (7.x-3.3+122-dev)

@skizzo
Sure, because it got committed to 7.x-3.x-dev...

Any thoughts on the next stable release of views? The last one is from 2012-Feb-22 and it would be good to not have to run the dev version on a production site.

This is true, but I found this discussion because I am running against this same issue on 7.x-3.5. The suggested patch is already in the code. Is there anything else this might be?

Hello,
Nothing to add, just to confirm that like Laura Davilla, I've got the warning on the 7.x3.5 version. And I'm afraid that I have NO exposed filter at all. So the "warnings" may be cause by something else.

I attach my view to my comment if this is any help. The warnings display on the block_4 display.

Sorry, I attach the wrong view (I have two on the same page...). After test, the view causing the warnings is the one attached here, forget the previous one :-). Thanks.

EDIT: Trying dev version didn't change nothing, still got the warnings...

After all, seems to be something with $view->get_title(), for my warnings... I have to say that my view was printed via php (views_get_view()...etc...). After manipulating my php, printing/deleting/doing/undoing the warnings went away. I also left the 7.x-3.5 version. Sorry not to be more precise.
And thanks again.

David

Fixing html

I'm seeing this error flood my logs. Is this really lingering after >4 years? :(

Bump.

My logs were also flooded by this message and in my case I could track down the error to a custom print template file which called

$view = views_embed_view($view_name, 'block_1', array($node->vid));

Changing it to

$view = views_embed_view($view_name, 'block_1', $node->vid); (No extra array for third argument)

fixed my log flooding.

Good comment in #28; I'm still hunting for this in my code.

#28 Fix the issue

I wonder if the problem is also caused by some other modules using views_embed_view() incorrectly?

Marking this closed, thank you everyone for working on the fix. Please open a new issue if there is still a related bug in Views itself.