Posted by javier.alejandr... on June 12, 2012 at 10:04pm
45 followers
| Project: | Chaos tool suite (ctools) |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
This function is completely broken. Try add a condition on any field, and on saving you will get errors and notices everywhere.
I tried to fix it, but code is very complex, and i dont want to break it much more! Hope somebody can fix it soon, as lots of cases are not handled (conditions on taxonomy terms, etc)
Comments
#1
Patch for making code work with taxonomy fields, and a PHP 5.4 notice/error
#2
The last submitted patch, ctools.patch, failed testing.
#3
Marked as duplicate #1435426: Notices thrown when using visibility rules on hidden fields
Also related issue #1520036: Notices thrown when taxonomy used for selection criteria
Both issues are depends on assumption that field contains only one storage column named 'value' but this wrong.
I think both issues should take a same approach for storing config and checking values in loop
#4
This fix worked for us. Doesn't address the taxonomy issue, but it should pass the testbot.
#5
I'm having the same error but no joy with the patch.
I'd created some content types and was trying to set the selection rule on a panel as follows
Panels > Manage Pages > Edit Node Template > Add Variant with Selection Rules checked > Selecting Node type of my custom content. My selection rules on the summary page just say
The main error i get is:
#6
Using Chaos Tools version 7.x-1.1, cannot set selection rules based on taxonomy field.
<?phpforeach ($value_keys as $key => $value) {
$values[$value] = $elements[$key]['#markup'];
}
?>
Here's some debug info:
<?php
print_r($value_keys);
/*
Array
(
[0] => @tid_value
)
*/
?>
<?php
print_r($values);
/*
Array
(
[@tid_value] => 7
)
*/
?>
<?php
print_r($elements);
/*
Array
(
)
*/
?>
#7
If we're manually setting
$display['type'] = 'list_default';then we *must* always call list_field_formatter_view(). I'm trying to scratch my head why this is even running code through the list formatter by default. Why not just output the raw values in the summary??#8
Personally I think until we're able to figure out how to get this to work showing field 'nice' values, then it should just stay simple and output the raw field values. Revised patch converts the summary to output the raw field values.
#9
Revised that doesn't fatal error. With the attached patch for taxonomy term fields I get a summary of 'tid equals 4, 5'
#10
After patch applied I get summary "tid equals ", and a warning in the next step:
<?phpforeach ($field['columns'] as $column => $attributes) {
$string .= " @{$column} equals @{$column}_value";
$keys['@' . $column] = $column;
// Display the field values raw separated by commas.
$values["@{$column}_value"] = implode(', ', $conf[$field_name . '_' . $column]); // line 205
}
?>
$conf variable
Array
(
[field_program] => Array
(
[und] => Array
(
[0] => Array
(
[tid] => 7
)
)
)
[field_program_tid] => 7
)
$field_name . '_' . $column evaluated value
field_program_tidPassing a scalar value into implode() while array is expected. This could be made to work if checked for scalar value I suppose:
<?php$value=!is_array($conf[$field_name . '_' . $column]) ? array($conf[$field_name . '_' . $column]) : $conf[$field_name . '_' . $column];
$values["@{$column}_value"] = implode(', ', $value);
?>
#11
Custom node layout is still not showing, in addition, your patch throws number of notices now:
#12
Anyone can fix this ? Please help. Need this in my project right now.
Cheers
#13
The more selection rules you add to the node template the list of error messages becomes bigger.
#14
I applied the patch in #9 and got the same output as #10.
Still experiencing the problem.
#15
This issue should be fixed after #1601062: Field access plugin ignoring selected value
Because currently
ctools_entity_field_value_ctools_access_settings_submit()wrongly saves data for field and totally broken for compound fields.The only question here is how to store values without breaking current config values, suppose hook_update_n() does not solve this problem.
The value that used to display summary stored in [field_name]_[column_name] see attached screenshot
For compound fields (link module for example) see second screenshot
#16
This is very big bug I don't believe that maintenaners allow this kind of bugs
#17
Also perhaps this bug with tools produced another bug in views new feature. Groupde Filters.
http://drupal.org/node/1778378
#18
It's not just the summary the whole thing seems to throw warnings and not really work.
#19
I have the same issue with taxonomy fields, I have the Notices, although the visibility rule works correctly.
I get 18 Notices like this one, when I am in the content tab, in pages->edit node_view in every variant I created:
#20
Also we could fix #1601062: Field access plugin ignoring selected value first
Because this Really completely broken
#21
Hello,
i run into this problem by upgrading from 7.x-1.1 to 7.x-1.2, so upgrading crashes my whole site.
In 7.x-1.1 all works fine for months.
I would change the version of this thread from 7.x-1.x-dev to 7.x-1.2.
#22
#9: 1630820-field-value-access-summary-borked.patch queued for re-testing.
#23
The error "Undefined index: module in ctools_entity_field_value_ctools_access_summary" in the current stable version is caused by a condition on a field that is marked as "Hidden" in the node type display settings:
The error is caused because of the following lines in entity_field_value.inc:
$display = field_get_display($instance, $view_mode, $entity);$display['type'] = 'list_default';
$function = $display['module'] . '_field_formatter_view';
When the field is hidden in the display settings,
$display['module']does not exist. The code should check for that.#24
Here's a right access check - we should not have False positives on NULLs
#25
Next steps:
1) Re-make settings form, probably we need incorporate #1601062-2: Field access plugin ignoring selected value
2) Provide upgrade old settings
3) Fix admin summary
#26
#24 isn't working
#27
@kaizerking what's not working? please explain your case!
#28
Here is the issue where I am getting notices, I have applied patch #24 and also the profile2 ctools patch
notices on page manager
#29
#24 did not work for me. I still have these notice error messages
Notice: Undefined index: module in ctools_entity_field_value_ctools_access_summary() Line 225 in sites\all\modules\ctools\plugins\access\entity_field_value.inc).
#30
Notice from #29 happens if the field is hidden on the entity and thus doesn't use a formatter.
Attached an updated patch that fixes this notice.
#31
#30 works! Great! Thanks a lot!
#32
I suspect I have a related problem. See #1876640: errors and not working selection rule when using negative check on a 'link'field for details. Might be a duplicate, not sure if the cause is exactly the same.
The patch from #30 doesn't solve the problem for me. It least not completely, still get errors in the backend but not on evaluation. So It probably has another (or secondary) cause.
#33
Combining the patch from #30 with the patch from #1780280: Notice on node view page variant seems to remove all notices for me. The selection rules I have tested so far seem to be working also.
Updated patch attached.
#34
Marked #1876640: errors and not working selection rule when using negative check on a 'link'field as a duplicate of this issue.
It really is a duplicate. Patch from #33 fixes it completely.
#35
Great to see access-summary fixed! Now it's ready to be commited
PS: Marked as duplicate #1780280: Notice on node view page variant as this hunk included
#36
Committed and pushed.
#37
The issue needs follow up to fix taxonomy fields when they have autocomplete/multiple values
#38
This patch solves the problem of saving and displaying values entered in the entity field form. Numbers, term references, entity references are tested (both singular and multiple (fixed) values). The remaining issue is multiple (unlimited) value form with 'Add more' button.
#39
#40
+++ b/plugins/access/entity_field_value.incundefined
@@ -103,8 +103,13 @@ function ctools_entity_field_value_ctools_access_settings($form, &$form_state, $
+ if (is_numeric($delta)) {
@@ -131,8 +136,33 @@ function ctools_entity_field_value_ctools_access_settings_submit($form, &$form_s
+ if (!is_array($items)) {
@@ -224,15 +266,58 @@ function ctools_entity_field_value_ctools_access_summary($conf, $context, $plugi
+ if (is_array($elements)) {
Suppose if we carefully massage the values in onSubmit so $conf values could be plain array $delta => $value and no matter how many values are stored.
The only thing to care a Compound fields.
Take care that some widgets accept "multiple values" but some not. This leads to the confusion we have.
Probably better check the field cardinality.
+++ b/plugins/access/entity_field_value.incundefined@@ -224,15 +266,58 @@ function ctools_entity_field_value_ctools_access_summary($conf, $context, $plugi
+ // Choose simple formatter for well known cases.
+ switch ($display['module']) {
+ case 'list':
+ $display['type'] = 'list_default';
+ break;
+
+ case 'taxonomy':
+ $display['type'] = 'taxonomy_term_reference_plain';
+ break;
+
+ case 'entityreference':
+ $display['type'] = 'entityreference_label';
+ break;
+
+ default :
+ // Use field instance formatter setting.
+ break;
Awesome! The way of tokens/substitution does not help here...
+++ b/plugins/access/entity_field_value.incundefined@@ -224,15 +266,58 @@ function ctools_entity_field_value_ctools_access_summary($conf, $context, $plugi
+ if (count($field['columns']) > 1) {
+ // Add some sort of handling for compound fields
Needs @todo here
#41
A small change in this patch: do not output unprintable garbage generated by field formatter.
#42
+++ b/plugins/access/entity_field_value.incundefined@@ -103,8 +103,13 @@ function ctools_entity_field_value_ctools_access_settings($form, &$form_state, $
+ if (is_numeric($delta)) {
+ if (is_array($conf_value)) {
+ $form['settings'][$field_name][LANGUAGE_NONE][$delta]['value']['#default_value'] = $conf_value['value'];
+ }
+ else {
+ $form['settings'][$field_name][LANGUAGE_NONE]['#default_value'][] = $conf_value;
This part is primary required
+++ b/plugins/access/entity_field_value.incundefined@@ -131,8 +136,35 @@ function ctools_entity_field_value_ctools_access_settings_submit($form, &$form_s
+ $form_state['input']['settings'][$field_name][$langcode] =
+ _ctools_entity_field_value_filter_items($field, $form_state['input']['settings'][$field_name][$langcode]);
$form_state['values']['settings'][$column] = $form_state['input']['settings'][$field_name][$langcode];
}
+ if (isset($form_state['input']['settings'][$field['field_name']][$langcode])) {
+ $form_state['input']['settings'][$field['field_name']][$langcode] =
+ _ctools_entity_field_value_filter_items($field, $form_state['input']['settings'][$field['field_name']][$langcode]);
+ $form_state['values']['settings'][$field['field_name']][$langcode] = $form_state['input']['settings'][$field['field_name']][$langcode];
This part needs to be simplified. No reason to bother 'input' here
+++ b/plugins/access/entity_field_value.incundefined@@ -131,8 +136,35 @@ function ctools_entity_field_value_ctools_access_settings_submit($form, &$form_s
+function _ctools_entity_field_value_filter_items($field, $items) {
awesome function but needs php-doc about @params and @return
+++ b/plugins/access/entity_field_value.incundefined@@ -224,15 +269,60 @@ function ctools_entity_field_value_ctools_access_summary($conf, $context, $plugi
+ if (count($field['columns']) > 1) {
+ // Add some sort of handling for compound fields
+ }
+ else {
+ $keyed_elements["@{$column}_value"] = $elements;
+ }
Please change condition to exclude empty statement
#43
The next try. Autocomplete widgets still don't work. Compound fields (with multiple sql columns) seem to work. The full plugin file is attached also.
#44
If a field does not have a value stored at all yet for a particular entity, checking against the '- None -' value (_none) fails.
#45
I'm not convinced about this approach. But, I have taken the follow patch from #43, and added to it some provisions to handle the case where no value is saved for a field.
#46
Probably best to provide interdiffs for reviewers.
#47
Comparing with '_none' or other magic constants is not the right way. I'll provide the improved patch soon (with solves autocomplete fields issue also). BTW, the real fun is permitting to configure the field comparison against file field or field collection field. :)
#48
EclipseGc++
Having interdiffs is much better way to get proper reviews!!!
Suppose it's clear that there's no way to save BC for broken data but after #33 we have in 7.x-dev there's a probability that some sites have working config. So the follow-up code that introduces support for "Compound fields" is really great and better to have it commited before next ctools' stable release.
@mrfelton please explain the difference in your approach. The issue is really needed and annoying same time...
+++ b/plugins/access/entity_field_value.incundefined
@@ -103,8 +103,13 @@ function ctools_entity_field_value_ctools_access_settings($form, &$form_state, $
+ $form['settings'][$field_name][LANGUAGE_NONE][$delta]['value']['#default_value'] = $conf_value['value'];
...
+ $form['settings'][$field_name][LANGUAGE_NONE]['#default_value'][] = $conf_value;
@@ -211,7 +244,19 @@ function ctools_entity_field_value_ctools_access_summary($conf, $context, $plugi
+ $entity->{$field_name}[LANGUAGE_NONE][] = array($column => $conf_value);
...
+ $entity->{$field_name}[LANGUAGE_NONE][] = array($column => $conf_value['value']);
...
+ $entity->{$field_name}[LANGUAGE_NONE][] = array($column => $conf[$conf_key]);
@@ -224,15 +269,60 @@ function ctools_entity_field_value_ctools_access_summary($conf, $context, $plugi
+ field_default_prepare_view($entity_type, $entity_group, $field, $instance_group, LANGUAGE_NONE, $item_group, $display);
+ $elements = $function($entity_type, $entity, $field, $instance, LANGUAGE_NONE, $item_group[0], $display);
Another funny part for localization...
+++ b/plugins/access/entity_field_value.incundefined@@ -131,8 +136,35 @@ function ctools_entity_field_value_ctools_access_settings_submit($form, &$form_s
+ _ctools_entity_field_value_filter_items($field, $form_state['input']['settings'][$field_name][$langcode]);
using $form_state['values'] are solves the problem
#49
I didn't want to derail the patch that's in here (though if people like what I've done it will derail things anyway). However, I was pretty pressed for time and I just wanted to make this work. So without further ado, I posted a patch here: #1955954: entity_field_value.inc is mostly useless.
#50
Okay I'm seeking advice. I was having the same errors as above. I tried the patch in #45 and I still had errors. Then I followed the thread in #49 and applied that patch. The errors continued.
So I did two things that I thought would help. I installed the current dev version and used the patch in #45 and I uninstalled the relationship module (because it uses entity fields).
Now I simply get an error:
So what would your next move be here? I suppose I could roll back a few days, but then I would loose the Views I built.
Any ideas?
#51
Could you try #43?
#52
@maximpodorov -- Sorry, late last night I made the call to just roll back the database, delete the Relationship module and rebuild my Views. However if you want I can email you the broken database.
I wonder if it would make sense to have a "known issues" notice on the cTools project page.
With a full version 1.3 release and no mention of any trouble, "module monkeys" (okay, site builders) like me can land them selves in some devastatingly hot water.
Of course CTools is needed now for Views, but it would nice nice to see a "Known Issue" warning stating that there is a current bug with evaluating conditional fields that causes problems with the Relationship module and autocomplete Taxonomy fields. See (this thread).
Had I read that I would have tread a bit more carefully.
#53
Here is the revised patch. It contains the fix of the problem described in #50. Other small improvements are there. Please test and review.