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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yhahn’s picture

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.

pimousse98’s picture

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.

pimousse98’s picture

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.

jmseigneur’s picture

+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.

neofactor’s picture

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.

Grayside’s picture

@#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.

neofactor’s picture

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.

Grayside’s picture

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.

neofactor’s picture

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?

neofactor’s picture

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".

Grayside’s picture

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.

neofactor’s picture

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

Grayside’s picture

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.

neofactor’s picture

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.

osopolar’s picture

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.

Grayside’s picture

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

doublejosh’s picture

subscribe.

infojunkie’s picture

+1 my interest is in refactoring features.

Wappie08’s picture

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

Maciej Lukianski’s picture

subscribe

atolborg’s picture

subscribe

Fabianx’s picture

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

Grayside’s picture

@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.

Fabianx’s picture

@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

Hanno’s picture

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

ar-jan’s picture

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.

Grayside’s picture

#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.

Hanno’s picture

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';

earthday47’s picture

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.

hefox’s picture

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

Grayside’s picture

@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.

Niklas Fiekas’s picture

Subscribe.

hefox’s picture

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.

perelman.yuval’s picture

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

perelman.yuval’s picture

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

mrfelton’s picture

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

donquixote’s picture

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?

perelman.yuval’s picture

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

donquixote’s picture

@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.

Grayside’s picture

@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.

ablommers’s picture

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.

hefox’s picture

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
FileSize
10.44 KB

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.

perelman.yuval’s picture

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).

perelman.yuval’s picture

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

damien_vancouver’s picture

Assigned: febbraro » Unassigned
Status: Needs review » Needs work
FileSize
10.48 KB

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.

lex0r’s picture

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.

mpotter’s picture

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.

Jan van Diepen’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
FileSize
12.69 KB

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.

Jan van Diepen’s picture

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.

justindodge’s picture

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.

rp7’s picture

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 :)

geek-merlin’s picture

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

Kevin P Davison’s picture

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!

SocialNicheGuru’s picture

#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?

geek-merlin’s picture

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

kendouglass’s picture

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.

Kevin P Davison’s picture

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

rjlang’s picture

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

colan’s picture

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.

colan’s picture

Status: Needs work » Reviewed & tested by the community

Silly bot.

hefox’s picture

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) ;_;

colan’s picture

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?

justindodge’s picture

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.

rjlang’s picture

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.

dsnopek’s picture

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.

dsnopek’s picture

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.

basvredeling’s picture

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?).

emilianodelau’s picture

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

basvredeling’s picture

FileSize
12.47 KB

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

basvredeling’s picture

Status: Needs work » Needs review
basvredeling’s picture

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.

hefox’s picture

mmm, I really don't like the use of consolidate here

1. make (something) physically stronger or more solid.
2.combine (a number of things) into a single more effective or coherent whole.

geek-merlin’s picture

(#74)> but it messes up the Feature Update procedure...
that's strange. do you have any idea what to fix?

(#75)> mmm, I really don't like the use of [the term ] "consolidate" here
+1 for a better name.

i suggest we can process these sub-issues
* fixing the patch
* finding the best naming
independently, maybe improving the patch with the "consolidate" strings while keeping in mind to check the naming before a commit.

basvredeling’s picture

regarding (#74)> no, I've got no idea, might have something to do with changes to hook_views_api() since the upgrade. I'd have to dive into it.

(#75)> renaming is fine by me so long as we can move this issue forward. My suggestions:

  • revert to "feature-import" (fi)
  • feature-fuse (ff)
  • feature-merge (fm)
  • feature-persist (fp)
Fabianx’s picture

As we have feature-export I am all for using feature-import(-all) / fi and fia to keep the common export,update,revert,import scheme.

I don't see the re-import for the ctools backend, yet. Will this come in a later patch?

And nice that ctex_drush_bonus supports something like it.

stefan.r’s picture

Status: Needs work » Needs review
FileSize
12.24 KB

Re-rolled and renamed to features-import

stefan.r’s picture

Status: Needs review » Needs work
Related issues: +#1014522: Upgrade existing features to D7

features.views.inc slipped back in here but won't be needed, the views logic can probably be implemented in features.ctools.inc instead

Fabianx’s picture

I would RTBC #79, but I really thing this should work also for CTools objects, however I am also fine to do that in Follow-up:

We just need to copy something similar to

http://cgit.drupalcode.org/drush_ctex_bonus/tree/drush_ctex_bonus.drush....

to make it work :) to features.ctools.inc.

Thanks,

Fabian

catFighter’s picture

Any solution doesn't work for me. But move code from Feature to Ctools Export Module (disable then feature) add new posibilty that then we can override settings in database for example Panels and refresh cache dont make revert as is in Features.

catFighter’s picture

Also i try use FTools but also dont save all to database.

milos.kroulik’s picture

sweetprincess: Sorry for my misunderstanding, but i would like to have clear overview of workflow you mention in #82. Is it like:

  1. Use Ctools export to export Ctools exportables
  2. use patch in this issue queue to enable re-importing of non-ctools exportables
  3. disable feature
  4. re-import Ctools exportables using Drush CTEX

Please correct me, if there's any mistake I've made or if you've any experience with such process.

kylebrowning’s picture

Status: Needs work » Needs review

#79 Works great, when can this get reviewed and committed?

inky@inky3d.com’s picture

I have been reading through this thread in great detail, but am still lost to what has been resolved.

I have patched Features 7.x-2.5 from #79 and see that there is a new "Import" tab, but I have no idea what happens when I click on it, or what is supposed to happen. When I do click on "Import", the features page reloads and the only thing that appears in my logs is: Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 207 of /var/XXX/XXX/includes/install.inc).

I don't use drush, so I don't have the option to use the CTools Bulk Export methods as explained in #52 and #57.

I have a fairly large site on which we want to remove Features, until such time as we do some further major updates.

If the workflow of how this patch can unlink features can be explained, I would be most grateful.

mpotter’s picture

Component: Documentation » Code
Priority: Major » Normal

Not sure why this is marked as "Documentation" when there is a patch here.

Can somebody summarize where we are with this patch. This issue seems to have deviated from the original post.

I'd like people to use FTools if they want the functionality of "moving" a feature into the database. That's not really the purpose of Features itself. If Features needs to implement something to make this possible in FTools, then submit a patch for that.

Status: Needs review » Needs work

The last submitted patch, 79: features-import-663136-79.patch, failed testing.

The last submitted patch, 79: features-import-663136-79.patch, failed testing.

bettibio’s picture

Recipe # 57 fails importing field group (label is missing after import in db). All the rest works like a charm.

NWOM’s picture

Here is a rerolled patch of #79 against the newest dev. It is a straight re-roll, but I have not tested it myself yet. Please review.

Edit: I personally couldn't get it to work. I imported via drush with verbosity (-v) and see that everything shows as being imported, however after uninstalling the feature, all of my components got removed with it. A few example components that went missing: Search API indexes, Menu items, Page Manager pages.

NWOM’s picture

Status: Needs work » Needs review
joostpluijmers’s picture

The patch by NWOM works and applies correctly. The module enables invocation of the new hook_features_import through both drush and the admin ui. The original author of this patch, has implemented this hook for the following component types: image(styles), node and context. This means we need to add support for all other component types provided by the features module as well.

joostpluijmers’s picture

Status: Needs review » Needs work
joostpluijmers’s picture

This patch:
- Consolidates the changes from #92
- Change hook_features_import API to be consistent with the other hooks requiring only $module, $component arguments.
- Adds support for ctools exportables.
- Adds recursion support for page_manager_pages.

Really only the items that are allowed to be in "code only" (eg: panels, views, layouts, imagestyles etc...) need to be re-imported. Other entities like nodes, terms and users are required to have database storage, so may be skipped by import.

Usecases:
- We provide page builders with a bootstrap kit, from which they want to import layouts and panels. But must be disabled to prevent features-override.
- Moving components to other features

I hope this patch will get committed, we are pushing it to staging for more testing. If any serious issues arise, I will update the changes here.

joostpluijmers’s picture

Status: Needs work » Needs review
joostpluijmers’s picture

Fabianx’s picture

#96: Thanks for your work on this.

I also very much look forward to using this functionality in my CMK module.

joostpluijmers’s picture

@Fabianx thanks, hope you get around to testing it.

I have forgotten to mention one important piece of behaviour. Imported content will (most likely) be removed from the database again upon export/rebuild. This expansion does not interfere with the workings of the original revert/rebuild/export. Meaning: You should import features, after which you either disable the feature or persist the object into code storage again. Otherwise it will revert back to its code version on rebuild.

Fabianx’s picture

#100 In CMK I never use features rebuild, but just the export functionality of it and hopefully soon the import functionality for reverting, so at least in my contrib module I have complete control about it!

Thanks so much again!

joostpluijmers’s picture

The current state of the import is that it will import "defaults" back into the database. I am now looking to create an enhancement to allow users to import the "current" state back into the database. What would be the smartest way to go about this? Render an export for component x and pass it to save?

Fabianx’s picture

#102: Yes, that is what I would do. In CMK I export quite aggressively also by ignoring conflicts (http://cgit.drupalcode.org/cmk/tree/includes/features.inc?id=b27d075#n100), that worked well for me.

joostpluijmers’s picture

Thanks fabianx, that is a great place to start looking! What would be the best default behaviour for the import? Import current or default? I'am leaning towards current, to avoid "oops" moments.

Fabianx’s picture

I think there are two use-cases here:

a) You want to revert your site to what is in code, but never use the hook() method, but push everything out to the database. In that case what is in code is the canonical revert.

b) You want to move exported things back into the database, but only if they match. In that case, you probably already have an override in the DB, so might be prudent to just ignore that. However I think features does not have the granularity as CMK has, so probably your idea to just take what export would provide and save it is best here.

Both a) and b) are unfortunately very valid, however you can reach a) by first reverting all, then run b) and vice versa, so maybe it is more a documentation issue.

ajfasano’s picture

Applied the patch from #96 and ran into two issues.
When running import from the GUI I got a warning "Warning: Illegal offset type in features_get_default() (line 825 " and "Warning: Illegal offset type in isset or empty in features_get_default() (line 833" and none of the objects were imported.

When running the import using drush fi, I received the following error: Undefined property: stdClass::$in_code_only features.ctools.inc:242

Looked up the error received when using drush and there was a similar issue with the Strongarm module back in 2012 #1402576. The patch was relatively simple.
Original Line 242 ctools_features_inc: if ($object && $object->in_code_only ) {
Modified Line 242 ctools features.inc: if ($object && !empty($object->in_code_only) ) {

The import succeeded and the objects were imported into the DB.

Found the same issue on line 380 of the same.

The feature in question uses components for block settings, content types, dependencies, field bases, field instances, flag, permissions, rules configurations, strongarm, and views.

As I am not all that familiar with the whole protocol of posting patches, I did not create one, but I figured I should bring this to your attention as there is renewed activity on this issue.

Thanks,
A.J.

arlinsandbulte’s picture

Is this issue duplicating the effort from the Features Tools module?
https://www.drupal.org/project/ftools

In particular, look at the feature Unlink directions for this module.

NWOM’s picture

@arlinsandbulte the Features Tools module is missing a lot of commonly used fields and isn't being actively updated. This patch has progressed further than Features Tools.

mpotter’s picture

In order to get this into Features itself, it would need to support all core feature types and also include tests for all of this new functionality. This is such a huge change that I'm very uncertain about putting it into the current Features branch, especially since this isn't needed at all in D8 and right now all new Features development is happening in D8 and the D7 version is just being minimally supported.

Since the Features Tools module was created to add stuff like this, I'd suggest trying to update it there. If that module isn't active then somebody can go through the process to become a co-maintainer.

Or, you can just keep working on the patch here and let sites interested in using it reference it in their make files.

geek-merlin’s picture

Note: I have a module that helps debugging D7 exportables by showing exactly which hook and which alter changes what.

https://www.drupal.org/project/xbrowser

it includes a vbo-like "Re-save settings to the database".
Originally i created it as the features tools "unlink file" seemed to cumbersome to me.

I'm open for help (with docs too ;-), patches and improvements.

joostpluijmers’s picture

Hi guys,

Heres the updated patch which contains working admin GUI and also support entity import by the entity exportable controllers.

@mpotter: that is good to hear! I need my most used modules in D8 before I can consider moving. But sharing is better than hoarding right? If I get around to it I will port this to its own module.

joostpluijmers’s picture

I noticed that during my own build, the new file features.entity.inc was missing. Git diff doesn't add new files unless they were git add-ed, live and learn.

Fabianx’s picture

Good work on #112! :)

dshields’s picture

I've been testing #112 with a number of inherited bloated features and am seeing terrific results!

Yuriy Mudriy’s picture

Status: Needs review » Needs work

Excellent #112 work for views but a am seeing this error for panels: Notice: Undefined property: stdClass::$in_code_only in page_manager_pages_features_import() (line 380 of /home/vagrant/project.local/docroot/sites/all/modules/contrib/features/includes/features.ctools.inc).

dshields’s picture

I'm not able to reproduce that error. Yuriy, might you provide instructions on how to trigger this notice.

Thanks.

milos.kroulik’s picture

If I try to import feature using #112, which contains field group, it leaves it in overridden state - most of the settings are deleted, as you can see from the attached features diff screenshot.

Features diff

dshields’s picture

So using this with the field group module needs testing..

dalin’s picture

A few things:

* /admin/structure/features/%feature/import needs a confirmation form. Otherwise it's an CSRF vulnerability.
* Needs some user feedback after it's been successfully (or not) imported.

Rafal Lukawiecki’s picture

I have used the patch mentioned in #112 and I can confirm that it seems to have worked. Import allowed me to get the previously large and incomprehensible feature back into the db, except for image styles. Those appeared as Overridden. Site seems OK after disabling the feature, but more testing on its way. Thank you for a very useful patch.

As our site will remain in D7 for the foreseeable future, and it is still under development, this is a very useful function for deploying changes from dev->stage->prod. If anyone wishes to suggest a different D7 way, please let me know. Thank you.

couloir007’s picture

I applied the patch to 7.x-2.x-dev, but when I click on import I get redirected back to the features landing page. Nothing seems to happen.

Lanny Heidbreder’s picture

Another resounding success for #112 here. Thank you!

EDIT: Actually, no it's not. Having the same field_group issues as others.

Lanny Heidbreder’s picture

I've got a patch to the field_group module at #2882785: field_group_pack sometimes called on already-packed groups that fixes group importing.

HLopes’s picture

Can confirm,

#106

(different line though, here it was L369)

#112 and #123

seem to have done the trick for me.

mrweiner’s picture

Just dropping in another confirmation that #112 seems to be working for me as well.

EDIT: I'm not using Field Groups, so I cannot comment on that aspect.

MariaIoann’s picture

#112 worked for me as well. Tested with Field Groups and Views.

In Field Groups however, the data blob column is missing important information (label, settings, etc.)

hargobind’s picture

Status: Needs work » Needs review
FileSize
18.43 KB

The patch in #112 doesn't apply to the current dev anymore. So here's a reroll.

Some things that I've changed:

  • Cleaned up code formatting. Add lots more comments.
  • Add a confirmation form when clicking Import, and a "feature has been imported" message.
  • Added an isset() check to hopefully bypass the issue that was reported with panels in #115.
  • Added cache resets for ctools and panels.
  • Added code demonstration in features.api.phpfor hook_features_import()

I don't have Field Groups installed, so I can't comment on those issues mentioned above.

I haven't tested all the components thoroughly, but it seems to work fine for node types and image styles.