dom_id conflicts with Views 3 [#1447076]

Since version 3.0, Views has a better way to compute unique dom_ids that makes it useless to do the same in nodereference_explorer_views_pre_render().

Worse, it appears that the way nodereference_explorer computes dom_ids can create conflicts when using attachment displays (see #1446970: ajaxViewResponse produces blank output if target selector matches several elements).

I propose to change nodereference_explorer_views_pre_render() to do nothing if Views 3.0 or later is in use, or use the same code than in Views 3 if it's an earlier version. Patch incoming.

Comment	File	Size	Author
#1	unique_dom_id-1447076-1.patch	2.52 KB	mdupont

Comments

Comment #1

mdupont

French

Switzerland

commented 20 February 2012 at 17:21

Status	File	Size
new	unique_dom_id-1447076-1.patch	2.52 KB

And here is the patch. It checks against views_api_version() and fallback to the same code than used in Views 3.0's theme.inc.

Comment #2

mdupont

French

Switzerland

commented 22 March 2012 at 09:53

Note: for the pager to work, I also had to change the following line in nodereference_explorer_views_pre_execute() from:

  $type = $view->args[0];

to:

  $type = html_entity_decode($view->args[0], ENT_QUOTES);

Otherwise, the name of the content types were wrapped with the HTML entity for the apostrophe character (') instead of the character itself, causing MySQL to fail on the query.