Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
#127 | features-import_objects-663136-127.patch | 18.43 KB | hargobind |
| |||
#117 | User Configuration - Lékárna Hartmann.png | 36.26 KB | milos.kroulik |
#112 | features-allow-for-remport-of-objects.patch | 15.27 KB | joostpluijmers |
| |||
#111 | features-allow-for-remport-of-objects.patch | 14.39 KB | joostpluijmers |
#96 | features-import-from-code-to-database.patch | 13.86 KB | joostpluijmers |
|
Comments
Comment #1
yhahn CreditAttribution: yhahn commentedThe 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.
Comment #2
pimousse98 CreditAttribution: pimousse98 commentedThanks! 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.
Comment #4
pimousse98 CreditAttribution: pimousse98 commentedA 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.
Comment #5
jmseigneur CreditAttribution: jmseigneur commented+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.
Comment #6
neofactor CreditAttribution: neofactor commentedAny 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.
Comment #7
Grayside CreditAttribution: Grayside commented@#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.
Comment #8
neofactor CreditAttribution: neofactor commentedThanks... 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.
Comment #9
Grayside CreditAttribution: Grayside commentedYou 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.
Comment #10
neofactor CreditAttribution: neofactor commentedI 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?
Comment #11
neofactor CreditAttribution: neofactor commentedI 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".
Comment #12
Grayside CreditAttribution: Grayside commentedYou 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.
Comment #13
neofactor CreditAttribution: neofactor commentedIs "features unlinking" on the books to be implemented?
If so... any insights as to how to manually do it now?
Comment #14
Grayside CreditAttribution: Grayside commentedThere 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.
Comment #15
neofactor CreditAttribution: neofactor commentedSeems 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.
Comment #16
osopolarThere 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.
Comment #17
Grayside CreditAttribution: Grayside commentedWhat's really called for is a programmatic version of #1.
Comment #18
doublejosh CreditAttribution: doublejosh commentedsubscribe.
Comment #19
infojunkie+1 my interest is in refactoring features.
Comment #20
Wappie08 CreditAttribution: Wappie08 commentedI 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
Comment #21
Maciej Lukianski CreditAttribution: Maciej Lukianski commentedsubscribe
Comment #22
atolborg CreditAttribution: atolborg commentedsubscribe
Comment #23
Fabianx CreditAttribution: Fabianx commentedHi,
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
Comment #24
Grayside CreditAttribution: Grayside commented@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.
Comment #25
Fabianx CreditAttribution: Fabianx commented@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
Comment #26
Hanno CreditAttribution: Hanno commentedsubscribe
struggling with too much dependency and by uncluttering nodetypes disappear.
Comment #27
ar-jan CreditAttribution: ar-jan commentedI'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.
Comment #28
Grayside CreditAttribution: Grayside commented#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.
Comment #29
Hanno CreditAttribution: Hanno commentedI 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';
Comment #30
earthday47I can concur with hanno that changing node_type.type from "feature" to "node" will prevent it from being deleted when the feature is deleted.
Comment #31
hefox CreditAttribution: hefox commentedI believe what is forming in #1014522: Upgrade existing features to D7 will cover this, aye? nay?
Comment #32
Grayside CreditAttribution: Grayside commented@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.
Comment #33
Niklas Fiekas CreditAttribution: Niklas Fiekas commentedSubscribe.
Comment #34
hefox CreditAttribution: hefox commentedA 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.
Comment #35
perelman.yuval CreditAttribution: perelman.yuval commentedHi 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
Comment #36
perelman.yuval CreditAttribution: perelman.yuval commentedHi 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
Comment #37
mrfelton CreditAttribution: mrfelton commented+1. subscribe. Going to test the briefcast and ftools modules, as well as the manual overriding and disabling workarounds in the time being.
Comment #38
donquixote CreditAttribution: donquixote commentedRelated 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?
Comment #39
perelman.yuval CreditAttribution: perelman.yuval commentedHi 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
Comment #40
donquixote CreditAttribution: donquixote commented@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.
Comment #41
Grayside CreditAttribution: Grayside commented@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.
Comment #42
ablommers CreditAttribution: ablommers commentedHaving 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.
Comment #43
hefox CreditAttribution: hefox commentedMoved 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.
Comment #44
perelman.yuval CreditAttribution: perelman.yuval commentedHi @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).
Comment #45
perelman.yuval CreditAttribution: perelman.yuval commented@grayside you are right.
what do think is the right why to unlink CCK/FILEDS elements?
Comment #46
damien_vancouver CreditAttribution: damien_vancouver commentedI 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:
I also tried with a view, and got a similar error (though not on all the view features I tried, only some):
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.
Comment #47
lex0r CreditAttribution: lex0r commentedMy 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.
Comment #48
mpotter CreditAttribution: mpotter commentedlex0r: 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.
Comment #49
Jan van Diepen CreditAttribution: Jan van Diepen commentedI 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,
I ran some manual tests on image, field and node.
Some notes on my experiences:
You have to patch against the latest development release 7.x-2.x-dev.
Comment #50
Jan van Diepen CreditAttribution: Jan van Diepen commentedThe 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.
Comment #51
justindodge CreditAttribution: justindodge commentedJust 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
toviews_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.
Comment #52
rp7 CreditAttribution: rp7 commentedThink 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 :)
Comment #53
geek-merlinhmm, what "features-tools unlink" actually does is in essence the same as described in #52.
(difference: features-tools says to handle less exportables)
Comment #54
Kevin P Davison CreditAttribution: Kevin P Davison commentedYes, 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!
Comment #55
SocialNicheGuru CreditAttribution: SocialNicheGuru commented#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?
Comment #56
geek-merlin@#55 those are faux-exportables and in db anyway.
Comment #57
kendouglass CreditAttribution: kendouglass commentedInstead 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:
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.
Comment #58
Kevin P Davison CreditAttribution: Kevin P Davison commentedThanks, 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
Comment #59
rjlang CreditAttribution: rjlang commentedWill second the attaboy to kendouglass #57; just tried it, works like a charm.
Comment #60
colanThe 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:
Comment #62
colanSilly bot.
Comment #63
hefox CreditAttribution: hefox commentedimproper 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) ;_;
Comment #64
colanI 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?
Comment #65
justindodge CreditAttribution: justindodge commentedI 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.
Comment #66
rjlang CreditAttribution: rjlang commentedPer 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.
Comment #67
dsnopekAttached 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.
Comment #68
dsnopekLet's see what the testbot says - does this break anything in features?
Comment #70
basvredelingin 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?).
Comment #71
emilianodelau CreditAttribution: emilianodelau commentedThis issue with features has become a major impediment to upgrading from 6.x to 7.x. Suggestion #70 is highly needed.
Comment #72
basvredelingrerun of patch #67 still untested (included missing views.inc in patch)
Comment #73
basvredelingComment #74
basvredelingSo, 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.
Comment #75
hefox CreditAttribution: hefox commentedmmm, 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.
Comment #76
geek-merlin(#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.
Comment #77
basvredelingregarding (#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:
Comment #78
Fabianx CreditAttribution: Fabianx commentedAs 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.
Comment #79
stefan.r CreditAttribution: stefan.r commentedRe-rolled and renamed to features-import
Comment #80
stefan.r CreditAttribution: stefan.r commentedfeatures.views.inc slipped back in here but won't be needed, the views logic can probably be implemented in features.ctools.inc instead
Comment #81
Fabianx CreditAttribution: Fabianx commentedI 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
Comment #82
catFighter CreditAttribution: catFighter commentedAny 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.
Comment #83
catFighter CreditAttribution: catFighter commentedAlso i try use FTools but also dont save all to database.
Comment #84
milos.kroulik CreditAttribution: milos.kroulik commentedsweetprincess: Sorry for my misunderstanding, but i would like to have clear overview of workflow you mention in #82. Is it like:
Please correct me, if there's any mistake I've made or if you've any experience with such process.
Comment #85
kylebrowning CreditAttribution: kylebrowning commented#79 Works great, when can this get reviewed and committed?
Comment #86
inky@inky3d.com CreditAttribution: inky@inky3d.com commentedI 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.
Comment #87
mpotter CreditAttribution: mpotter commentedNot 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.
Comment #91
bettibio CreditAttribution: bettibio as a volunteer commentedRecipe # 57 fails importing field group (label is missing after import in db). All the rest works like a charm.
Comment #92
NWOM CreditAttribution: NWOM commentedHere 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.
Comment #93
NWOM CreditAttribution: NWOM commentedComment #94
joostpluijmers CreditAttribution: joostpluijmers as a volunteer commentedThe 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.
Comment #95
joostpluijmers CreditAttribution: joostpluijmers as a volunteer commentedComment #96
joostpluijmers CreditAttribution: joostpluijmers as a volunteer commentedThis 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.
Comment #97
joostpluijmers CreditAttribution: joostpluijmers as a volunteer commentedComment #98
joostpluijmers CreditAttribution: joostpluijmers as a volunteer commentedComment #99
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commented#96: Thanks for your work on this.
I also very much look forward to using this functionality in my CMK module.
Comment #100
joostpluijmers CreditAttribution: joostpluijmers as a volunteer commented@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.
Comment #101
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commented#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!
Comment #102
joostpluijmers CreditAttribution: joostpluijmers as a volunteer commentedThe 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?
Comment #103
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commented#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.
Comment #104
joostpluijmers CreditAttribution: joostpluijmers as a volunteer commentedThanks 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.
Comment #105
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedI 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.
Comment #106
ajfasano CreditAttribution: ajfasano commentedApplied 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.
Comment #107
arlinsandbulte CreditAttribution: arlinsandbulte as a volunteer commentedIs 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.
Comment #108
NWOM CreditAttribution: NWOM commented@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.
Comment #109
mpotter CreditAttribution: mpotter commentedIn 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.
Comment #110
geek-merlinNote: 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.
Comment #111
joostpluijmers CreditAttribution: joostpluijmers as a volunteer commentedHi 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.
Comment #112
joostpluijmers CreditAttribution: joostpluijmers as a volunteer commentedI 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.
Comment #113
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedGood work on #112! :)
Comment #114
dshields CreditAttribution: dshields at Canadian Blood Services commentedI've been testing #112 with a number of inherited bloated features and am seeing terrific results!
Comment #115
Yuriy Mudriy CreditAttribution: Yuriy Mudriy as a volunteer and at DEWEB Studio for Drupal Ukraine Community commentedExcellent #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).
Comment #116
dshields CreditAttribution: dshields at Canadian Blood Services commentedI'm not able to reproduce that error. Yuriy, might you provide instructions on how to trigger this notice.
Thanks.
Comment #117
milos.kroulik CreditAttribution: milos.kroulik commentedIf 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.
Comment #118
dshields CreditAttribution: dshields at Canadian Blood Services commentedSo using this with the field group module needs testing..
Comment #119
dalinA 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.
Comment #120
Rafal LukawieckiI 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.
Comment #121
couloir007 CreditAttribution: couloir007 commentedI 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.
Comment #122
Lanny Heidbreder CreditAttribution: Lanny Heidbreder commentedAnother resounding success for #112 here. Thank you!EDIT: Actually, no it's not. Having the same field_group issues as others.
Comment #123
Lanny Heidbreder CreditAttribution: Lanny Heidbreder commentedI've got a patch to the field_group module at #2882785: field_group_pack sometimes called on already-packed groups that fixes group importing.
Comment #124
HLopes CreditAttribution: HLopes commentedCan confirm,
#106
(different line though, here it was L369)
#112 and #123
seem to have done the trick for me.
Comment #125
mrweiner CreditAttribution: mrweiner commentedJust 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.
Comment #126
MariaIoann CreditAttribution: MariaIoann commented#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.)
Comment #127
hargobindThe patch in #112 doesn't apply to the current dev anymore. So here's a reroll.
Some things that I've changed:
isset()
check to hopefully bypass the issue that was reported with panels in #115.features.api.php
forhook_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.