I have these field settings:
- Required: No
- Allowed views: selected one
- nothing else ticked
When creating content I see am option in the viewfield. Selecting it and then clicking on preview lists the first view (of the site) instead of none.
I found this: viewfield.module
function _viewfield_potential_references($field_settings = TRUE, $field = array(), $delta = 0) {
...
if (!$field_settings && (!$field['required'] || ($field['multiple'] && $delta > 0))) {
// drupal_set_message("<pre>" . print_r($options, TRUE) . "</pre>");
// array_unshift($options, '<'. t('none') .'>');
$options[NULL] = '<'. t('none') .'>';
Otherwise it gives a value of '0' later on.
function viewfield_field($op, &$node, $field, &$items, $teaser, $page) {
...
case 'sanitize':
foreach ($items as $delta => $item) {
if (empty($item['vname'])) {
$items[$delta] = array("vname"=>NULL,"vargs"=>NULL);
continue;
}
$item = empty($item['vname']) || $field['widget']['force_default'] ? $field['super_default_widget'] :
This fixes the problem for me. But I think it needs a better fix in case people use the force default stuff.
Great module BTW!!!
Comments
Comment #1
miiimoooActually I think I found a simple solution for this - although it's more like a workaround but might help someone else.
This allows setting the default view to in the field settings and leaves the default on when editing content.
Comment #2
karens commentedIf you don't choose the option to 'force default' the field still saves whatever view is selected as a 'global default value'. If you haven't selected a view, it ends up saving the first view in the list as the 'global default value'. Then on pages where you don't select any view there is some borked logic that displays the global default view even if you have not chosen 'force default'.
This fix doesn't take care of the borked logic, but at least allows the default to be no view instead of whatever view happens to be the first one in the list.
This is a fairly critical problem that actually makes the field unusable if you don't want a default view.
Comment #3
karens commentedTo replicate the problem:
1) Add a viewfield to a content type.
2) Leave 'force default' unchecked and select no view as a default and make it not required.
3) Create a new page for this content type and leave the viewfield empty to display no view on that page.
4) You will see the first view in the viewfield list instead of no view.
Comment #4
bdimaggioThanks for this snippet miiimooo. This problem was kicking my ass, and would have taken me ages longer to figure out without that.
Comment #5
les limMarked #484850: Not choosing any view not possible as duplicate of this issue.
Comment #6
murokoma commentedHi there,
can someone please post the full corrected viewfield.module code/file?
I am not quite sure where to put the additional 3 lines within that block, and I'm also having the issue that always *something* is displayed....
Thanks a lot!
Robert
Comment #7
raspberryman commentedIssue is reproducible with today's -dev.
Comment #8
willhowlett commentedSubscribing
Comment #9
askibinski commentedsolution mentioned in #1 works.
Here is a patch for it.
Any reason not to commit this to dev?
Comment #10
mediamash commentedcritical for futher use indeed, needs update
Comment #11
jupiterchild commentedInstalled viewfield and immediately hit this problem. Pretty much killed what i wanted to do until I came across this thread.
I manually applied the patch from #9 and can confirm this fixed the issue for me.
Comment #12
sdk commentedsubscribing
Comment #13
pepe roni commented@the maintainers:
Is there a reason why you didn't add this path to the current (march 27th) dev release?
I helped myself by creating an always empty view (node-id = 0) and set this view as default in the field settings of the viewfield. But I would better like the patch to be included in the next dev release, please!
Comment #14
sunWhy didn't you just remove !$field_settings and the parenthesis that wrap the directly following condition?
Powered by Dreditor.
Comment #15
sunFresh to this module, but the proposed fix looks wrong - presuming that the calling code is right, of course.
Attached patch should be the proper fix, also clarifying the logic.
Comment #16
sunAlrighty, this time for real - the calling code was bogus, too.
Comment #17
askibinski commentedsun >
thanks, that works (and looks better ;)
Comment #18
willhowlett commentedIs this going to get commited soon do you think? I really need this functionality and would prefer to use an up to date version rather than use patches / workarounds.
Comment #19
willhowlett commentedPatch works great by the way, many thanks. Needed to uninstall the module and reinstall first (is that because the inc file makes changes to the database? I'm new to this)
Comment #20
sunThanks for reporting, reviewing, and testing! Committed to all branches.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
Comment #21
roball commented"Next official release" would be fine - there has not even been a release for 6.x yet. Any plans?