Posted by DamienMcKenna on September 24, 2010 at 4:39pm
22 followers
Jump to:
| Project: | Features extra |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
A current problem with Features Extra is having to manually add a machine name to objects that already exist in the system, i.e. taxonomy and blocks. The UUID module, on the other hand, provides a way to have this done automatically. Rewriting Features_Extra to use UUID would save end users a lot of hassle migrating existing sites to using Features, and would remove the need to create another string.
A step past that then would bring up the question of merging with the UUID Features module. It provides a layer to let nodes, comments, users, and terms be exported with Features only uses the UUID module to provide the machine-name functionality.
Comments
#1
I like it, keep in mind when this is integrated in that #881550: fe_block doesnt let you chose which theme block settings to export. discuses some important functionality for block settings exporting that needs to be modified and incorporated in.
-Chris
#2
Hmm, this isn't a bad idea but would merit a 2.x branch. Anyone interested in spearheading this? I can give appropriate commit rights. Otherwise, I'll consider it some time.
One reservation I have, which may well be wrong, is that UUID Features, at least for nodes, seems to always show Overridden status upon revert. Maybe it's just because nodes get different nids and stuff and wouldn't be an issue with Features Extra stuff?
I'd love to merge this module into UUID Features, though...because I don't really want to maintain it in the long term :) at least not very actively. Shh, don't tell anyone.
#3
It does seem like these modules have the same goals, and I don't see a need for a different project. Re-writing this one to have an architecture that's more simliar to uuid_features doesn't address the issue of module duplication. So, if more folks want to help with uuid_features, that seems great to me :).
Also, with the recently committed #1008496: Node timestamps, options overridden and cause uuuid_node components to appear modified, we've addressed the node timestamp issue in most situations.
#4
OK, then me or you (whoever does it first) could create issues in uuid_features to port over fe_block, fe_nodequeue, fe_taxonomy (tentative - I think Features itself already implements this) functionality to UUID Features, and then I'll close this as won't fix.
There's one question, which is whether the Views support this module offers is not yet available through other means. The other question is whether you'd be willing to absorb that into UUID Features. Thank you for commenting!
#5
hey guys,
i think merging with UUID features is a good idea and this functionality would be valuable to a project i am currently working on (which is for D6 sadly) so i'd like to help move this forward.
i think this move would also help re: deployment/barebones spinups since features_extra exports IDs that are only unique to the generating site. I've noticed that if you place core "box" blocks in a region with the context module and featurize those contexts the context will then break when you move it to another site as the block deltas usually dont match up. i suspect this might happen for other exportables that also rely on the BID.
UUID would put these core box blocks on a more tenable export paradigm and then other feature modules could provide handling for the UUIDs instead of the BIDz. Essentially the same goes for nodequeue and im not positive but i think there is already support in UUID Features (at the very least its in the roadmap maybe?) for taxonomy so a merge would tentatively include just core blocks and nodequeue?
that being said a roadmap for a merge would look something like this:
1. add UUID support for core blocks and nodequeue in the UUID module
2. merge the exporting of blocks/nodequeues into UUID Features
I think another serious consideration that should be made at the time for 2 and which partially addresses the Overridden status issue above is to provide hook_uuid_block_features_export_render/(not render)_alter so that there is a mechanism to override exported blocks and nodequeues.
Let me know what you guys think.
#6
plus 1 for this one
good thinking
#7
subscribing.
#8
subscribing.
#9
subscribing
#10
Subscribe
#11
subscribe
#12
subscribing
#13
Don't comment to subscribe anymore. Use the Follow button in the top-right.
#14
I opened a feature request #1324846: UUID support for core block in uuid.
#15
I think that currently uuid is supported only for entity based objects, not sure how this will work out with blocks...
#16
there is the boxes module, but it doesnt use UUID.
after looking at the current state of features_extra compared to where we are with UUID Features... i think it makes the most sense to focus on UUID features and ditch features_extra
#17
FYI, according to http://drupal.org/node/1245582 , they plan on deprecating uuid_features, supposedly in favor of the Deploy module.
#18
lol. Features Extra? 301 redirect -> UUID features -> 301 redirect -> Deploy :D
#19
Exactly
#20
Also node_export has UUID + features baked in