Exporting of blocks for features

I won't be adding this to Features but you are welcome to use this on your own in a custom module or so. FYI, jmiccolis has reimplemented the custom blocks concept in the Boxes module which has integration for the CTools export API.

NB: http://drupal.org/project/features_extra offers this functionality

yhahn, if features.block.inc is going into D7, will you consider a backport for D6?

Or is there an architectural reason it's marked Won't Fix for D6 and should stay that way?

This module is broken. I took some of the patch in this ticket and some of the fe_block.module and worked up something that works in the meantime. I punted on the boxes. It should be rolled into ctools.

I am adding this patch so I can pull it in with my drush make file. It isn't the best but it works.

Just realized I rolled a crap patch. Here is one generated from CVS diff.

I was getting an error on line 122 of includes/features.block.inc because it was expecting an array instead of an object. I modified the patch from #5 so it uses an array instead.

Try: http://drupal.org/project/features_extra

So for on D7 what is the best way to export block? Context is not possible because it actually bug with i18n.

Try Features Extra for 7.x
http://drupal.org/node/647444/release
If something doesn't work, raise a new ticket for Features Extra module.

release note of Features Extra say "The Block and Taxonomy components have not yet been migrated."

Try: http://drupal.org/project/features_extra
You can do git clone of the project http://drupal.org/node/647444/commits block export works very well

Just confused that exporting blocks is a so common operations, why don't intergate it into features module but in features extra.

I suppose much people are using features for syncing staging to production, so one module to finish this is the best way. People just need a stable and easy to use module to do the all configurations syncing.

Just make sure is it possible for the above request.

Features module is designed to reduce user's work, but now it splits the fuctions to sperate modules are just add more complication to users, this is not the goal of features module.

I think most users would only want to use one features module.

We wont be integrating Block export into Features. As mentioned further up in the thread, Boxes is a much better way to do this.

So I heard good things about features and tried it out. Very happy so far. Hit a small snag, it didn't perform how I expected it to.

If I select the blocks dependency for my feature then I kind of assume that block positions are supported and restored... If I get to the point, choosing blocks to restore would have made so much sense. I don't like boxes and nor do I want to use it. My option is to do this manually for now.

I thought the goal of features was to simplify the core, contrib and custom stuff. Well blocks are pretty much drupal core. Giving them a home/region is custom config. I don't understand why you would want to not support this. Surely it's a common scenario to keep blocks in sync after installing views and menu_blocks (for example)?

BTW, features extra is a year out of date so I don't trust it.

#15 answer the question. If you don't want to use boxes for whatever reason, create an new module or patch features extra (your right now it is buggy).

If you don't have the skills, pay someone. If you don't have money, again use what other people use.

Sadly, is not because it's a core module than is good. Block is old and hard to export. boxes has a way better architecture than make export easier. If nobody export core block in feature is for a good reason: the data from this module is not exportable in a nice and solid way.

See Drupal 8.x related ticket: #430886: Make all blocks fieldable entities