Made config changes locally (to a view).
Updated the associated Feature locally.
Migrated the updated feature code to production.
Attempting to revert the production feature so the new feature settings are deployed.
Feature simply won't revert and remains overridden.

Why would that be? Is this just weirdness? Is it due to views?

I love features -- but it seems like there's lots of little hiccups like this that are hard for the mere mortal to diagnose. Obviously I could make a small config change on production via the views UI, but that kind of defeats the one of purposes of features, no?

Attached is a diff of the relatively simple changes I was making to a view...Any suggestions/pep talks are greatly appreciated.

Comments

Status:Active» Closed (fixed)

When using views in your features, make sure you clear your views cache AFTER you revert.

This is happening to me with content types/fields, and contexts.
They will not revert, and "overridden" stays next to the component, along with the checkbox.

I only have one feature enabled, so I dont think its conflicting with another feature.

any suggestions?

Version:6.x-1.x-dev» 6.x-1.0-beta8
Status:Closed (fixed)» Active

At first I was reverting twice, which did work. It seems flushing caches immediately after doing the revert does the trick. This shouldn't need to be done manually, therefore I'm reopening this issue. See also #801088: views in a feature still say 'overridden' after I revert them

I am having the same problem when recreating a module to include a new context.

Even after revert attempts and cache clearing, it is still determined to show the Feature as overridden and the diff showing the code as being removed.

It'll probably be useful to include some more information in our statements, like what types of things are in the feature.

My feature that reverts after the cache flush is only a content type with cck fields. Things get a little weird when changing display order of cck fields and other fields because lots of weight attributes get updated, not all of which belong to the feature, but I understand what happens. (Making that more intuitive is another task, and is a general problem with exportables and drag-n-drop weights.)

I haven't used context so maybe I'm way off, but perhaps something similar is going on? Post the diff?

Upgrading to beta8 actually resolved this problem, but only after I had to actually recreate the feature with the new context for to be imported properly.

StatusFileSize
new127.49 KB

The same problem.
Tried 10 times, clear the cache, etc.
Overrides column has additional fields in info:

features[content][] = "page-field_pdf_file"
features[ctools][] = "strongarm:strongarm:1"

See screenshot for details.

I was seeing similar behaviour with features built and deployed on 6.x-1.0-beta6. Even deploying, then recreating on the deployment server and "re-deploying" (ie, uploading the files I'd just generated) didn't resolve it.

I was also seeing issues where CCK fields didn't appear on the node create form after deployment (though they did appear when editing the content type, just not when editing content).

I installed diff module in order to inspect the differences between the features, which was informative and may clarify the "differences" features module is seeing between your feature and the current state of your DB.

I just now bumped up to beta10 just now and regenerated my features; the issue seems to have been resolved with this latest Features beta.

Thought I'd follow this one, too. I too have the "unfixable overridden status" issue but of a different flavor, likely.

Shown in my attached screenshots are two completely unrelated features, both with the same snippet in "Default" that has nothing to do with either of the diff'd Features that I am certain is causing my woes.

Note: I suspect it has something to do with having recently installed and performed a data import with table wizard + schema + migrate.

[edit: I also just tried "drush fu ..." followed by "drush fr ..." and still have those overrides exactly as before]
[edit: I relinquish git merge of any blame, favoring migrate instead (see #12 below)]

Update: My great un-revertable Features are revertable once again! I didn't stick around to confirm that they were in fact being reverted just not being detected as being no longer Overridden, but my culprit was something with Table Wizard (or migrate or migrate_extras-- but the Overridden diff suggests the former). I disabled tw (and with it migrate and migrate_extras) and my Overridden status vanished :D

fwiw, here's a capture with proof when repeated on staging:

[~/public_html/hcf]# drush features
Name                Feature             Status    State
Features Tests      features_test       Disabled
Grants DB           grants_db           Enabled   Overridden
HCF Consultants DB  hcf_consultants_db  Enabled   Overridden
HCF Event Calendar  hcf_event_calendar  Enabled   Overridden
User Profiles       user_profiles       Enabled
[~/public_html/hcf]# drush dis tw -y
The following projects will be disabled: tw, migrate, migrate_extras
Do you really want to continue? (y/n): y
migrate was disabled successfully.                                                                                              [ok]
migrate_extras was disabled successfully.                                                                                       [ok]
tw was disabled successfully.                                                                                                   [ok]
[~/public_html/hcf]# drush features
Name                Feature             Status    State
Features Tests      features_test       Disabled
Grants DB           grants_db           Enabled
HCF Consultants DB  hcf_consultants_db  Enabled
HCF Event Calendar  hcf_event_calendar  Enabled
User Profiles       user_profiles       Enabled
[~/public_html/hcf]#

texas-bronius: I experienced the exact same issue you did, and I tried to fix the same way (drush fu.. fr..) with no luck.
In my case, simply disabling migrate and migrate_extras modules did the trick, no need to disable table wizard.

I'm also using table wizard, migrate, and migrate_extras. Haven't yet tried disabling those. drush fu, drush cc all works for me. Does anyone have ideas as to what in any of those modules would cause issues with Features?

If we're documenting things here, I'll add that a most odd thing is happening to me in a new way: I had been happily developing locally, updating features export code, moving the updated codebase to remote staging, and features-reverting to the new code. Tonight, however, this stopped working for me: I have verified that I am looking at the updated code and the changes are there, but Features will not recognize these as different ("Overridden") and still shows me Default (and prevents me from trying to feature-revert to the new codebase).

[edit:]
Just discovered drush fr <feature_name> --force, but it gave me no joy.
[edit: Was able to resolve my issue somehow, but unfortunately am not sure how-- it involved a db export from staging back to dev where my features changes were originally made (and exported), running features-revert there (where one field was flagged "needs review"), then dumping db back to staging. Looks like all is well again .. for now!]

Has anyone ever seen it where it appears that Features is just not reading the updated .inc code?

Has anyone ever seen it where it appears that Features is just not reading the updated .inc code?

I am using Open Atrium and wanted to override a CCK nodereference field to reference another content type. A very simple change - I just added one line to features.content.inc to match the new setting. However, the field still shows up as overridden! If I diff the "default" and "override", the "default" file does not reflect what's actually in the file on disk. If I revert, it reverts to the "original" default, not the default that I just defined in the file.

What's odd is that if I run drush feature-update [feature-name], the changes are picked up - even though the new features.content.inc produced by Drush is the same as the one I generated by hand.

I'm having this same issue using Features 1.0. I have a feature that contains a view, a couple panel pages and quicktabs, but no matter what I do, the panel pages (page manager) will not revert. If I look in mymodule.pages_default.inc, the code is correct, but when I view the panel, it is the old version. I've tried reverting both through the UI and via drush, but no dice. I've cleared all caches multiple times as well, and disabled migrate, migrate_extras and tw. I can't for the life of me get this feature to revert. Well, just the page manager portion of the feature I guess. Anyone else have this problem related to features and panels?
Thanks!
steve

I am having this issue with Features 1.0 as well. My features package is just a bunch of block contents (boxes) and block-settings.
The blocks themselves become available deployments but the block-settings area remains Overridden no matter what I try.

I'm having a similar issue to #18

My feature refuses to revert, here is a screenshot of the diff http://skitch.com/digital006/dayfr/site-page-structure

http://skitch.com/digital006/dayfm/site-page-structure-feature << Screenshot of the feature

All the modules listed there are up to date and enabled.

The Page Manager stuff also has the same issue, it refuses to revert.

Can we programmatically revert?

I've created a feature package and deployed it. When generating a new site through a custom install profile I've created - I have the feature package I've created automatically enable itself through the install profile.

The problem is, all the Blocks (boxes) do get enabled and I can see them if I go to Admin -> Blocks. My issue is that the block SETTINGS in my feature package never get assigned to them.
(ie. they don't get placed in any region, although the settings are passed in the features package?!)

If I manually go to the new site and REVERT, then they get placed in their correct region - but why do I have to revert? Shouldn't it be automatic when the module is enabled?

This is what I get on my features page on the new site when using DIFF:
DIFF Analysis

What exactly does thsi mean again? the LEFT is what is in the code and the RIGHT is what is in the database?

If my feature package contains the regional (block Settings) INC file, why would it not get deployed when the module is enabled?

Thanks!

@Straddle- The issue you describe sounds similar to my confusion-- see my #14 reply above for more details and possible resolution. Iirc, the features actually _did_ revert, they just didn't get detected as such, and so rebuilding the feature from deployment allowed me to get a "fresh copy" of the feature to pull back into dev and continue thereon out as originally expected.

One word to the wise: Sometimes I reload from remote deployment to keep the freshest dev going, and I use git to ship things back and forth. I think at one point I had confused my workflow with differing versions and didn't really recall that when you do a rebuild from both a db dump and a site dump, you don't _need_ to revert features at the destination in the first place.

I have issues with reverting too - but for taxonomies. See #921982: Features does not detect change to taxonomy when reverting

I'm getting revert problems too.

Features 1.0

A feature with a role and a view.

I change my view, recreate feature, replace old code with new code, verify changes with diff.

Deploy to staging, click revert, nothing. (Try multiple times)
Clearing cache, disable/enable the feature, even deleting the view and importing it manually, NOTHING will get features to pick up the fact that the features code has changed.

Version:6.x-1.0-beta8» 6.x-1.0

I had this issue with roles and context and was able to fix it.

The problem was missing lines in the feature module .info files. So for example, I had a context that was stored in the [feature]_context.inc file, but there wasn't a correponding line in the .info file. Somewhere along the lines it got lost, and I'm not sure where.

I was able to solve the problem by adding the line back in to the .info file. For the context, for example:

features[context][] = "home"

Then I ran a drush fu my_feature and it was good to go. I did the same thing with another feature module that had some role data saved, but didn't have any .info lines for it.

I'm switching the version here to 1.0 since the latest discussion seems to be around that version.

For those that are having issues with views/panels, it'd be good if you checked that the view/panel is also appearing overridden on the views/panel listing page, and try to revert it there. If that doesn't work, it's likely a views/panels issue.

For example, Features uses view functions to delete the in database version of a view.

Straggle: left is sorta what is in code, with some complexities, while right is what is in the database, basically what would go into code if feature updated.

To my knowledge, enable a feature on a site that has had code will not automatically revert it, but it will rebuild, or rather cache clear will rebuild if feature is marked as needing rebuild. Features usually do not provide enable/disable/install/uninstall* hooks, so it does things during cache clear; things that were already existed are detected as needing revert, but won't revert themselves. If features did automatically revert, you'd loose all your customizations each cache clear before ya got a chance to features-update >.O.

A lot of what features provides are 'faux exportables,' which were designed to be exportables originally, so are a bit ugly to work with.

You can add enable/install/uninstall/disable/update hooks to your your module's install file (.install will stay in the folder on drush features-update) if you needed for deployment, or do a mass revert after install modules, etc. I use update hooks.

Using diff module will likely be useful for those that haven't.

#931782: _features_sanitize: Type casting in array comparison causes is_assoc to fail with 1 item assoc arrays may be effecting some, but shouldn't actually effect the feature reverting, just showing as needs revert when doesn't.

Yeah I'm having this problem too. Only way I've found around it is to just disable the feature, delete the page and then re-enable the feature. So far I've just been having problems when I use a new feature to override an existing page on the staging site - we'll see if it keeps happening after deleting the old instance of the page from the db.

Subscribe.

Subscribe.

I agree with greg_harvey when he says that this issue is "a) WAY to generic to be a useful issue title for maintainers
and b) not at all targeted towards a specific issue."
Because Features has several different ways of handling exportables each one has to be bugtested separately, e.g. the code that handles CTools & Panels (greg_harvey's issue) is different to Views, Content Types and many other portions, so each needs its own issue to handle the problems with reverting.

Agreed, DamienMcKenna. For those having problems with **ctools pages not reverting** specifically, please bring discussion over to #813760: CTools Page manager pages do not revert properly

subscribe - all devs in my current shop see this problem regularly.

Category:support» bug
Priority:Normal» Critical

It sounds like we are describing several different ways in which a Feature might not revert. I think this might be better served as a wiki page, because nobody can follow the various scenarios and posted workarounds. I would also like to post another failure to revert scenario, but will wait for a wiki. How about this one:
http://drupal.org/node/986932
Unfortunately, it has sat untouched on my screen for several days, and I won't get back to finishing out in any reasonable amount of time. Please feel free to continue migrating this growing knowledgebase into that handbook page, if it is deemed appropriate to do so.

Version:7.x-1.x-dev» 6.x-1.0
Component:Code» Miscellaneous
Status:Postponed» Active

I added a scenario where a View is stuck showing as "Overridden" when it clearly isn't: http://drupal.org/node/986932

Only project issues are autocompleted tmk.

Please test #931782: _features_sanitize: Type casting in array comparison causes is_assoc to fail with 1 item assoc arrays for that views issue, DamienMckenna

I identified my problem. I had been using hook_views_default_views_alter() to override some existing views from other modules (e.g. OG) but wasn't first verifying the specific view was present in the $views array, I was just overriding them. My fix was to change this:

<?php
function groups_views_default_views_alter(&$views) {
 
// Override some of the default views.
 
$path = dirname(__FILE__) . '/views';
  include(
$path . '/overridden.og.inc');
 
$views[$view->name] = $view;
}
?>

to this:

<?php
function groups_views_default_views_alter(&$views) {
 
// Override some of the default views.
 
$path = dirname(__FILE__) . '/views';
  include(
$path . '/overridden.og.inc');
  if (isset(
$views[$view->name])) {
   
$views[$view->name] = $view;
  }
}
?>

Once I made that change the view no longer listed as Overridden and life was good again.

subscribe

Same here. Using features_revert() in own installation profile, new views were added, but nothing changed for overriden views (such as taxonomy/term/%)

My code sample:

   $revert = array(
    'openstore_content' => array('content', 'variable'),
    'openstore_menus' => array('menu_custom', 'menu_links'),
    'openstore_views' => array('views_default'),
    'openstore_variables' => array('variable'),
    );
   features_revert($revert);
  $clear = array('cache_views', 'cache_views_data');
  $cache_tables = array_merge(module_invoke_all('flush_caches'), $clear);
  foreach ($cache_tables as $table) {
    cache_clear_all('*', $table, TRUE);
  }

Does anybody know how to solve this problem?

@volocuga: If you have overriden default views, then you have to clone them in order to export them properly. Features should have displayed a note about this when you were creating your feature. Apologies if you have already done this, but from the sounds of it, this is the situation you are in.

Name the clone something like custom_taxonomy or whatever it is. In my experience, the cloned view's path/menu settings will take precedence over the default one's, so your site should continue working. If you are using blocks or putting the view in Panels, you will have to update those though.

Component name, not hook name, is what is used when problematically calling features revert.

Component name is the identifier in the .info, views I believe (or is it view? too lazy to look).

<?php
'openstore_views' => array('views'),
?>

@wizonesolutions, @hefox
Thanks, very useful comments

Component name is the identifier in the .info, views I believe (or is it view? too lazy to look).

Say I have the following in my .info file:

core = "6.x"
dependencies[] = "content"
dependencies[] = "nodequeue"
dependencies[] = "simplenews"
dependencies[] = "uc_views"
dependencies[] = "views_bonus_export"
dependencies[] = "views_bulk_operations"
dependencies[] = "views_showcase"
dependencies[] = "votingapi"
description = "Views"
features[views][] = "conditional_blocks"
features[views][] = "data_export"
features[views][] = "discounts"
features[views][] = "news"
features[views][] = "newsletters"
features[views][] = "order_management"
features[views][] = "poll"
features[views][] = "popular"
features[views][] = "product_manager"
features[views][] = "promotion"
features[views][] = "queues"
features[views][] = "similar_products"
features[views][] = "user_cart"
features[views_api][] = "api:2"
name = "Openstore views"
package = "Features"
project = "openstore_views"
version = "6.x-1.0"

The identifier, that meant @hefox shown between "features[" and "][]" and is "views", right?

If you have overriden default views, then you have to clone them in order to export them properly

If I cloned this default view, it becomes a completely different view. Then how will Features know that this newly created view has to override the source default view?

wizeone was refearing to when you want to override a default view that another module supplies; for example, views comes with a disabled taxonomy_term view that supplies overrides for taxonomy/ paths. Since two modules cannot define the same view in hook_views_default_views, they were suggesting a way around that: create a new view and not use the default view.

However, if you're not using a view that is supplied by another module, that is not needed.

(In general to override other module views, I export my view manually and override it in hook_views_default_views_alter (or manually alter the view to my liking), but those are a bit more advanced.)

"views" is the correct component name for views

Thanks hefox. Sounds hardcore :) But yes, that's what I meant.

If you are using blocks or putting the view in Panels, you will have to update those though.

Sounds not good. I've done many modifications based on the view name, for example css classes and template overrides

So I assume that Feature can not override default views at all and I should do that manually :(

@volocuga: Features cannot override a default view exposed by another module, just like you can't have the same view in two different features, it'll cause problems and the view will disappear. What you need to do is add an instance of hook_views_default_views_alter() to your feature and add the view there (or just tweak the few settings you wanted to change); you'll have to do this manually, but there are some tutorials on how to do it if you search around, e.g.:

There is an experimental module in automating that (I have not used it): Features Override

Here's an example usage for hook_views_default_views_alter().

Lets say I have a view named "awesomecontent" that's provided by the awesome.module, i.e. there's a function awesome_views_default_views() which contains the definition for the "awesomecontent" view. I want to change how this view works, so I make a few modifications via the UI and then on admin/build/views it says the view is "Overridden".

There are two ways of getting my changes into code:

Method #1 - Easy

In my own module, e.g. moreawesome.module, I add an implementation of hook_views_default_views_alter(), e.g.:

<?php
/**
* Implementation of hook_views_default_views_alter().
*/
function moreawesome_views_default_views_alter(&$views) {
 
// Only work on the Awesomecontent view.
 
if (array_key_exists('awesomecontent', $views) {
   
// Code goes here.
 
}
}
?>

I then export the view and paste its contents into the above function, inside the if() statement. Note that I've added an if() statement to first ensure that the view actually exists, which helps avoid a bug seen elsewhere. Before I'm done, though, I need to tweak the code slightly, so it would end up looking like this:
<?php
/**
* Implementation of hook_views_default_views_alter().
*/
function moreawesome_views_default_views_alter(&$views) {
 
// Only work on the Awesomecontent view.
 
if (array_key_exists('awesomecontent', $views) {
   
$view = new view;
   
$view->name = 'awesomecontent';
   
// The rest of the definition...
    // Override the existing view with this new definition.
   
$views['awesomecontent'] = $view;
  }
}
?>

A slight alternative is to export the view to a separate file, e.g. "override.awesomecontent.inc", and then load that file, e.g.:
<?php
/**
* Implementation of hook_views_default_views_alter().
*/
function moreawesome_views_default_views_alter(&$views) {
 
// Only work on the Awesomecontent view.
 
if (array_key_exists('awesomecontent', $views) {
    include(
'./override.awesomecontent.inc');
   
// Override the existing view with this new definition.
   
$views['awesomecontent'] = $view;
  }
}
?>

If you do that, just make sure to add the normal PHP opening string (a '<' with '?php' after it) to the start of the file, otherwise it won't load.

After that's all done, just clear the site cache to make the changes get picked up and revert the version in your current site. All done.

Method #2 - Hard

In my moreawesome module I still add an implementation of hook_views_default_views_alter(), but this time I manually change individual settings in the existing view rather than just replacing the whole thing. The first thing to do is work out what to change, and to do this use the Devel module to output the existing data in a readable format:

<?php
/**
* Implementation of hook_views_default_views_alter().
*/
function moreawesome_views_default_views_alter(&$views) {
 
// Only work on the Awesomecontent view.
 
if (array_key_exists('awesomecontent', $views) {
   
dpm($views['awesomecontent']);
  }
}
?>

Then I export the overridden view and compare the values I want with what comes out-of-the-box and make the necessary changes. FYI I've found the best way of doing this is to start recreating the variable hierarchy to get to the setting I want, and then changing the bit I want, e.g. to change the path to the first Page display it would be like this:
<?php
/**
* Implementation of hook_views_default_views_alter().
*/
function moreawesome_views_default_views_alter(&$views) {
 
// Only work on the Awesomecontent view.
 
if (array_key_exists('awesomecontent', $views) {
   
// Change the path to the first Page display.
   
$views['awesomecontent']->display['page']->display_options['path'] = 'moreawesome';
   
dpm($views['awesomecontent']);
  }
}
?>

I left the dpm() in function so I can verify the change happened as I wanted, and once I'm happy with the changes I comment it out or just remove that line entirely.

@DamienMcKenna That's some of the better documentation I've seen for that hook. You should put it somewhere.

@grayside: thanks, I added a handbook page for it: http://drupal.org/node/1014774

Awesome!

Damien, thanks, you posted exactly what I asked for

#16 did it for me.. Drush saves another day.

Thanks Damien!

First-time Features user. I created a feature of 5 content types from Site A. Installed/enabled the feature on Site B, where those same content types currently exist.* Get only feature "overridden". Dumb question, not specified in Features documentation: Should I be deleting all of the content types of Site B first, before employing the content-type features? That doesn't sound right to me. But not clear about Features 'putting code in features rather than database'.

* Simply want my shared content type modifications to be updated on other sites. (Export/Import to existing content type always generates error.)

If this module works as I hope, I intend to marry it.

subscribe

Subscribe

I'm having 2 features exhibit weird behaviour:

feature1: one that won't revert no matter how many times I select Revert checkbox, although the changes appear to be imported
feature2: one that features which do Revert when I check revert, however they are still marked as override although the revert checkbox disappears by itself

In both cases, neither is provide an override tab, nor does the URL feature1/diff provide any output of what exactly is being overridden.

Initially both features had the behaviour of feature1, however the feature2 I manually added an include for feature2.features.inc into the feature2.module which seems to have gotten me a little farther. This trick unfortunately won't work for feature1 as there is no feature1.features.inc to include.

Would the number of fields affect not being able to revert in Features 7.x?

I have a feature with around 50 fields attached to it amongst other things, and sometimes a field will revert and sometimes it won't. I also can't seem to change anything via the Ui in Manage Display / Manage Fields with the feature turned on. It prints out the changed value, but reverts on page load.

I think these two are related, but not sure how to test that.

If my issue is performance-related, then it would be a good idea to use Batch or Queue API for reverting features.

edit: i narrowed down my issue to the fact that at some point features installed a duplicate field_name so it was reverting the field, but that field was not being used because most searches are based off of field_name instead of field id.

subscribe

I just had a similar issue with block settings and content stored in the Feature. It appeared that I had old blocks that were somehow conflicting with the blocks being tracked in Features. I deleted those blocks and could revert without problem.

Example: #1101256: Exporting field without CCK cause non-revertible Overridden status
When Feature has non-revertible Overridden status.

If you have a View that will not revert, also try going into the Views UI (the list of Views) and in D7 you can select "Revert" from the action drop-down menu on the right. After doing this, the view should shows as "in code" on the left.

I had this issue with a specific view where a new display was added by another developer and after I did my "svn update" I could no longer revert the feature either through the Features UI or via Drush features-update. Using the Views interface fixed the view for me.

Also, i noticed that when views ui module is disabled, some features (with views) will not revert. enabling view ui will fix this.

I had this issue with uc_product_power_tools in a feature.

Whenever I enabled my feature, the settings for uc product power tools would be overridden.

here is a screen shot: http://drupal.org/node/1034144#comment-5041552

I think that it might be related.

Subscribe.

subscribe

subscribe

@tinefin- please don't post 'subscribe' comments any more. Instead use the 'follow' link at the top of the page.

I had a feature that would not revert today. It was D7, rather than D6, but I think it's still relevant because of the cause/solution.

I merged two git branches containing different versions of the same Views based feature, each with different displays.

As far as git is concerned, it merged the exported Views code just fine, but it left me with conflicting Views display pages. It took a LOT of poking to find out what was wrong, but changing one of the displays from page_1 to page_2 (and obviously clearing every cache going) sorted it immediately.

So the moral of the story is that Features was not to blame at all. It was bad Views code caused by a normal git merge. So the next time a feature will not revert, I shall be quizzing git and looking at the exported code before blaming Features.

Version:6.x-1.0» 7.x-1.0-rc1
Component:Miscellaneous» Code

I'm also having this problem in latest D7 version - but its the page manager items that won't revert. According to page manager, the panels are running from code. Features can't tell that though, may be related to #1529026: Features is unable to determine the status of my existing features

rc1 is broken with regard to some ctools stuff. rc2 with a fix should be out sooner than later.

Status:Active» Postponed (maintainer needs more info)

Can folks try this with the latest 7.x-1.x-dev code to see if that fixes it?

Version:7.x-1.0-rc1» 7.x-1.x-dev
Status:Postponed (maintainer needs more info)» Needs work

@greggles,

I tried with the latest 7.x-1.x dev and the problem remains. My specific case is a context. It actually appears as though the entire context file is never firing, as the default in features for the context file is:

- FALSE

And the info file's default shows:

- features[context][] = learn_training

Reverting (including trying with a --force flag via drush) does nothing.

Going to flip this back to "needs work."

Status:Needs work» Postponed

Needs work implies a patch; a quick scan shows no patch.

"feature not reverting" is a generalized problem that is caused by many, many different issues that should be their own issue queue post. Only reason to keep this one open is to refer to other ones.

aimEep: features-rc1 was bust and messed up hook_ctools_api, so that is likely related to your context problem.

This is so weird. Even after disabling and uninstalling the feature module, then reinstalling it, the in-code changes aren't being brought into the database.

In my case it is the page_manager_pages which isn't updating.

@shark: Are you sure you have the "include('myfeature.features.inc');" line in your myfeature.module file?

@DamienMcKenna: You saved my day, just been messing around with my feature module and couldn't find why my panel page and view aren't created, then found that missing line you mentioned, added it and now it works. Thanks! Somehow this line must have gotten lost when I recreated the feature module...

Version:6.x-1.0» 7.x-1.x-dev
Component:Miscellaneous» Code
Status:Active» Postponed

@DamienMcKenna - How does the code in #76 compare to this? include_once 'webinars.features.inc'; (or is it the same?) That's what I am seeing generated when I generate my feature.

I have been struggling with the issue described here for a long time on various sites so still trying to determine the cause and if I should open my own issue...

@highrockmedia: They're effectively the same thing, though the include_once() line adds additional internal logic to ensure the file isn't loaded multiple times (which shouldn't happen anyway.

Priority:Critical» Normal

Changing the priority of this since the only reason this Issue is open is for people to read the information about the various reasons a Feature might be stuck on Overridden.

The include_once line mentioned above is automatically added by Features the first time is exports a Feature. However, it is only added if you export something that needs the featurename.features.inc file. If you later add a component that requires this file, Features is sometimes not able to add the include_once, especially if you have ever manually edited the featurename.module file. Perhaps the code that adds this line to the export needs to be improved, but if that is the case then we need to open a separate issue thread on it.

I'm experiencing now the same problem as described in #73 (but in 6.x).
I've the latest 6.x-dev

Status:Active» Postponed

The following description explaining the case when the default Feature returns FALSE. Which is caused by missing include in the .module file.
Not any other scenarios.

Function: features_detect_overrides

<?php
function features_detect_overrides($module) {
// ...
   
foreach ($states[$module->name] as $component => $state) {
      if (
$state != FEATURES_DEFAULT) {
       
$normal = features_get_normal($component, $module->name);
       
$default = features_get_default($component, $module->name);
        if (
$component == 'views') {
         
var_dump($normal, $default); exit; // ADDED DUMP
       
}
?>

In above code features_get_normal() returns normal view, features_get_default returns FALSE.

Within features_get_default(), the following condition returns FALSE:

<?php
       
if ($default_hook && function_exists("{$m}_{$default_hook}")) {
?>

So it seems that hook module_views_default_views doesn't exists, so that means that somehow the required include file module.views_default.inc was not loaded.
But it's loaded correctly for the other features.

The reason for that is the file module.features.inc is loaded for one feature where it works (with hook_views_api hook), but not for the other.

So the main reason of the whole issues is that .module file didn't include .features.inc file.

Working feature (.module file):

<?php
include_once('my_module.features.inc');
?>

Non-working feature (.module file):

<?php
// Drupal needs this blank file.
?>

So now the question is, why the following code failed during export (file: features.export.inc):

<?php
 
// Add a stub module to include the defaults
 
else if (!empty($code['features'])) {
   
$code['module'] = "<?php\n/**\n * @file\n * Code for the {$export['name']} feature.\n */\n\ninclude_once '{$module_name}.features.inc';\n";
  }
  else {
   
$code['module'] = "<?php\n/**\n * @file\n */\n\n// Drupal needs this blank file.\n";
  }
?>

Workaround

You have to add include manually to .module file (see other features).
Example:

<?php
include_once('my_module.features.inc');
?>

Problem

As I understand, the following logic is:
1. If .module file doesn't exist, then create a NEW file
1a. If generated code for .features.inc file is empty, then write '// Drupal needs this blank file.'
1b. If generated code for .features.inc file is not empty, then add the include 'include_once '{$module_name}.features.inc'.
2. If .module file does exist, then copy over (don't touch).

So I think there is the wrong logic here.
1. I'm creating a new feature including e.g. few variables.
2. I'm exporting it, and .features.inc file is empty, because I don't need any hooks, so the .module file is blank as well.
3. Now I've decided to add views dependency and export the feature again.
4. In this case, my feature was exported wrongly, because it copied the old .module which contains blank file, instead of proper include for .features.inc, where I've my required hooks for views.
So in this case my feature is broken, because .module file doesn't include .features.inc to load the views.

Status:Postponed» Active

Status:Postponed» Needs review

I have improved the code that adds the featurename.features.inc file to the export and submitted a patch as per comment #80 above. Please see the new issue thread created here: http://drupal.org/node/1875888.

Same experience as #55. Not using a view, simply content type updates. Fields are not consistent across sites and can't get out of overridden. 1 error is says that a filed already exists in database.

StatusFileSize
new585 bytes

Hello

I had a problem with revert context when you use module metatag. This small patch solves the problem. More info about this bug you can get in this issue http://drupal.org/node/1921344

Status:Needs review» Needs work

Status:Needs work» Needs review

I'm using Features 7.x-1.0 and I'm having issues with features not reverting as well. With my views related features I was able to fix this by manually clearing all the caches but I'm still having issues with features that are being used to capture content types and their fields - specifically a fiend that uses the File Field Sources 7.x-1.7

I changed an image field to include IMCE as a valid file field source and features said it was overwritten. I regenerated the feature and tried to deploy it out to my other sites but it won't take. I try reverting it but it refuses to work. I had to manually make the file field sources changes on each deployment site.

Issue summary:View changes

For those with issues with blocks using Features Extra (FE Block), I notice that the setting it's not filling in on revert is the custom block machine name. When I manually pasted in the machine name, the feature became default.

I did have a separate problem with the block settings for a webform-generated block (which doesn't expose the machine name) not reverting, but I don't know whether it's related.

Status:Needs review» Active

Please open up seperate issue (if haven't already) for any patches/specific instances to fix