Export nodes with features?

Thnx bojanz,

should I submit a feature request or, by design, is exporting nodes not in the realm of possibilities with features?

Thanks bojanz,

Hereby my feature request to allow for the implementation of content (nodes) via features.

Hey hefox,

Looks like this module is exactly what @grayside is talking about in comment #5. I'll check this out, have you used this module already?

Ok... I've opened pandora's box. Yes, uuid_features exports content but I'm getting weird results where page nodes are exported but the entire content type page is not. Promoted to frontpage and menu links are not propagated. The problem is, I don't really know where the issue lies. I have submitted a comment to this thread http://drupal.org/node/401948 which details the problem.
The thread mentions a problem with CCK (content_copy) but the patch was abandoned in favor of node export. However, I need my feature to be part of an installation profile and I would like to update this feature once in a while. So for me, node_export is no good.

Most of all, I am confused because I don't know what to troubleshoot. The thing is, my installation profile contains several features, and they work great. The most extensive of configurations are done fully programmatic, thanks to the brilliant alliance of strongarm, ctools and features. And the two simplest of settings (promote to frontpage, show in menu) spoil the party. Which brings me back to (@grayside) http://drupal.org/node/825206. Because it could be a variable I'm missing/ misinterpreting.... Without me realizing. Most of the variables I can look up on drupal.org, but try searching for something like 'clear' or 'rebuild'. These sort of variables could be anything for all I know, including an empty table or something left over by a module I uninstalled a long time ago. Or they could be very, very important....

There is an overall red flag though, if I finish my installation profile, I get most of my features saying they are overridden. If I don't run them in an installation profile, but enable them manually, no overriddenness! I also get no conflicts whatsoever and on close inspection all is very well wit all of my features.... Yet content is still not behaving in any case.

I really need some help on this, it's kinda frustrating to have all my efforts that went into this are being rendered useless because these two rebellious node operations. And more so, I think it is not a matter of features not functioning properly, rather, it is brilliant. But as I said, I've unlocked pandora's box somehow and it won't shut.

With the benefit of hindsight.... I can't believe I didn't check... but it appears the nodes I export are installed with different node id's. So I export node/96 and it becomes node/1 on the other end. So that's why my menu's and node references are DOA.

I also noticed, looking at the code of my feature, it stores the alias given by path-auto. Don't know if that's a problem or if it would solve the issue if I can somehow prevent that, keeping the node id's uniform between my export and the site I install it on.

True, same thing goes for FAQ's from the Frequently Asked Questions module. That can add to the confusion.

But nonetheless, after some reconnaissance it can work brilliantly.

Well, I've spent 4 days on this now and I can conclude it's not possible to achieve my goal. I can understand somewhat why but it does surprise me a little. Anyway, for future reference, here's what I tried and found out.

My goal was to build a feature module that implements dummy content, menu's and guidance for inexperienced users to easily make quick configurations and setup content and such. I wanted this to be a feature so I can easily improve and extend the guidance content. That's why I wasn't too fond of delegating this to my installation profile.

As it turns out, it is very well possible to export content, menu's and menu links through features. You just need the uuid_features module. What you'll get however, is a limited selection of variables. Something like this:

'uuid' => '5913c0ea-eb57-11df-8431-00163e4a2868',
'type' => 'book',
'language' => 'en',
'status' => '1',
'comment' => '2',
'promote' => '0',
'moderate' => '0',
'sticky' => '0',
'title' => 'Introduction',
'body' => '

blah blah....

',
'format' => '2',
'name' => 'me',
'path' => 'book/introduction',
'date' => '2010-11-08 17:43:43 +0100',

If you apply a patch however, found here: http://drupal.org/node/920966 you'll get lots more. So now your code looks something like:

'type' => 'page',
'language' => 'en',
'uid' => '1',
'status' => '1',
'created' => '1289681201',
'changed' => '1289691640',
'comment' => '0',
'promote' => '0',
'moderate' => '0',
'sticky' => '0',
'tnid' => '0',
'translate' => '0',
'revision_uid' => '1',
'title' => 'Content',
'body' => '

blah blah

',
'log' => '',
'revision_timestamp' => '1289691640',
'format' => '2',
'name' => 'me',
'picture' => '',
'data' => 'a:0:{}',
'path' => 'content/content',
'pathauto_perform_alias' => '1',
'last_comment_timestamp' => '1289691338',
'last_comment_name' => NULL,
'comment_count' => '0',
'taxonomy' => array(),
'files' => array(),
'panel_build_mode_info' => array(
'page' => '',
'teaser' => '',
'processed' => FALSE,
),
'uuid' => '1e361a36-ef67-11df-8431-00163e4a2868',
'revision_uuid' => '1e362a94-ef67-11df-8431-00163e4a2868',
'date' => '2010-11-13 21:46:41 +0100',

Now, this is where it becomes apparent that there are impossibilities in play. If you run the feature with your content (patched or not) in your installation profile , you'll find that Drupal just says no. Your feature is overridden and the exported variables are largely ignored. So if your node was at node/96 in the site your created the feature with, it will arrive as node/2 (for example) in your new website. So your (menu) links are broken. If you revert the feature, flush caches, update database, the content module breaks. You'll get a lot of errors pointing to content.inc.

The way I worked around this right now, is to do some staging. I export my nodes, the menu's and menu links into a feature and install it on a new website. I then update the broken content and menu links and recreate my feature. I update my installtion profile accordingly and the next time I run it, all is well. A new website is now created with nodes and working menu's! However, you'll still have variables being ignored, so working with books and such is a no go.

There is also a different / in between approach. You can include exports of your nodes and include them in seperate text files into your profile and have the Drupal installer call on node_export and the installation_profile_api to deliver your nodes to your new website. This is just a tat bit more flexible than hard coding the nodes into your profile but not really much different.

Unfortunately, as it now appears, path auto variables are also overridden by default. Like the node patterns setting. This problem is also related to the aforementioned issue thread http://drupal.org/node/920966. I haven't tried the 2.x dev version of pathauto, and the patch that is found here http://drupal.org/node/871132. So I don't know the extent of the drama on the path_auto part.

I have been as thorough as I could be in my attempts, but I may off course have missed something or made an error somewhere. But the above is where I landed. Hopefully this will assist others who are trying to do the same.

One thought though, on the statement that the purpose of features is to separate settings from content. I think features is brilliant so I'll be the last to object. I'm just wondering why one would exclude nodes 'per se' as a philosophy. I do understand the circumstantial motivations for keeping them separate (believe me....:) )

Thanks @chaps2, I've got a strong stomach :)

I'll definitely try it, thanks for writing it and pointing it out! I'll won't be getting around to it in the very near future though. I'll post back as soon as do!