Features Support

I don't understand what features is to be honest. I've read their project page, and I just don't get it. I've never used panels either.

This one might have to be up to someone else.

The features marketing material is quite confusing. Adding features support to taxonomy_export has helped me understand the purpose of features a little better.

Features is essentially a RAD toolkit for dealing with the repetitive bits of custom module development. So, features can quickly throw you together an API compliant module that consists of a bunch of in-code views, some in-code panels and a in-code CCK types. Put another way, it's a module generator that generates things like hook_views_defaults() and hook_node_info() and packs it up into a zip file. The crucial thing, to me, that differentiates features from the other import / export modules is the code it generates uses the normal Drupal, Views, Panels, CCK, etc.. APIs. Again, put another way, you can install a module created by features on a site that isn't running the features module itself (actually this isn't 100% true, some generated code does require the features module).

Unfortunately I don't have much free coding time at the moment :-(. I'm happy to review / comment on any patches.

Funny, I was just thinking the same thing: Node Export + Features could conquer the world (of exporting Drupal elements)!

Since the bulk export feature has been added, a lot of people have assumed this module will allow you to export the structure of a whole site and keep things like menu links, authors, node references, book hierarchy, etc.. BUT NO IT DOESN'T. The reason is that the ID values that are used to identify the connections between things like that get changed around during an import. There are hooks that allow manipulation of nodes during imports/exports...

Node Export + VBO is a sweet, killer combo, no doubt. But even so, in many cases it seems to leave a lot of us wishing there was a way to grab the various aforementioned (et al) bits associated with nodes being exported - and Features definitely seems up to the task. Features provides a powerful, dare I say, sexy UI to snatch up related elements.

A crude synopsis: Features is a module - that creates modules (and so much more), from various relational elements, and even provides built-in version control - wow! However, that crude analogy doesn't do Features proper justice, nor pertain directly to this issue. But I think this brief post by greg.harvey is an excellent lead-off in to understanding and implementing Features - and did I mention it's a short read. ;)

My perspective on this is probably self-evident: Node Export + Features is a match made in heaven. As an aside, I'm actually working on a project today where this would come in extremely handy. NE + VBO will get me most of the way there (and for that I'm eternally grateful - thanks!), but additional massaging is required. I hope this helps.

I would say that given the relative simplicity of Node Export, and the fact that pretty much all Drupal developers understand nodes, it would be better if this sort of project was initiated by the Features developer/s.

I don't plan to work on this any time soon, so I'll file it away under postponed. If anyone has any patches or any more to say on this, don't hesitate to continue this discussion.

I agree that this would be awesome.

One use case I have is that I have a set of nodes (Workshop Types) that get used in node reference fields (on a Workshop node). It would be great to include the actual Workshop Type nodes in my feature.

If anyone has done work on this it would be great to see.

This could be really useful for building a set of canned nodes, e.g. Privacy Policy, Terms of Use, etc, that are reused across multiple sites. Clearly there's a chance of going crazy and expecting too much, but for limited uses it could work well.

It may be worthwhile looking at UUID & UUID_Features instead.

uuid_features is very cool but it don't have full supports for all cck fields at the moment. It only exports certain node properties. But it does take care of node references, user references, and files. By exporting the referenced node object and its uuid.

I have tried something similar with Node export and uuid https://github.com/chia/Smart-Node-Export

Hi chia, I noticed you've done some work on a node_export_features module. It also does stuff with references and uuid. I'm not sure I completely understand it, but I am wondering is all that functionality required to be together in one module?

Hi Daniel,

I wasn't sure where to put the code which will maintain node references. The idea is to maintain relationship status between nodes, after they are exported.
I tried not to touch the node_export code at the moment. I have used uuid to check if a node already exists, if so do an update.

OK, let me know when you are finished with this - I might cut the references stuff out and put the code somewhere else. There are a few other relationship type things I could implement using your idea too. I'd prefer if in the end node_export_features only provided features integration. Someone might want the node reference functions, but not realise they are in the features module, etc...

I'm gonna start messing around with that new module in the next few days unless you say something :P

Hi,

I dont have any other plans at the moment. You can make any changes :). I was planning to export user references and file reference. But i havent worked on it at the moment.

I want to remove the Node reference stuff from the Features submodule. I don't think this belongs here, and I will think of somewhere else to put it and solve this issue: #985848: Handle references

I also think the UUID stuff is better applied to Node export, in general, or be in it's own submodule. The reason is that many other issue solutions could rely on UUID. I am even considering making Node export depend on UUID so that the UUID information is always available in future for these implementations.

One thing I'm having trouble understanding is how much of the UUID stuff used in the Features integration is absolutely necessary, as opposed to a design choice. I guess it's not a big deal if UUID is to become a staple requirement of Node export.

I am much more open to the UUID thing, as I've seen some posts from core maintainers suggesting a push to get UUID into Drupal 8. The UUID module is surprisingly under-used as well, and perhaps having Node export depend on it will open that module up to wider community scrutiny and actually make it easier for us to maintain integration by the time D8 rolls around.

My other idea had been to allow admins to choose how nodes are compared/matched to identify nodes across sites, but this seems over-the-top for now, especially considering many people will ultimately rely on UUID using this method anyway.

I also intend to take less responsibility for the Features submodule as I don't completely comprehend it's potential, so I hope chia can stick around to provide support.

OK, I've reorganised the code to a point where I'm more comfortable with it. I've split out the node reference stuff into a module called node_export_relation, which will make more sense in drupal 7. Though I haven't implemented either features or relationships in D7 yet because UUID is not available in D7 yet.

If you find bugs in the Features integration, please start a new issue. I might not be able to do anything though, I'm a little confused as to what the purpose of Features integration is.. to be honest, it seems a bit pointless to me, really :/. So hopefully chia will check back once in a while.