When adding a new View, I select
Show-> BIR Object of type -> BIR Image
This is a custom created entity with 4 bundles, BIR Image being one of them in the "show" list.
When clicking Continue and Edit, the following warning appears:
Warning: htmlspecialchars() expects parameter 1 to be string, array given in check_plain() (line 1476 of C:\Users\Robert\Documents\My Work\drupal\www\includes\bootstrap.inc).
Under Filter, I see "BIR Object: Type (= ) "
If I edit the filter, it shows bir_image in the Value. When I click Apply, it then shows correctly under the Filter:
BIR Object: Type (= bir_image)
The above warning then disappears whenever coming back to the view. It appears the select is not passing on the correct value. Though, perhaps this is related to Entity API? The select works when using Content, Taxonomy, etc.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 1117512-wizard-dont-assume-filter_in_operator.patch | 1.42 KB | dawehner |
| #8 | 1117512-wizard-dont-assume-filter_in_operator.patch | 1.7 KB | dawehner |
| #6 | ViewPage.jpg | 14.78 KB | rbruhn |
Comments
Comment #1
merlinofchaos commentedHm. My guess is there's something going on with your custom entity here. This is going to be difficult to debug unless we can reproduce it.
I would start by doing a debug_backtrace() in check_plain -- that particular error means that check_plain() received an array, not a string. That suggests that the value is stored as an array, but what's *displaying* the value thinks it's a string, which means the actual filter handler is having an issue.
Do you have a custom filter handler? Do you know what filter handler is being used here?
Comment #2
merlinofchaos commentedComment #3
rbruhn commentedChasing this down all day...
From what I conclude in comparing Content->Article vs my BIR Object-> Bir Image, the views handler used is based on the field type from the table data:
File: views.module Line: 987
Because my entity bundles are defined by the "type" column, it returns:
Thus, it is using the views_handler_filter_string vs views_handler_filter_node_type.
The error occurs when File: admin.inc, Line 2146 runs:
File: views_handler_filter_string.inc, Line: 133
$this->value is an array in this circumstance: array('bir_image' => 'bir_image'). It's an array in other cases too from what I can tell: array('article' => 'article'). It's just handled differently in the other filters. Changing $this->value to a string fixes the warning, as well as showing the bundle in the Filter correctly: BIR Object: Type (= bir_image)
I'm not offering a fix as I'm not sure how this should be handled. Whether it should be taken care of in the admin_summary() code or some other place.
Comment #4
esmerel commentedComment #5
dawehnerI'm wondering how you managed to get an array on a form which just has a textfield.
Can you also post your full views integration?
What you probably want is an 'options callback' key in the definition of your views data for the filter of the field type.
Comment #6
rbruhn commentedThis is simply running the with Entity API, which is suppose to have built in Views operation.
You asked about how the array gets in there. There is not a text field, it's a drop down. It's like I explained above...
The entity info and table stores the bundle types in a column named "type."
When creating a new View, the file views.module Line: 987 function runs, it's selecting the "type" column to display in the drop down so the appropriate bundle types appear.
Show [BIR Object] of type [BIR Image]
(see image attached)
Since the column "type" is a string, the function returns views_handler_filter_string as I commented above.
Now if I have to solve this by creating my own views data handler for my entity bundles, I will. I simply thought an entity is an entity, and the bundle types would be handled appropriately.
Comment #7
dawehnerIn general entity api should use a filter_in_operator for the type column, because you always have just N availible bundles.
Nevertheless views should fix it internally, so it does not assume this anymore.
Comment #8
dawehnerHere is a patch for it. There should someone create an issue in entity api.
Comment #9
dawehner@rbruhn
I would like you to test the patch. thanks.
Comment #10
rbruhn commented@dereine
Sorry, just saw this.
Thanks. I will check it out tomorrow. It's 12am here and my eyes and brain are fried :-)
Comment #11
rbruhn commented@dereine
I tested the patch and it appears to work.
I changed how I was doing things in my own modules (nodes instead of entities), but tested the result using Organic Groups. When creating a view and choosing:
Show: Organic groups membership of type og_membership_type_default
It produced the same error I had with my entities. Once I applied the patch, it worked as expected with no errors.
What issue should be created for entity api? I'm not sure how the issue would be phrased, or where the problem would be in entity api.
Thanks for this patch.
Comment #12
dawehnerI'm not 100% aware but do you think that bundles are always somehow limited like node: type's?
If yes entity api should use 'handerl' => 'views_handler_filter_in_Operator' instead of 'views_handler_filter_string' by default
Comment #13
rbruhn commentedNot sure what you mean... but every example I've come across using bundles has had a type table like node. For example, the same error occurs when using the Profile2 and OG.
So yes, I guess your statement about the handler Entity API is using should be changed.
Comment #14
dawehnerHere is a new version which doesn't break the taxonomy terms
Comment #15
rbruhn commentedThanks dereine. Didn't even check how it effected other modules.
Comment #16
dawehner@rbruhn
You know the issue seemed to be quite important for you, so can you please test this patch?
Comment #17
rbruhn commentedSorry. The patch did work for me if that is what you are asking.
Kind a new to Drupal so not sure if there is something more I need to do for testing.
Comment #18
dawehnerThanks for testing out the patch!
Commited to 7.x-3.x