Upgrade existing features to D7

Subscribe.

An alternate might be a features_coder_upgrade module that helps convert exports directly.

Subscribe

Subscribe. This is something I'm going to be doing a lot of.

Working on upgrading the Debut feature set to D7, I'm finding it's easiest and best to start fresh. Review your overall design, making sure you're using D7 approaches. E.g., you'll likely want to replace imagefield and emfield fields with media fields. Open a D6 site with the feature enabled and then rebuild each component. Export to a new feature. If you have custom code in the feature, you can manually copy it over and adapt it. Yes, it takes time, but, as well as getting you there quickly it imposes the discipline of reconsidering your choices.

The hard thing is upgrading existing sites--but that's something you'll have to face with our without some automated upgrade of your features.

@nedjo that sounds like a best practice, but are the migration paths somewhat smooth for the content abused that way?

Here are some examples of feature upgrades:

http://drupal.org/cvs?commit=491448
http://drupal.org/cvs?commit=491504

If you're switching e.g. from imagefield to media fields, presumably you'll need a custom upgrade script, or maybe something using Migrate.

Subscribe.

just bumping into this myself and am using the same approach as nedjo. However, particularly for sites where the features modules are primarily used for keeping configuration in code and assisting the deployment of configuration, this could turn an otherwise common upgrade into a huge amount of work. Its not uncommon to see 5-6 features modules on a small-medium site, plus any "real" custom modules that require upgrading.

Has anyone tried manually changing the module column in the node_type table back to 'node' before turning the non core modules off?

It seems like that should at least preserve the fields and tables in cck. Just curious, getting ready to start this myself.

fwiw, I talked with a few people about possible ways to approach this:

1 - using coder module to upgrade the features modules

This currently doesn't work because coder module only supports core api changes and thus doesn't recognize all the various contrib hooks for cck, views, etc.
It may be possible add code here that might support this though and could help other upgrade paths outside of features modules

2 - use D6 features.module to export a D7 compatible feature

Instead of trying to upgrade a feature, we could try to just export a D7 compatible feature through the existing D6 interfaces. This would require code to be written, but could be easier than an upgrade path.

3 - import / upgrade for features to D7

Perhaps a similar approach, but I think this might require more code since it is writing an upgrade path for everything.

4 - push the feature back into the database and let upgrades take care of themselves

Perhaps there could be an option similar to revert, that actually pushes all the features configuration into the database so that when they are disabled, any configuration is just upgraded as normal. You would then simply have to redefine the features in D7, but this seems like less work than rebuilding the content types, views, etc for each feature.

5 - manually recreating each feature

as per nedjo, the fall back option is to rebuild everything in D7 and recreate the features. This is obviously very labour intensive but might force some rethinking of implementations which is a good discipline to have.
I think in general this fallback will be part of any process. However, just like the coder module eliminates a lot of repetitive work and then often requires some manual clean up, an upgrade path for features should follow similar process and allow you to finish much quicker.

#4 and #5 seem the most natural. It places the work suitable for an upgrade path on the various modules that spawned the configurations in need of upgrade. And it leaves everything else for the kind of reconsideration it probably needs.

It also has other sorts of utility--if someone wants to leave the Features infrastructure for a different approach to exportables, it becomes possible to start over more cleanly.

Wait. Why isn't there a way to permanently store a feature in the database? This seems like a very critical piece of functionality to me. I assumed the configuration of the database would remain intact if I just removed the code. Isn't there a way to prevent features from disabling a feature's functionality if the code is missing and it hasn't been disabled?

as is described here? #969980: Export definition to database (and remove feature)

@#17 that would be solution being discussed.

@idlewilder The ideal Feature has:
- Features module itself is not a dependency.
- The exported components are run directly from code, not even touching the database except for caching.

Obviously, that's an ideal, but with that as the goal, it can't be surprising that the opposite direction wasn't implemented. Why would you disable a feature, and lose some of the benefits (features reverts, etc) of using features in the first place?

Simple: Migrating off the features platform, or upgrading your site. Now that we are talking about major upgrades, it's come up as an increased priority.

4 - push the feature back into the database and let upgrades take care of themselves

This seems to be the most logical answer from my understanding. It would also mean the features module could be removed, and the site could still function with the same settings intact. The features module currently locks you in to its perpetual usage.

Is it possible to convert a feature module to one that does an installation of the variables (to the DB) instead?

Having to recreate entire sites when a major updates come along is not really a practical for smaller sites where there is less money & time to test & retest the migrate process.
I also worry about the amount of urls you make into 404's by exporting the content from one DB to another.

The features migrate process (or lack of) puts me off using features on D6 sites.

Agreed that #4 is the most promising short term approach. We would need a contrib module to push features to the db. Wouldn't be that hard to do, but would need a method for each component type.

That said, for most component types, it's not time consuming to do this manually. Go through your features-provided views, contexts, etc. and override them one by one, making no changes. Then do the upgrade.

Anyone trying this, please report back on how it goes.

If you have many components, you might try this trick in the new version to save the time and error potential of individually selecting elements through the UI:

• Create a new feature with a single item of each component type you're using.
• Manually edit up the .info file to add in references to the remaining items you need, copying/adapting as needed from your D6 feature.
• Regenerate the feature to get all the items you added manually to the .info file.

@nedjo I think this should be part of the core Features module, as it's critical to the uninstall (and possibly site migration) process.

@drew reece Not all features really need the features module installed, but it is a common need. Features module does not have anything to do with content migration issues. The effort to unite the two is still a fundamentally experimental process. See http://drupal.org/project/migrate for moving content between sites, or one of any number of projects that focus on content first.

Unifying how content and configuration are exported and deployed is definitely an ongoing, and probably a Drupal 8 kind of task.

subscribe

subscribing

I resurrected #663136: Provide way to Import views/true exportables back to the database as the primary feature request for this concept of releasing components back to the wild.

There have been many duplicates of it, and many of them related to:

• Wanting to use features just to migrate configuration as a one-off.
• Feature-builders that have learned they were over-aggressive in selecting components for a single feature but cannot easily re-formulate with exported components.
• More specific requests in the name of a D7 Update process ;)

That leaves this issue free to continue as a meta-issue of the Features upgrade process.

subscribe

Here is an idea, which could work for D7 migration as well, but is untested:

- Download: http://drupal.org/project/briefcase

* Export all content types, etc. to briefcase (might need support for more ctools exportables -> see patches in issue queue of briefcase)
* Disable feature
* Re-import data from briefcase
* Upgrate to D7

Remove features.content.inc and other "data" files, basically just leave compatible things and the .info, set version to 7.x, and re-export the feature from the DB.

Done :-).

I believe this could work _really_ well :-).

Best Wishes,

Fabian

Just responded to Fabian in the other issue. Let's try to keep the import topic here isolated to discussing details of how it would fit in an upgrade workflow.

Attached is a patch that

* introduces the new drush commands features-import (fi) and features-import-all (fia).
* introduces a new hook_features_import()
* implements the new hook_features_import() for the following components
* context
* imagecache
* node
* views

The following components probably do not need an implementation
* content
* ctools
* menu_custom
* menu_links
* taxonomy
* user_role
* user_permission
* views_api

Implementations left are
* fieldgroup

I did implemetations for some contrib modules, too
* panels_layout
* panels_mini
* page_manager_pages
* page_manager_handlers
* quicktabs
* variable
I will post them in the according queues, when we have a consensus on how to implement it at the end.

Please test and give feedback, I will work this issue, as we have a direct need for it.

*subscribe*

*subscribe*

Just a note, even though - so far as I am able to see now, but I will report back when I have more info - the patch in #29 works, you still need to tell drupal the the Content Type now exists in the DB:
UPDATE node_type SET custom = 1, modified = 1, locked = 1 WHERE type IN ('page', 'story');
// The 'module' has been changed from 'feature' to 'node' so I am assuming the patch worked...

#29 has some good thought and work, but is redundant to 2-3 other issues. Please search the queue before posting here.

This issue should really be kept specific to architectural discussion about how to handle upgrades, not general enhancements to the Features module. Please do not hijack this issue further for discussion about the patch.

Duplicate is primarily #663136: Provide way to Import views/true exportables back to the database, I believe encroaching as well on #981248: Allow a feature to execute a secondary install function after features components are created and #893360: Drush update/recreate (add components).

Subscribe.

mckeen.greg had a good point in #32:

you still need to tell drupal the the Content Type now exists in the DB:
UPDATE node_type SET custom = 1, modified = 1, locked = 1 WHERE type IN ('page', 'story');

Found that it's necessary to at least set modified to 1. Added that to the SQL UPDATE already available in the node_features_import() function in includes/features.node.inc and created a new patch.

It might not be the place to do this but I would like to let people know that this is working perfectly on an upgrade of a D6 website to D7.
The website has 8 content types in features, 50 fields divided over these content types and 5000+ nodes of these content types.
Using content_migrate to do all the actual migrating.

Thanks so much for the patch in #29. Was afraid it might be a show-stopper for the upgrade.

The D6 Features tools project, http://drupal.org/project/ftools, includes an Unlink features module that aims "to give the ability to remove elements from a feature and put them back to the DB." and might be worth trying.

If that works, and this is the primary concept of an upgrade path, we should get it into Features core.

I actually had a try at ftools, but I failed to make it work. For one admin/build/features/unlink gave me an empty page. Maybe I'm missing something. The documentation is not helping though.

#35 Jan Van Diepen,

could you give step by step instructions?

I am not sure how to migrate my features to D7 using this patch.

thanks

While still on D6 run the following commands from your site's root (or put them in a bash script and run the script):

cd sites/all/modules/features/
wget http://drupal.org/files/features-import-1014522-32.patch
patch -p1 < features-import-1014522-32.patch
cd ../../../../
drush fia -y

After this the modules supported by the import patch will be in the database so you can upgrade your installation to D7 and they will be available there.

If you use a module that is not supported by the this patch you can write your own code to implement the import functionality for that module. If you make a nice patch of it and post it on drupal.org you can cd to the module directory, wget your patch, apply the patch and cd back into your drupal root as well before you do drush fia -y.

This patch applies to current head & 6.x.1.2

#41 applies cleanly and works as advertised. Thanks!

drush fia -y
drush dis module_created_by_features.module -y

Should be ported to D7 too.

+++ b/features.api.php
@@ -224,6 +224,18 @@ function hook_features_export_alter(&$export, $module_name) {
+ * TODO

Do it? o.o

+++ b/features.api.php
@@ -224,6 +224,18 @@ function hook_features_export_alter(&$export, $module_name) {
+  // The following is the simplest implementation of a straight object export
+  // with no further export processors called.
+  foreach ($data as $component) {
+    $export['mycomponent'][$component] = $component;

Is this suppose to be actual example or copy and pasted from somewhere else?

+++ b/features.drush.inc
@@ -170,6 +184,57 @@ function drush_features_export() {
+      else if ($feature) {

elseif

+++ b/features.drush.inc
@@ -170,6 +184,57 @@ function drush_features_export() {
+    if ($module->status && !in_array($module->name, $features_to_exclude)) {

The features to exclude for all is any additional parameters? Is that the same as the other commands? Doesn't seem intuitive

+++ b/includes/features.context.inc
@@ -229,3 +229,13 @@ function context_features_revert($module = NULL) {
+    $context = context_load($context_name);
+    context_save($context);

My preference would be if ($context = context_load) ... in case it doesn't load for some reason.

+++ b/includes/features.context.inc
@@ -229,3 +229,13 @@ function context_features_revert($module = NULL) {
\ No newline at end of file

New line

+++ b/includes/features.imagecache.inc
@@ -89,3 +89,23 @@ function _imagecache_features_preset_sanitize(&$preset) {
+    // Presets

Incomplete comments!

+++ b/includes/features.imagecache.inc
@@ -89,3 +89,23 @@ function _imagecache_features_preset_sanitize(&$preset) {
\ No newline at end of file

New line again

I personally am not comfortable commiting the import this to features 6.x without it being added to 7.x first. This is a new feature/functionality, and new feature/functionls need to go into 7 first, though it is adding an issue with upgrade to 6. My preference would be to leave the patching for adding import to a 7.x issue that gets backported, ie. #663136: Provide way to Import views/true exportables back to the database?

Good work so far in this issue.

Agreed that this should go into D7 first.

The existing features tests for e.g. override operations have calls that are at least very similar to the proposed new hook_features_import() operations. Where possible, the calls in the tests should be replaced with new import calls.

And we'll need tests to cover this proposed new functionality.

Here are some improvements; most of #43, minus comment improvements. The largest functional change is wrapping {} around {node_type}. Agree with D7 first, but no time for that right now.

Please turn review over to the 7.x patch at #663136: Provide way to Import views/true exportables back to the database.

Marking this as active to focus on this and leave this for discussion on upgrade path in general.

@ #41

Having trouble running drush fia -y. I keep getting this error.

Fatal error: Call to a member function save() on a non-object in sites/all/modules/features/includes/features.views.inc on line 274

Any idea?

@ #29 and #40

I get this error while using the patch.

Do you really want to continue? (y/n): y
PHP Fatal error:  Call to undefined function drush_backend_invoke() in sites/all/modules/features/features.drush.inc on line 229

Any ideas?

The save is due to trying to save a view that isn't a view; debug it? :/

The backend invoke is drush versions; either patch needs to be updated or need to update your version of drush (forget which) .. or both.

drush_backend_invoke() is for an older version of Drush (3 and 4); it was removed in Drush 5. Is there any reason that you are using the patch in #41 instead of the updated one in #45? I haven't tried it in a while, but this version updates drush_backend_invoke() to use the new function, drush_invoke_process().

Hi Greg,

I tried #45 now and I used Drush 5. Now I'm getting.

Fatal error: Call to a member function save() on a non-object in sites/all/modules/features/includes/features.views.inc on line 274

Any idea why?

Thanks

@hefox at comment #49

What do you mean by trying to save a view that is not a view? Are there any reasons why it cant save the view? Is it because the features are not just contain views but also cck, imagecache, permissions, etc...?

I have not seen #47 / #51 before. I think that the first step would be to see what the object being operated on contains. That will give some clue as to where it came from.

@all

Here is the output of the debug

http://pastebin.com/fh5sW2bG

Wow. I've got to admit I'm flummoxed that this far after the release of Drupal 7, there still isn't a reliable mechanism in Features to migrate a content type created in Features for Drupal 6 to Drupal 7. Given the whole reason for using Features was to ease migration processes, this is gobsmacking.

I've basically decided that when I manage to re-deploy on Drupal 7, I won't use Features as frankly some trust has been lost here...

I hate to throw a wrench into the works, but there is basically no way to reliably convert Features between two different versions of Drupal. The reason is that Features are stored as CODE and the CODE (apis, etc) change between major Drupal versions.

There is some confusion on here on whether Features are stored in the DB or stored as code. There are two different kinds of Features Exportables: 1) "true" exportables only live in CODE...best example is Views (or any other Ctools export). 2) "faux" exportables live in the DB. Examples are many core exportables such as Fields and Content Types.

For "True" exportables, Features also looks at the object being exported and if it has an "export" method, it just calls this to create the exported code. Thus, the output format of the exportable is completely up to the module that provides it. For example, the Views module is responsible for exporting the View object. This means the D6 version of Features is calling the D6 version of the View export function, while the D7 version is calling the D7 View function. If the resulting exports change, then Features can't do much about it.

The only way to properly handle converting Features exports between Drupal versions is to write code for each and every exportable type to handle the special cases. The above patch is a good start on that work, but it's not something that I want to put into Features itself. It really should be done as a separate "Convert" or "Import" sub-module. Otherwise the Features module itself would need to be updated every time a module goes through a major revision that might change it's export code.

This kind of migration is just not something to be provided by the core version of Features in my opinion. It's a one-time conversion process to be done by a helper module just like other migration tools. Migrating from one major release of Drupal to another major release is never a simple "press a button" upgrade, and Features can't really help with that.

Features is for helping to deploy database configuration from one site to another running the same major version of Drupal. It was never intended as a tool for migrating to a new version of Drupal. People who are disappointed with that just had the wrong expectations for what the Features module is intended for and what is possible to do with exported code.

I am going to keep this issue open for continued work on the above patch in case somebody wants to convert it into a helper module, but I am removing the "critical" priority from this task as it raises unrealistic expectations.

You are correct that the "import" code should live right next to the "export" code that it compliments, so that they can be maintained together. However, I think it is very important for the features import and features import all commands to be part of the features module itself, so that there is a central place that defines what it means to do an import, and so that there can be some expectation that modules that implement an export should also implement an import function if they wish to maintain an upgrade path to the next version of Drupal.

I am willing to accept the core features import code in the Drush Site Upgrade command, but I think that we will have a much lower level of adoption than if it were accepted into features itself.

mpotter, it would be completely reasonable that Features not be capable of handling the upgrade process from Drupal X to Drupal X+1, for both core and changes in contrib modules. However, it would be highly valuable to enable Features to be capable of pushing the configuration back into the database in the current Drupal version, so that the user can stop using Features while continuing to have the feature they have set up. This would of course then allow them to use the migration that Drupal itself, and those contrib modules themselves, provide for major version migration.

In my opinion, the documentation of Features should contain a prominent disclaimer that states, "USING THIS MODULE WILL PREVENT YOU FROM USING THE NORMAL CORE AND CONTRIBUTED MODULE UPGRADE PROCESSES WHEN MOVING BETWEEEN MAJOR VERSIONS OF DRUPAL." Perhaps the significance of this has escaped people who consider using the Migrate module as the "normal" way to approach a site upgrade. For less complex sites, using Migrate should be gross overkill.

From my perspective, the particular pain point is the inability to extract content types from the clutches of Featues.

Wait, which true exportables do not have ways to important them? True exportable predate features and to my knowledge, each has a way to to put the items back into code -- e.g. views, re-save the view and back to the database it goes. Faux exportables are already in the database.

e.g. important is for ease, it already exists in a manual form, so well, lacking documentation perhaps?

However, I think hook_features_import would be a useful hook for features core as it is a task that various people need for various situations.

edit: hook_features_import not hook_features_important *lol*

Good point; someone might want to import a feature back into the database to take an existing feature and split it into smaller components. I think that this request has relevance beyond just the upgrade path.

It was mentioned back in 2011, but might be worth pointing out again - Features Tools provides a way to put exported features back into the database (I've never tried it though).

#61: Good call. Some had trouble with Features Tools (c.f. #38) last year, but the project looks well maintained, and may work better now. I have not had a chance to try it myself, and do not remember if I tried it before. If it works, it would satisfy the desired resolution of #56.

Per #37, #57, #59 & #60, I still think this functionality should be in the Features module. If that is not acceptable, though, please move this issue to the drush_sup queue, and I will support Feature Tools there, if it works.

I think the focus on the upgrade path as the basis for the features_import functionality is becoming a red herring.

To me the real issue is that if I make the decision to use features on my site I have to continue using it, or face a painful manual migration process away from it. An upgrade is just one reason I might want to drop it.

In a perfect world features module would automatically give back control of everything it ever touched as soon as I uninstall the module, I don't think this an unrealistic expectation, and is well within the scope of the main module itself.

That being said, I really don't think it should be up to features to provide any kind of upgrade path for existing features. I have never seen a site that couldn't use a fresh look at how it's features are organized as part of a move to D7, so why not just re-create the features on the upgraded site?

Hi Greg,

I'm wondering if this patch also import Strongarm, Permissions, Rule configurations, Imagecache presets, and Fieldgroup.

Thanks

Features Tools didn't work for me. I agree ++1 with each and every point by mrf in #63.

Somehow, also, there also needs to be a way to get *rid* of a feature from your database. Perhaps Features-created modules need to have a UI for removing the feature, if and when the default moves to leaving the feature in the DB. (Or, vice versa.)

++1 on having a UI to remove features

Well, we have a patch in #45 that supports drush. Slapping a UI on top of that shouldnt be too much work.

First off, this is a long post because the issues raised in this thread will resurface in the D7 to D8 upgrade. So I consider it good practice to document as much as possible of the considerations for the D6 to D7 upgrade.

In reply to #63: I only partly agree that features shouldn't provide an upgrade path. In its current form features actually break the regular upgrade path. IMHO an important part of the problem is timing. When going into an upgrade, a logical first step is to check if all your installed modules support D7. There is no warning beforehand that your feature created modules are not going to translate to a new Drupal version. The coder_upgrade suggestions won't do you any good either. And once you go into an upgrade it's a little late to realise that actually, the first thing you should have done is consolidate your features into the db.

Now, because I've already done an upgrade before, I know this. But it'll still be a problem for first timers, people who only do a single upgrade or even for experienced users who take on the upgrade of a site they're not familiar with. One approach to smoothing out the feature upgrade path is to focus on tackling these challenges:

• a workaround is cumbersome and counterintuitive
• upgrade documentation is lacking
• and there are no system warnings during the process

But, as said, I believe the most important issue is the fact that features frustates the timing of the regular drupal upgrade path. If you follow these guides: http://drupal.org/node/550130 and http://drupal.org/node/570162 you only know your in trouble once you've finished upgrading and are trying to convert your existing "modules" to D7.

I found the drush feature-import-all path to be succesful in a couple of 6 to 7 upgrades. My experiences with the ftools module are disappointing. So I would love to see drush fia to become part of the features module, with or without a GUI. And rather than calling the procedure: "getting rid of" (comment #65) or "removing a feature" (#66) , I'd suggest calling it consolidate or import. Removing is usually easy but unpredictable. If you disable the feature module on the installation where you've created it: the module is gone but the exportables remain. If you moved the feature to a new installation, disabling leads to vanishing exportables. A mix of these 2 situations also occurs and can only be averted by careful planning of feature deployment.

We can deal with all of the above challenges if Features would:

1. throws some warnings, somewhere, early in the upgrade process.
2. add features to the list of modules that require data migration: http://drupal.org/node/895314
3. add a warning to any D7 compatibility list or statement that: "albeit features itself upgrades, feature created modules do not."
4. provide easily accessible, clear (mostly capitalised) documentation about upgrades
5. Hook into drush_sup
6. exempt from coder_upgrade module suggestions or add an extra suggestion
7. add information on the contrib modules conversion documentation page: http://drupal.org/node/224333 that it futile to convert feature created modules.
8. backup the D6 feature exportable related database data, so you can do an upgrade of the exportables after the upgrade of drupal core is finished
9. have a stable consolidate feature option

Then for a final suggestion.... While consolidating features in the database is a nice workaround. Having to recreate features manually after an upgrade is something I wouldn't like to do. Perhaps we can reuse the feature_module.info manifest to recreate the feature module automatically after an upgrade is finished. We could follow the follow scenario:

1. upgrade preparations
2. consolidate feature into db
3. run drupal 7 upgrade
4. update feature .info files to D7 features standard
5. regenerate the feature modules from the .info files

The D7 to D8 upgrade process could follow the same route.

Greetings -
I have been tasked with a migration from D6 to D7 for a site that I did not develop. The site utilizes the Features Module to create a derivative module (Call it Derivative Module). Derivative Module is dependent upon every installed, contributed module (approximately 70).

After my initial attempt at a migration I discovered I was missing 2/3 (8 total) of the site's content types. Upon returning to the D6 installation for debugging, I disabled the Features module and Derivative Module and discovered that the missing content types were constructed utilizing Derivative Module. So by disabling Derivative module I am breaking these content types AND the views, blocks & panel settings. Obviously, 8 content types provide a range of utility on the site.

So after reading this extended post, am I correct in my conclusion that I am hosed if trying to upgrade from D6.2 to D 7.15 with Features Module and Derivative Module? Therefore, I am required to rebuild each content type, view, block and panel setting?

If I am incorrect, may I ask for someone more versed in Features Module than I to clearly explain the procedure for migration from D6 to D7? I'm not embarrassed to admit that the post is vague to me and inconclusive.

I had fairly good luck with #45, but ended up rebuilding all of my views by hand rather than debugging the problems I had during upgrade. Perhaps this was due to the fact that I did not upgrade to views-6.x-3.x prior to doing the major site upgrade. I would recommend trying features-import and drush site-upgrade first; if it does not work out for you, then perhaps you may need to rebuild all of your content types and views by hand, and then use a drupal-to-drupal migration to move your data. Unfortunately, that project too is still unfinished; I have not tried it myself yet.

Thanks for the quick reply. This information is stunningly disappointing. After seeing what happens to the site when Features is disabled, my supposition is that the migration is better suited to your solution.

Would you mind, please, providing some advice on the steps you took for rebuilding in D7? What did you do in D6 prior to the migration? How did the fields become integrated into D7 and become exposed to views, etc.?

The contents of #7, #20 & #56 conspire to produce an unclear path through the migration.

Thanks in advance, I truly appreciate it.

GaryDev, the thing about content types created by Features is they *are* in the database, just marked as created by a module and thus turned off when the module is disabled, thus not upgraded during the upgrade to Drupal 7. I found that manually editing the database to mark these content types as being a standard content type seemed to be the key to a successful migration. I had run the FTools module previously, so while that didn't seem to help it may have laid groundwork somehow. I regret I didn't carefully document the steps but doing some digging directly in the database may help...

Despite swearing off Features as a result of this whole experience, I also admit it hasn't taken long to start using it again. It's still the best solution to the staging problem Drupal has, at present...

Hi Babbage,
Thank you for that. I did notice that the content types are indicated in the node_type table. Here there is a column called "module" which indicates "features" as the module type. Is it the case that I simply need to swap "features" for "node" and my content types will be preserved as nodes when I disable the features module?

What about the views and other content settings?

It may not be as bad as I have been thinking it is... fingers crossed.

For the site I upgraded, I never had added my content types to a feature; I used features-import to re-import a bunch of taxonomy terms and vocabulary back prior to upgrade, and that worked fine. So, while I have no direct experience, it was sort of my impression that features-import handled the operation described in #73. I would think that the best thing to do would be to try features-import, and see if it works; if it does not, see if you can fix it. It would be better to do your database operations in code rather than by hand, anyway, so that you can re-import and run your code again if you discover that something should have been done differently than you did it the first time.

To follow up on #68: I've prepared documentation for http://drupal.org/node/895314. I'd suggest to add the following to the bottom of the page

Modules that require D6 preparation

These modules need preparation in Drupal 6 before you start the Upgrade procedure in UPGRADE.txt.

• Features
  - This module makes Drupal configurables such as content types, CCK fields, image cache presets, taxonomy vocabularies and views exportable in module format. Before you can upgrade these "feature modules". You need to consolidate their content into the database. This needs to be done before the D7 upgrade is started. Once consolidated, the upgrade itself is handled by the core and contrib modules relevant to the feature exportables (ie: CCK, Imagecache, Taxonomy, Views, etc)

and I've changed the word Import and all related stuff to Consolidate. See patch attached. (btw, in the patch is a small fix to the api code as well)

Updated the Drupal 6 documentation page as suggested in #75.

On the patch, if you are taking an approach of adding a way to "consolidate" features into the database, then I'd like to see this ported to D7 first and then backported to D6 since we'll need the same functionality when going from D7->D8.

I would really like to stress the second use-case for this functionality, too. Which is to consolidate a feature into the database then disable & uninstall that feature and then create a new feature with 1 or more of the earlier items from the first feature.

In the year towards the release of Drupal 8, that seems like a very useful use-case that is 99% the same.

I think it makes a lot of sense to handle the 99% as 1 issue.

The patch in #75 looks good, and I was able to "consolodate" my features-created content type back into the database using the command

drush features-consolidate modulename

Unfortunately the drush aliases fc and fca were not working for me, complaining of being unable to bootstrap Drupal, inspite of the above working with no problem (?).

More importantly, this patch needs to add a UI to features so that users don't need to know drush to use it :) (TODO)

@hefox I know you said you wanted development on this issue to appear in #663136: Provide way to Import views/true exportables back to the database first, but I need to upgrade this site to D7 before I can help with any D7 patches... so, first things first :)

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

And posted it as a patch on Provide way to Import views/true exportables back to the database.

It's a patch against the latest development release 7.x-2.x-dev.

As some of you might have noticed, features.views.inc was not included in the patch referred at in #79.

Well, I posted another patch at Provide way to Import views/true exportables back to the database that has the views support in it.

Again, it's a patch against the latest development release 7.x-2.x-dev.

Patch provided in #41 worked for me.

patch from #75 rerolled against latest 6.x-1.x

#663136: Provide way to Import views/true exportables back to the database

AFAICS, both issues do the same thing (well, this issue is more ambitious, there there is only one way to upgrade existing features: import them back). Why don't close this one?

Importing a feature back to the database is one solution to upgrading existing features to d7 (and the most likely), but there could be more. Since it is the most likely, postponing this issue till that one gets fixed and backporting is the correct status. Also, it's easier to fine when it's open for those looking for it.

While writing for 7, then backporting is the official way of writing modules, in this case, there is only need for the D7 feature for people who want to upgrade to 8. Basically, this patch becomes obsolete when D8 comes out, which is the point where all of a sudden this feature needs to be developed for D8 first, then backported to 7.

It makes a lot of sense to get this into 6. It would actually help the last people who are upgrading to 7, so they are ready for 8.

just my 2 cents.

I've been fully engaged in the last couple weeks with upgrading a large, highly-customized site to D7. Although upgrading is certainly my priority, I agree with all the points made so far that being able to bring the exportables back into the DB is highly useful for other scenarios which is a case to get this patch into the features module.

I've looked at the few options that are out there about making this happen. The two leading options are the features-consolidate approach mentioned above and the CTools Export approach.

It seems that importing features back into the DB using the features-consolidate approach is the simplest and least painful, and it makes the most sense to me because the consolidate command is then available to users of the features.module without having to install some extra module(s) to accomplish this task.

For what it's worth, the patch in #82 worked for me without errors for consolidating content types, CCK fields, Views and ImageCache entries.

Since this issue was marked postponed, let's get that patch moved over to #663136 and tested there. If I have the time after this upgrade, I'll do it myself unless someone else here beats me to it.

A couple of suggestions about #82:
- Calling drush fc module-name should output that it has done something (right now it just prints a blank line).
- Calling drush fca when no features modules are installed should detect the number is 0 and print an alternative message.

i've made a first pass at adding ctools into the patch in #82 for 6.x - i needed it for boxes primarily, but it helps with variables as well. it just completely ignores ctools api before 1.7. i thought it might be of some use to folks trying to do 6->7 upgrades.

i tend to agree with batje in #86, the normal process of only working in the current release and then backporting is not the most helpful in this case. it's not a common situation.

The patch from #88 fails in a couple of places for me on the drush include file:

patching file features.api.php
Hunk #1 succeeded at 155 (offset -3 lines).
Hunk #2 succeeded at 223 (offset -3 lines).
patching file features.drush.inc
Hunk #1 FAILED at 29.
Hunk #2 succeeded at 101 (offset -9 lines).
Hunk #3 FAILED at 189.
Hunk #4 succeeded at 336 (offset -185 lines).
Hunk #5 succeeded at 393 (offset -185 lines).

Can you upload the patched module?

Dur. Patch works on the latest dev version. Nevermind.

I had trouble applying to the 6.x dev branch, worked fine once I cloned the git repo and applied through git apply instead.