CCK Reference fields based on views broken by recent change in views_plugin_style Views 2.7 (#502348)
eft - October 25, 2009 - 22:30
| Project: | Content Construction Kit (CCK) |
| Version: | 6.x-2.x-dev |
| Component: | Views Integration |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
I have two content types with CCK fields. One type includes a CCK field that is a node reference, the other includes a CCK field that is a user reference. Both field are Select List widgets based on Views. The view results sets are as expected when previewing them; however, I just installed the latest Views dev version (date stamped 1256344316) and when creating content the select lists are empty. I reverted to the previous dev version (date stamped 1255998945) and the select lists are populated fine.
If you need me to provide more info I would be happy to do so - I just don't know where to look.

#1
I am also seeing this bug on Node Reference fields using the views display option with Autocomplete textfields -- the "title" field is blank/empty. The view itself is working and the title field shows up fine in views preview. This started with the Oct. 23 release (Oct. 19 release was working fine.)
#2
Moving this to CCK primarily to get Markus' attention.
The common factor here is that I committed a patch that moves field rendering around. I didn't think it would affect other things, but it appears that this may have affected CCK. The patch I committed is #502348: How group display by mutliple fields? -- can you see if this patch has caused a problem for CCK and then we can figure out what the problem is and where it should be fixed.
#3
Ugh, it not only affects the Select widget, but also the autocomplete widget when based on a view.
It seems the 'content_php_array_autocomplete' style is broken by this change in Views. The code is tiny and can be seen here:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/cck/include...
Playing with an autocomplete path, for example,
nodereference/autocomplete/field_test_noderef/text, the result looks like this:{ "text [nid:411]": "\x3cdiv class=\"reference-autocomplete\"\x3e \n \x3cspan class=\"views-field-title\"\x3e\n \x3cspan class=\"field-content\"\x3e\x3c/span\x3e\n \x3c/span\x3e\n\x3c/div\x3e"So it seems the value contains markup, and that breaks the nodereference widgets.
However, I'm not sure to understand the change in Views. Earl, could you please help?
#4
Hmm. The change I made moves the rendering of fields upstream somewhat. But I'm not sure why it would affect this.
The rows should always have had markup, so I don't understand how this changed that.
#5
hmm... looking a bit more at this, it seems the problem is not that we render markup here. Markup here is fine. The problem is that the following code generates only markup, with no data:
<?php
class content_plugin_style_php_array_ac extends views_plugin_style {
function render() {
$results = array();
// Group the rows according to the grouping field, if specified.
$sets = $this->render_grouping($this->view->result, $this->options['grouping']);
$base_field = $this->view->base_field;
$title_field = $this->display->display_options['content_title_field'];
$title_field_alias = $this->view->field[$title_field]->field_alias;
// TODO : We don't display grouping info for now.
// Could be useful for select widget, though.
foreach ($sets as $title => $records) {
foreach ($records as $label => $row) {
$results[$row->{$base_field}] = array(
'title' => $row->{$title_field_alias},
'rendered' => $this->row_plugin->render($row),
);
}
}
return $results;
}
}
?>
The 'rendered' elements in $result array only contain markup, without real data about the fields. So we may need to change
$this->row_plugin->render($row)or the code that's behind that, but honestly, this part of CCK/Views integration is kind of obscure to me. I do not understand the flow. :(I guess it could also be related to the following snippet from nodereference.module:
<?php// TODO from merlinofchaos on IRC : arguments using summary view can defeat the style setting.
// We might also need to check if there's an argument, and set *its* style_plugin as well.
$view->display_handler->set_option('style_plugin', 'content_php_array_autocomplete');
$view->display_handler->set_option('row_plugin', 'fields');
// Used in content_plugin_style_php_array::render(), to get
// the 'field' to be used as title.
$view->display_handler->set_option('content_title_field', 'title');
?>
#6
Just a quick observation: Using the latest CCK 6.x-2.x-dev (Oct-15) and the latest Views 6.x-2.x-dev (Oct-28) results in this problem. Reverting Views to the 6.x-2.6 release from June 10 fixes it.
#7
#8
subscribing
#9
subscribing
#10
I've been bitten by this bug while upgrading to Views 2.7, attached patch against the latest CCK 3.x-dev seems to fix it. It's pretty much the same fix the Views Accordion module applied in #621568: Views 2.7 breaks views accordion
#11
@DeFr: Thank you very much! :-)
After testing here, this seemd to fix Reference fields using Views here, so I've committed this to CCK2 and CCK3.
#12
Just confirming that the patch works on CCK 6.x-2.5. Thank you.
A newbie quesiton, have I understood this correct: That the patch is commited means that it's commited to CVS, and will turn up in the next stable release as well as the next development release?
Marcus
#13
Yes, the patch has been committed to CCK2 and CCK3 branches. It should be available in the next development snapshot, and of course it will be in when a new stable package is released.
PS: I'll contact yched and KarenS to evaluate if a new release of CCK worths to save time to all of us. Otherwise, all those who upgrade to Views 2.7 but keep CCK 2.5 will be affected by this issue.
#14
(coming from #242158: nodereference dropdowns not populating with node titles when using advanced view)
Thank you, patch solves the problem. It's absolutely woth a new version. As you just stated, markus, I ran into this issue when updateing to Views 2.7, added a comment to a duplicate of this issue and I'm sure, others will follow with new duplicate issues.
#15
Hi,
I may be having the same problem.
I have a content type that has a pull-down field where the allowed values are populate from a view. The content type also has fields that are a taxonomy tag (multi-select) and a pulldown text field with 3 possible values. If the view-pulldown come before (higher on the page) than the others, then the others are broken and have empty pulldowns and you can't select anything. If the view-pulldown comes after the other pulldowns, then they all work.
Since the site I am working on is complicated and has custom modules that do form_alters and etc, I set up a clean drupal install and tried to replicate the behavior. I have I so far not been able to; instead I have a separate problem; the views-populated pull down shows only the label, not the contents of the view output. (The view previews and works fine). It is a node reference that is using a view that has one filter (node published is yes) and one filed (Node: Title). In the pull down you see "Title: " for each possible selection, but nothing after the "Title:".
I also took the site I am working on and one by one disabled all the custom modules, but the problem still happens.
Eventually I will either have a version of my clean test site that produces the problem, and then I can post the whole db dump here, or I find some piece of the development site that I can disable to make it work, and I will focus on that. In the meantime if anyone has suggestions to narrow the search that would be appreciated.
As a final weird observation, this bug appears for user 1, and for at least some users with just "authenticated user" permissions everything works perfectly.
--Rob
#16
Do you still experience this problem, after applying the patch? Have you installed Views 2.7 on both websites?
#17
On the "clean" site I was using views 2.7. On the dev site I was using views 2.6, I upgraded to views 2.7, and the same behavior remains, except that now the view-based pull down also has no values in it. The 614292.patch above caused the views-based pull down to start working again, but any pull downs after it still do not work, unless you are not the admin user.
It continues to work better if you have a less privileged account, which I will try to use to narrow this down. I will hopefully post more on this tomorrow.
--Rob
#18
So I'd suggest tu open a new issue, as the Views .27 compatibility issue is fixed for you with the patch and your problem already existed before updateing to Views 2.7.
#19
This is already included in CCK 6.x-2.6.
#20
I have just upgraded to both Views 2.7 & CCK 2.6, and *am* seeing this problem. It appears that CCK 2.6 did *not* fix the problem for me.
The dropdowns are empty for both admin and non-admin users.
#21
Automatically closed -- issue fixed for 2 weeks with no activity.