I have a feature (built initially before the field base / instance split) and upon regenerating it with the new base and instance values stored, every time I revert it, after some time it will fall back into an overridden state. Unfortunately I'm not entirely sure what prompts this behaviour (I suspect cache clear or cron), but I do get a watchdog message every time this happens:
features 05/21/2013 - 10:10 Rebuild completed for siftgroups_blogs / field_instance. Anonymous (not verified)
features 05/21/2013 - 10:10 Rebuilding siftgroups_blogs / field_instance. Anonymous (not verified)
Just to reiterate - I revert my feature, the field instance settings are then correct in the database. At some point, without any changing of the settings (such as field display or ordering), the feature will become overridden again, in the field instance settings. The attached image is an example. The thing that boggles me is that, if I have reverted my feature, the settings should be equal in code and in the database - so where could these overriding values be coming from?
Other things to note:
* I have patched the module to address the features_exclude issue, so there is currently no features_exclude in my module when I rebuild / revert.
* I have checked my features to ensure there are no other features sharing the same field instance values for some reason.
* I have a custom install profile (I don't actually know much about these, but someone suggested it could be a factor)
Comment | File | Size | Author |
---|---|---|---|
#8 | test.php_.txt | 22.56 KB | tstoeckler |
#6 | stack_trace_23052013-1.txt | 38.96 KB | n_potter |
2013-05-21_1011.png | 35.19 KB | n_potter |
Comments
Comment #1
DamienMcKennaIs there a featurename.features.field.inc file in the feature's directory?
Comment #2
hefox CreditAttribution: hefox commentedSo is the database changing then?
What damien says; if the field.inc is there it and has a different definition for the fields, that could be causing not. If not, If it's happening regular enough, my suggestions is edit field_write_instance (or whatever name of that function), and add a drupal_mail that caches the condition that that field is being updated and mails you a debug_backtrace of what's happening (if field = fieldname and changing it to in way unexpected) drupal_mail())
Comment #3
n_potter CreditAttribution: n_potter commentedThanks both; I removed the original features.field.inc when I updated the module, so that shouldn't be a problem. Will try the suggestion above and see what I get.
Comment #4
n_potter CreditAttribution: n_potter commentedWell, no joy there - the stack trace just gives me the field settings that get changed. But I did notice that the API version was still set to
features[features_api][] = api:1
; trying this on a new feature created in version 1, it was updated to 2 so I am not sure what happened to not make it update - perhaps something to do with the fact that it used a field split? Unlikely.Comment #5
hefox CreditAttribution: hefox commentedWhat is calling th update function? debug_backtrace() should show you exactly what is calling what to get to the update
Comment #6
n_potter CreditAttribution: n_potter commentedI've attached the stack; apologies but the backtrace function dumps the contents of all the arguments so it's huge. I have extracted each function called from the dump in order below, but see the attached text file for the full stack trace with arguments:
siftgroups_blogs_field_update_instance
call_user_func_array
module_invoke_all
field_update_instance
field_instance_features_rebuild
call_user_func_array
features_invoke
_features_restore
features_rebuild
features_flush_caches
call_user_func_array
module_invoke_all
system_cron
call_user_func_array
module_invoke
drupal_cron_run
I looked briefly at the stack trace for when I manually update a field's display setting and most notably was the absence of the cron functions and rebuild functions....
So I think that clearly shows that the features over-ride upon cron run; the presence of the
field_instance_features_rebuild
function seems to be the perp. I'm not sure about the "rebuilding" status but I'm aware that it's rarely seen in the GUI. On several occasions I have looked at the feature to check for overrides and seen this state in the GUI.I would also note that it is the field instance settings that override each time this happens - in particular, the field's display settings - they will override to having a label of "above" and a display of "hidden", despite being set, in code, to label of "hidden" and a visible display. What I conclude from this is that they seem to be overriding to the default state of any field when added to a content type - the field is not immediately visible and will be given a label by default.
So, the settings that are overridden may not be stored in some other module or database entry, but simply that when the feature rebuilds, the Field API goes "Oh, I'm going to ignore the settings in the feature and create this field with the usual defaults".
ADDENDUM: The problem I'm having is particular to this feature, which was created quite some time ago (early 2012, with a much older version of Features 1), so if the above seems standard then perhaps I should rebuild the feature completely.
Comment #7
tstoecklerI've hit this problem as well, today.
I might be mistaken and I've actually hit a different bug - in that case I apologize for spamming this issue - but I think it's the same one.
The symptom was the same: That I could not successfully revert features. I did not get any errors, but the database did not get updated. The concrete case was a field instance of a phone field (http://drupal.org/project/phone) was not getting updated. I had changed the field settings in code, and they didn't get updated in the DB. The special case here is that there is a deep nesting in the settings ($instance['widget']['settings']['country_options']['country_codes']['country_selection']['AC']) and also a *lot* of settings due to the list of countries, i.e. the field instance takes a big chunk of memory. I suspect one of these is causing the following bug:
In
features.field.inc
, line 298:I've dumped
$field_instance + $existing_instance
into a variable and checked that the result is in fact *not* equal to$existing_instance
. However,$field_instance + $existing_instance != $existing_instance
yields TRUE. This seems like a PHP core bug, but I don't know very much about internal array comparison (or PHP internals in general) so I'm posting this here.Comment #8
tstoecklerHere's a test script to prove the weirdness:
The relevant part is:
the return is:
Comment #9
hefox CreditAttribution: hefox commentedMentioned line is now a strict comparison for likely reason described, back to postponed
Comment #10
mvcStill a bug. Consider the following value in field_config.data:
In this case I uninstalled the i18n_taxonomy module and removed the options_list_callback value i18n_taxonomy_allowed_values from the exported feature. When I revert the feature the database is not changed and any call to drupal_get_form() for this node type (eg. at node/add) will fail with "PHP Fatal error: Call to undefined function i18n_taxonomy_allowed_values() in .../modules/taxonomy/taxonomy.module on line 1499".
I'm working on a patch.
Comment #11
mvcComment #12
mvcHmm, spoke to soon. Features can't do this because core's field.crud.inc doesn't actually permit this: #937554: Field storage config entities 'indexes' key
This module could go modify field_config.data itself but I've written a single-use script to do that for my client. Fixing this in the general case will have to be left as an exercise for the reader. Otherwise, this can be fixed here if and when it gets into core.
Here's my script, in case it's useful to anyone: https://gist.github.com/m-v-c/e0653b7d1c1156999371
Comment #13
PolHi @mvc,
Thanks for your patch.
I showed it to a colleague and he says that you should also set the language to a default language then.
Is it not done on purpose ?
Thanks.
Comment #14
mvc@Pol, that wasn't necessary for my particular use case, because I was removing locale and i18n and making a unilingual English site. Hopefully the script I posted will serve as a starting point for you to create a fix specific to your site, but a proper fix is blocked pending a patch for the Drupal core issue I linked above.