I am finding features to be too buggy for production yet, although I really like what it has to offer. I would like to unlink all the pieces of my site that I had put in a feature, so they're just regular site items, and then I could uninstall the feature followed by the feature module. Is there a way to do this without breaking a site or having to redo all of the work (re-creating content types and so on)?
Thanks

Delphine

Files: 
CommentFileSizeAuthor
#72 fco-663136-72.patch12.47 KBbasvredeling
PASSED: [[SimpleTest]]: [MySQL] 40 pass(es).
[ View ]
#67 features-consolidate-663136-67.patch21.21 KBdsnopek
FAILED: [[SimpleTest]]: [MySQL] 35 pass(es), 5 fail(s), and 3 exception(s).
[ View ]
#50 features-consolidate-663136-50.patch21.44 KBJan van Diepen
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch features-consolidate-663136-50.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#49 features-consolidate-663136-49.patch12.69 KBJan van Diepen
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch features-consolidate-663136-49.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#47 feature-persist-663136-47.patch7.39 KBlex0r
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch feature-persist-663136-47.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#46 features-import_back_to_database-663136-46.patch10.48 KBdamien_vancouver
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch features-import_back_to_database-663136-46.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#43 features_663136_hook_features_import.patch10.44 KBhefox
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch features_663136_hook_features_import.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Status:Active» Fixed

The easiest way to do this is to override your views, node types, etc (this will store a copy of them in the database) and then simply disable or delete your feature module.

I would recommend taking a backup of your feature module & database just in case.

Thanks! I will try that.

As a side note, I find features a great way to migrate a bundle of capabilities between sites and keep track of dependencies. It would be great to have an option for each feature to "unlink" it - for example if there will be lots of changes to it, or if one wishes to remove a dependency (currently the UI allows to add views/dependencies but not remove them). Essentially something that would copy everything to the site then automatically disable the "source" feature.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

A comment as to what was my problem: there was no way to switch the node types to "overridden" regardless of the changes I made to them. Everything was in the database but when disabling the feature it would break. I ended up going to the database and in the node_type table changing the following fields: module: features->node ; locked: 1->0 ; custom: 0->1; modified 0-> 1
After that even though the "node" section would not show as overridden, disabling the feature would not break the site anymore.

+1 Easily unlinking features would be a good improvement. At the moment, it is difficult to uninstall Features once it has been used to import a feature. It is even difficult to disable or override features that are not needed anymore, for example, imagecache presets created with features cannot be disabled or overriden.

Any further progress on this?

We issued features to our users.. but then they heavily modified the content type and view. We fear that we we no longer use features because our users change it away from what we provide.

I am now looking to take existing sites and disconnect the content-type and view without breaking anything when we remove features from their site.

I will play with: "node_type table changing the following fields: module: features->node ; locked: 1->0 ; custom: 0->1; modified 0-> 1"

pulling it down to a local copy to see what breaks.. if anything.

@#neofactor this particular version of this issue is closed, and not really where recent discussion has been taking place.

The fact that your customers are overriding your features has nothing to do with Views-they could override any site that you provide them. It sounds to me like the solution to your problem would actually be some kind of functionality to lock down any UI for values your features provide. That is quite likely to require custom coding with or without Features.

Thanks... but at this point I am trying to understand how to unlink features and let the content type and views keep working.

It looks to me like CCK is the thing being broken when turning off features. I need to figure out how to re-enable the content type with features off.

You need to delete CCK fields in an update function after deleting it from your feature. Anything except explicit field deletion risks data loss for users not trying to delete a field.

I am not sure I am explaining the situation for you.

1) I had built features that users have used in a mulitisite instance.
2) They have modified the delivered content type and views beyond what I provided.
3) I would like to get rid of my features install completely since it is not really being used and is out of date.
4) I would like for the end user's content type and views to keep working when features module is removed.

Any ideas on how to do this?

I guess I am stuck... I will just have to clone each of the views and content types out.. delete the features and then re-apply each.... too bad... this might cause a collision in machine names I fear.

There has to be an easier way to push out pre-built setups / "features" without having a dependency on the created "module".

You are not intended to remove the features module. You are intended to do your best to run the features from code, and need the features module to facilitate that.

As it stands, features is not intended as a method for one-off configuration deployment. Once "features unlinking" is put together as a feature, it will be possible to use Features in that way.

Is "features unlinking" on the books to be implemented?
If so... any insights as to how to manually do it now?

There are a number of issues about it, and I think someone is interested in it, but I can't find the primary issue because it's one of those topics that people think of in different terms and so can't find each other. For example, unlinking vs. severing vs. "remove feature".

I think the most compelling use case is facilitating upgrades #1014522: Upgrade existing features to D7. I believe the Patterns module was written more with simple transferring configuration to another site.

Seems like the Patterns project is being merged into the http://drupal.org/project/configuration project.
Neither are gearing for D7 and are both at beta for D6.

Will look into them... and contribute to try and keep them alive if a similar function will not reside within Features.

Thanks.

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

There is so much activity here ... marking this as active again. For me #1 is not a practical solution. Mark this as duplicate if you found the original one.

What's really called for is a programmatic version of #1.

subscribe.

+1 my interest is in refactoring features.

Priority:Normal» Major

I have the same problems.. actually I think this is a major issue since not letting users choose to stop using features is very harsh..

Actually I'm using D7 features Beta 2 and I'm currently overriding as much things as I can in order to be able to disable a big backup-feature without breaking my site.

EDIT: I disabled and uninstalled the feature and almost everything seems fine, the only thing I noticed is that I still cannot delete all of my content types..

Greetings Wappie

subscribe

subscribe

Hi,

I am not absolutely sure that this will work, but there is a little known project called briefcase, which does export to files. If I remember correctly it also works with things run from code. (basically views +all ctools exportables could be supported).

http://drupal.org/project/briefcase

The workflow would then be:

Export all to briefcase, disable feature, import data from briefcase, reorganize.

Best Wishes,

Fabian

@Fabian that's an interesting workaround, but I think relying on another export-to-code module is clearly a taped together hack.

Looking at how Briefcase handles the data import and applying any lessons to Features directly may be interesting.

@Grayside: I do agree, but I posted this as is (and also differently in two issues) as:

a) There are people outside here that need this functionality now

b) Briefcase is a really simple module, which can be used as a model for features

And the important part is getting the import functionality to work in features, which works fine in briefcase.

Best Wishes,

Fabian

subscribe
struggling with too much dependency and by uncluttering nodetypes disappear.

I'm following the advice as per #1, but I was having trouble to override the content type, because it was "system defined" so it still got deleted upon disabling the feature. (I believe I used a feature that had created the content type in the first place).

Is there a way to override a system-defined node type so it doesn't get deleted? For now (testing) I made a new node type and converted existing nodes to the new type using node_convert.

#27 locked some thoughts into place for me.

drush features-import allows you to specify a feature. Each component of that feature will be saved to the database one at a time. Exported components that do not support being run from the database will be seen as red flags and will not be affected. Similarly, the developer is on their own for non-features export code.

Importing exported node types will probably involve invoking the feature's hook_node_info() implementation and saving the resulting node types to the database using node_type_save().

After the command is run, the feature should be disabled and the cache cleared. Because custom code in the module might need to be moved, the features-import command should not handle the module disabling.

I looked into the database. In the database these node types in the table node_type have the field value 'module = features' while normal ('system defined') node types have the value 'module = node' and locked = 0.

So something like this should probably work:
UPDATE  `node_type`  SET  `module`  =  'node', `custom`  =  '1', `modified`  =  '1', `locked`  =  '0' WHERE `node_type`.`type`  =  'YOUR_TYPE';

I can concur with hanno that changing node_type.type from "feature" to "node" will prevent it from being deleted when the feature is deleted.

I believe what is forming in #1014522: Upgrade existing features to D7 will cover this, aye? nay?

@hefox, this is a specific feature that seems important for the issue you linked. I've been treating #1014522: Upgrade existing features to D7 as a meta issue for which this is one worthy component.

Subscribe.

Assigned:Unassigned» febbraro

A patch for this is in the other issue queue, last I looked at the issue. Should it be transferred here? I'm weary about moving a patch as loose people to review, etc.

However, though this feature may help to fix a bug, being that this is a feature, and features go in 7.x first, does this feature need to go into 7.x first than be backported? Need to ask febbraro or such.

Hi all , i create a module that add to an unlink functionality to features module.

http://drupal.org/project/ftools

right now we support boxes views and rules.
We will add support for the menus, context, cck in the near future.
The module is still in beta and need testing and code review.

In general what we do is to put all the elements that we remove from the feature in an unlink file (feature_name.version.unlink.inc)
And create an admin page where you can execute the file and import the elements to the DB.

Anyone how could test the module and write is opinion about it is welcome.

thanks.
perelman yuval.
www.linnovate.net

Hi all , i create a module that add to an unlink functionality to features module.

http://drupal.org/project/ftools

right now we support boxes views and rules.
We will add support for the menus, context, cck in the near future.
The module is still in beta and need testing and code review.

In general what we do is to put all the elements that we remove from the feature in an unlink file (feature_name.version.unlink.inc)
And create an admin page where you can execute the file and import the elements to the DB.

Anyone how could test the module and write is opinion about it is welcome.

thanks.
perelman yuval.
www.linnovate.net

+1. subscribe. Going to test the briefcast and ftools modules, as well as the manual overriding and disabling workarounds in the time being.

Related issue:
#1367240: A clear mental model on how feature components should act on uninstall/disable

Just asking now:
What happens if I remove everything related to features from the *.info file, and then disable and uninstall?
Will this remove the feature module from my system, without removing whatever functionality it created?

Hi donquixote, in generel if your feature element is on the code, it will be removed from your site.
because the element set in the code and not in the db, so once you disable the feature the element is gone.
featrue dont know to write your feature elements back to the db.
i write a small module that help to unlink features elements so they can be disabled safely.
@see http://drupal.org/project/ftools
we also make a screencast that can help to understand how the uinlinking works.
@see http://www.youtube.com/watch?v=UaGhMgWH8nk

@perelman.yuval
Thanks, this was not obvious to me so far from reading the docs!
Could you add your wisdom on #1367240: A clear mental model on how feature components should act on uninstall/disable ?
It would be great if future docs can be more clear about this.

@perelman.yuval that is only correct for true exportables. Faux-exportables, such as CCK fields and taxonomy terms are stored and run from the database, and will typically get stuck there if the code vanishes... unless it doesn't.

A clean removal of those elements is not simply deleting code.

Having support for unlinking of content_types, including CCK would be extremely helpfull. I need to transport some large contenttypes (many cck_fields) to another site and import is not working for some reason (ends up in WOD). We have been working on several complex sites and only recently discovered the possibilities of features. Due to the iterative development approach we use working with the preferred features workflow (dev->staging->production) does not work for us. We need a kind of roundtrip engineering, where newly developed features on client-sites can be put back into the development site (which acts as a kind of blueprint for client projects). I think features is a great module, but the lack of unlinking feature for content and views makes it more difficult to use. Features tools looks promising, but no content/cck and views support there.

I have tried several scenario's, only #6 has been working for me so far.

Title:Unlinking views, items, and so on, from features?Provide way to Import views/true exportables back to the database
Version:6.x-1.x-dev» 7.x-1.x-dev
Category:support» feature
Status:Active» Needs review
StatusFileSize
new10.44 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch features_663136_hook_features_import.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Moved from #1014522: Upgrade existing features to D7 and altered; added a hook_features_import_status so can tell whether the item can be imported or not.

Hi @ablommers.
Ftools can unlink views elements on D6 and D7(If it dont work for you please open an issue.)
For the content type support i will add it soon (i think i will start with D7 fields, but i know a lot of sites were built in D6 so i will try to find time for that to).

@grayside you are right.
what do think is the right why to unlink CCK/FILEDS elements?

Assigned:febbraro» Unassigned
Status:Needs review» Needs work
StatusFileSize
new10.48 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch features-import_back_to_database-663136-46.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I would like to import features back to the database as well.

My use case is that I started with a multisite setup and both sites were more or less identical at the start, sharing features for content types, views, menus, etc. Over time though, then their needs have diverged, the features are heavily overridden on the second site.
I would now like to refactor my features on the second site (including the stuff that isn't overridden).

So... I re-rolled the patch from #43 for 7.x-1.x-dev. Unfortunately though, I am seeing some errors. Importing a feature with nodes and field groups gets me:

drush fi example_content_types
Attempt to assign property of non-object export.inc:188     [warning]
PHP Fatal error:  __clone method called on non-object in /www/sites/all/modules/field_group/field_group.module on line 1529

I also tried with a view, and got a similar error (though not on all the view features I tried, only some):

drush fi example_views
PHP Fatal error:  Call to a member function save() on a non-object in /www/sites/all/modules/views/views.module on line 1634

So.. it definitely needs some (or a lot) of work still. I am just exploring my options right now, I might be able to just override each feature as I don't have that many. I may hack on this patch some more if I find myself painted into a corner and desperately needing this functionality.

Re-rolled patch attached. I'm setting this issue to Needs work and unassigning it to febbraro for now, as it's been sitting for quite a while.

StatusFileSize
new7.39 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch feature-persist-663136-47.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

My 5 cents to this issue. I used an alternative approach (probably not as nice and generic). It does the job and we can save all "hook_default_X" defined items (currently these are images styles, views and page manager pages/handlers) to database. Any feedback is welcome.
I performed some testing and no issues were revealed with this patch.

lex0r: looks like a good start, but I'd like to see a more modular approach that uses drupal hooks to call functions within the specific component *.inc files rather than having a hardcoded select statement. One hook could query a component to find out if it can be persisted (controlling the addition of the Persist option), and another hook could actually perform the work of persisting the component.

Version:7.x-1.x-dev» 7.x-2.x-dev
StatusFileSize
new12.69 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch features-consolidate-663136-49.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I combined the work done on Upgrade existing features to D7 and Provide way to Import views/true exportables back to the database.

So basically I,

  1. added links and a tab for consolidating a feature through the ui
  2. changed the drush aliases from fc (which is already in use) to fco and changed fca to fcoa to be compatible with the other alias and added fco-all to comply with preferred coding practices
  3. fixed a bug in features.image.inc.
  4. fixed 2 hook implementations in features.node.inc. Changed node_features_disable to node_features_disable_feature and node_features_enable to node_features_enable_feature. See function _features_restore in features.module.
  5. fixed function node_features_consolidate(). Somehow the original code failed to update the database. Copied some code from node_features_disable_feature and adapted it for the required purpose.
  6. fixed a bug when reverting a feature without selecting any components. When clicking "Revert components" on any feature without selecting any components to be reverted all features got reverted. Fixed it in function features_admin_components_revert().

I ran some manual tests on image, field and node.

Some notes on my experiences:

  • Node types seem to always be stored in the database unless you remove it through the ui.
  • The comment body field instance is added to a comment automagically (with default settings) when it is not provided in the feature. if it is provided in the feature, or an other feature for that matter, the default settings are overwritten by the ones in the feature.
  • When reverting a feature with fields the field definitions are stored in the database never to be removed unless you remove them through the ui.

You have to patch against the latest development release 7.x-2.x-dev.

StatusFileSize
new21.44 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch features-consolidate-663136-50.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

The work done on Upgrade existing features to D7 aslo included an include file for views at includes/features.views.inc. Although I do not believe the code should be in the features module, but in the views module, I ran some manual tests on this code. Views are consolidated into the database, but I ran into an old bug that is described at Feature-packages appear overridden when they are not. To be accurate, The views component is overridden initially. Immediately after clearing the cache its status turns to Default. After updating the page the views component is overridden again. When reviewing the overrides the Default for the views component just shows 'FALSE' on Line 1.

There is a simple patch posted in June 2011 in the aforementioned issue. This leads me to conclude that a difference between Default and Overrides is introduced somewhere in the code. However, I was unable to pinpoint it. Maybe there is somebody out there that can help with this?

Please find a new patch against the latest dev 7.x-2.x-dev that also includes features.views.inc.

For what it's worth, I'm thinking of writing some automated tests for the new code.

Just gave the patch in #50 a shot.

Couple things:
- I had to "touch includes/features.views.inc" in order to get the patch to apply, since that file was missing (in this case, touch just made a blank file from the command line). Hopefully that helps someone else playing with it - not sure if that's to be expected or not, but it worked.

- The implementation of hook_features_consolidate() for views wasn't being called for me when clicking the 'consolidate' tabs/links. In features.views.inc I needed to rename the function views_features_consolidate to views_view_features_consolidate

Afterwards I tried consolidating several features with content types, contexts, image styles, and views - everything seemed to work great. I consolidated, then disabled those features and all of the expected components were still present and appeared to be the same version that was active before disabling. It's still pretty early in my testing on a large site to be sure, but so far so good.

One thing that hasn't worked is consolidating a feature with display suite settings/fields/layouts etc - but it looks like there is no handler in place for this yet.

@Jan van Diepen - I'm not sure if I am fully understanding the views bug you're describing in #50, but I don't think I was reproducing it in my testing. At the very least, consolidating a feature with views in it seems to have worked without mishap.

Think I've found an alternative solution to get your exported objects back into the database so you can safely disable/remove your features.

1) Export everything you want in the database using CTools Bulk Exporter (admin/structure/bulk-export). Put the module it generates into your modules folder (eg. my_exports_module)
2) Disable the features containing the objects you just exported
3) Enable the module CTools Bulk Exporter created for you
4) Download Drush CTools Export Bonus & enable it
5) Run the following drush command: drush cbsa my_exports_module
6) Disable my_exports_module

Tested this with view modes/fields/... created in Display Suite - everything went better than expected :)

hmm, what "features-tools unlink" actually does is in essence the same as described in #52.
(difference: features-tools says to handle less exportables)

Yes, and it seems more time consuming to use "features-tools unlink" than to do what #52 suggests. Or am I wrong? Really looking for a better solution here, particularly because I inherit sites that use Features for no reason, and I just want that stuff back in the DB. Either for upgrades from D6 > D7 or for maintenance purposes. Thanks!

#52 I do not see taxonomy or any field definitions or content types in the list of exportables.

Should they just show up under the bulk exporter tab? Or did I misunderstand?

@#55 those are faux-exportables and in db anyway.

Instead of CTools Bulk Exporter, I used Drush CTools Export Bonus.
Here is what I did on a site today to get rid of all five of my custom features [on a Drupal 7 site]. So far, everything seems to work well. Haven't tried this on a D6 site yet. I was able to delete my features from the modules folder. I also deleted the newly generated ctools exports after importing them to the db. Only do this on a test site:

$ cd .drush
$ drush dl drush_ctex_bonus
$ cd mysite
#export all known ctools exportables of a site to a module:
$ drush ctex mysite_exports
Select to proceed
[0]  :  Cancel
[1]  :  Export everything
[2]  :  Make selection
1
Successfully written drupal7/sites/all/modules/ctools_export/mysite_exports/...
#see what we got:
$ ls drupal6/sites/all/modules/ctools_export/ctex mysite_exports/
  mysite_exports.box.inc
  mysite_exports.context.inc
  mysite_exports.ctex_bonus.aliases.inc
  mysite_exports.ctex_bonus.blocks.inc
  mysite_exports.ctex_bonus.ctypes.inc
  mysite_exports.ctex_bonus.dateformats.inc
  mysite_exports.ctex_bonus.fields.inc
  mysite_exports.ctex_bonus.filters.inc
  mysite_exports.ctex_bonus.info.inc
  mysite_exports.ctex_bonus.menus.inc
  mysite_exports.ctex_bonus.roles_and_perms.inc
  mysite_exports.ctex_bonus.variables.inc
  mysite_exports.ctex_bonus.vocabularies.inc
  mysite_exports.ds.inc
  mysite_exports.feeds_importer_default.inc
  mysite_exports.flexslider_default_preset.inc
  mysite_exports.info
  mysite_exports.install
  mysite_exports.metatag.inc
  mysite_exports.module
  mysite_exports.strongarm.inc
  mysite_exports.views_default.inc
#enable new module
drush -y en mysite_exports
#save all configs to db:
drush -y cbsa mysite_exports
#Done. Don't need it any more:
drush -y dis mysite_exports
drush -y pm-uninstall mysite_exports
rm -rf drupal7/sites/all/modules/ctools_export/mysite_exports

I can now safely disable, uninstall, and delete my custom features!

Note that 'drush dl drush_ctex_bonus' might incorrectly install into your modules folder. It is not a module. Put it in the .drush folder.

This is similar to #52 but I don't understand why he was using both the Drush CTools Export Bonus and the CTools drush bulk export command.

Thanks, Ken. That's about as simple as it seems to get. IMO Features are great for developers, but not so great for clients. Not the best to hand-off to clients w/ features, that is. I used this method, and it works really well. Thanks for sharing the solution with us! -Kevin

Will second the attaboy to kendouglass #57; just tried it, works like a charm.

Component:Code» Documentation
Category:Feature request» Task
Issue summary:View changes
Status:Needs work» Reviewed & tested by the community

The recipe in #57 should exist somewhere on one of the project's documentation pages. There should also be a link to it from the main project page. Something like this would be good:

To remove features from code contained in Features modules, and instead place them back in the database, follow the [link] recipe.

Status:Reviewed & tested by the community» Needs work

The last submitted patch, 46: features-import_back_to_database-663136-46.patch, failed testing.

Status:Needs work» Reviewed & tested by the community

Silly bot.

Status:Reviewed & tested by the community» Needs work

improper use of rtbc, open a new issue if want to create a handbook page and about it for now, but please, can someone reroll the patch so features could easily provide this commonly asked for functionality. It's not a hard patch (I just don't need it) ;_;

I suppose Features could implement this, but perhaps it's not necessary given that drush_ctex_bonus already does it? That was my point, but now I'm thinking that the functionality should be part of Features because things that can be built with it should be taken down with it.

Thoughts anyone?

I think features should provide the UI for this process - clean up/garbage collection is usually the responsibility of the one who made the mess. The drush_ctex_bonus is a cool alternative if you like, but the process itself still feels a bit like an unsupported hack when it comes to your features.

Personally, I think the patch in #50 was a great start as well as simple to use.

Lastly, it's worth noting (I believe) that drush_ctex_bonus does not allow all feature types to go back into the ether, so having some control over future improvements might be nice.

Maybe we can utilize the drush_ctex_bonus code in someway - like as the dependency of a sub-module built for this cleanup process, that way it can do a little more and can be maintained on the features side.

Just my thoughts.

Per colan's RFC #64: Anything that makes major changes to a site (and Features is major) that is *potentially* reversible, *should be* reversible. We needed to undo D6 Features before upgrading to D7 (and did, using a "features-consolidate" drush command from a posted patch), and while D7 Features were an invaluable part of our D6->D7 transition, part of the cleanup was removing "temporary" Features (which we did using the script in #57, above). So Features should absolutely implement the reverse action.

StatusFileSize
new21.21 KB
FAILED: [[SimpleTest]]: [MySQL] 35 pass(es), 5 fail(s), and 3 exception(s).
[ View ]

Attached is a straight re-roll of the patch from #50 against the latest Features 7.x-2.x. I haven't had a chance to test it and I noticed there were some suggested fixes in #51 and maybe others.

Status:Needs work» Needs review

Let's see what the testbot says - does this break anything in features?

Status:Needs review» Needs work

The last submitted patch, 67: features-consolidate-663136-67.patch, failed testing.

in reply to #65
If this needs a UI I'd suggest every feature on the features admin page has an extra option under the "actions" column called "consolidate". Pretty simple. The result screen should give a summary of what has been consolidated. Perhaps the feature detail screen (needs review / revert) could possible also give a status of is the "consolidation status" (ie, does the exportable exists only in the database, only in the code or both?).

This issue with features has become a major impediment to upgrading from 6.x to 7.x. Suggestion #70 is highly needed.

StatusFileSize
new12.47 KB
PASSED: [[SimpleTest]]: [MySQL] 40 pass(es).
[ View ]

rerun of patch #67 still untested (included missing views.inc in patch)

Status:Needs work» Needs review

Status:Needs review» Needs work

So, the patch passed tests... but it messes up the Feature Update procedure. It writes the hook_views_default_views() to the MYFEATURE.features.inc instead of the MYFEATURE.views_default.inc. Didn't bother to check what else was wrong with it and rolled back the patch to prevent duplicate function declarations.