Make Bean types exportable

This has to be next up on my list... Need to get my bean types into my features :)

subs. +1

I don't know much about Entity, ctools, or exportables, but it seems like both provide the same or similar things. You seem to be using a mixture of Entity and Ctools. Why do you think the exports should be done with ctools as over Entity?

Ok, here is my first attempt. It almost works, but...

• You'll need to apply the patch from #1167506: Unable to view newly created bean before applying this.
• I haven't tested the upgrade hook, so to test you may be better off reinstalling from scratch.
• When you go the the features create page, the Block types are listed without a name - I'm not sure why this is, but you can still select and it seems to get included in the export ok.
• When enabling a feature that contains beans, the new beans don't show up at admin/structure/block/types until you clear the cache. I'm guessing this is a ctools cache issue. Perhaps there is a way to flush the cache when the feature is enabled? would hook_enable() work perhaps?

You'll notice that I'm moved the bean_types table to from the bean_admin_ui module to the main bean module. I think this makes a lot more sense as there should be no need to have the admin_ui enabled or even installed to work with beans.

NOTE: Basically, I just used the example code from entity_test.module as a guide.

Whilst I think of it... What exactly are we getting out of ctools? Entity is providing the Exports, and it seems like entity can do everything that we are using Cools for. I think the thing it gives us is plugin support, but how do you envisage this to be used? Is it needed?

The types will be exportable using ctools export and not entity since the types are not entities themselves, nor will they ever become entities.

I don't understand the logic behind this. Would would the types never become entities? What is the problem with using entities to provide the exports?

I know that you can deploy beans them without features by adding a plugin, but we would far prefer to use features, so that working with beans follows the same methodology as working with content types. I don't see a huge difference in the concepts. You can have multiple types of each, which are fieldable and exportable.

The admin ui module gives the ability to add bean_types (not beans) view the UI. This will remain separate.

Shouldn't beans have the ability to have multiple types without the admin_ui?

I think I am missing something about this module concept-wise!

Ok, that makes perfect sense. I read a few threads, and looked several other modules that seemed to be doing a similar thing and they were al using Entitles to provide the exports. So I read the docs and it sounded pretty simple and just went for it. Would be awesome if you could get it done with ctools though.

I didn't get on too well with CTools :( I decided to have a go using the features API, similar to how the Drupal Commerce guys are doing it with Commerce features

http://drupal.org/sandbox/mrfelton/1169160

Seems to work pretty well. Only problem I have is switching out the Delete links with Revert onces for bundles that came from code.

Here is my first attempt at this. This patch uses the CTools Export API to export bean types to code. This makes it very easy to implement exportables, and we don't have to worry about maintaining our own features implementation.

Some notes:

* CTools needs a serial identifier as a primary key, so I had to add one.
* If you have a column name called 'type', CTools, will overwrite it with it's own data so I change the name of the machine name column to 'name'.
* I tried to use the CTools Export UI at first, but it turns out it is very hard to use it in this particular case, since we want to have fields on top of our content, and it is really hard to get that working inside Export UI.

@indytechcook Do we need to be backwards-compatible here? In that case we need to write an update hook for this.

Setting status

I'm also changing the title, since this is about exporting the bundles, not the beans. If I missed the point completely, please feel free to change it back =)

Nah, you're right. Nice work. I'm gonna give this a try in a minute.

@fabsor, I would say that since we have had an alpha out for some time, this will need an update hook. Certainly, I need one so that I can run this on some of the sites that I'm using Bean on.

I have added an update hook to the patch, however I've been unable to run it as I get the following error when visiting update.php or using updatedb with drush:

Fatal error: Call to a member function getLabel() on a non-object in /Users/tom/workspace/alumni/profiles/alumni/modules/contrib/bean/bean.module on line 37

I'm guessing this is because the code has been changed to use the new database structure, which won't actually be available until the database update has run. Bit of a catch 22. Not sure how to get around this.

Here is a patch with a working update hook. However, even after running the update I'm getting WSOD.

Call to a member function values() on a non-object in /Users/tom/workspace/alumni/profiles/alumni/modules/contrib/bean/includes/bean.core.inc on line 54

For some reason, ctools_plugin_load_class() isn't returning anything on line 278 of bean.module which means that the bean type class doesn't get loaded and set in $bean->setPlugin() line 343 of bean.module.

OK. Patch updated with fully working update hook.

However, there are a couple of problems with the export functionality:

1) Fields not included - If you crate a Bean Type and add a couple of fields to it, then create a feature and add your Bean Type to it, the resulting feature module contains only the code to recreate the Bean Type, and does not add any of the fields

2) Name - In the Features admin ui, the bean types appear under a category called Bean Admin UI. A more appropriate name would be 'Bean Types'

Oops, wrong patch. This one has working update hook.

Thanks for fixing the update hook, nicely done!

Here is a patch that adds the fields we attached to a bean type to the feature automaticly. The second complaint however is harder to fix, since features just takes the name of the module as component name, and it doesn't provide a good way of altering that as far as I know.

We might consider breaking out the configurable bean into it's own module so that you don't have to have the UI enabled to actually create your bean types, it feels kind of strange that you would attach that to the admin module, but I would consider that a different patch.

It is actually possible to change the name provided in the features UI. Features allows you to override any one or more of the default features hook implementations, including hook_features_api() which is where the name comes from.

Attached patch implements hook_features_api(), and moves your features pipe alter into a includes/features.inc file

FYI, lok at the top of features.ctools.inc in the features module. Some pretty funky code there to make that possible!

Also, the bit from the features API.txt that explains it:

- Using a custom table with CTools Export API integration. If this is the case,
Features will automatically have integration with your module. You can implement
any of the Features hooks in order to override the default CTools exportables
integration behavior.

**Features integration:** Automatically provided. You may implement any of the
Features hooks where you need further customization for your configuration
object.

I definitely agree about moving it out into its own module eventually. The fact that all of this is attached to the admin ui really confused me when I first started to work on the exportable support. We are not exporting admin_ui's - we're exporting bean_types, and you shouldn't need an admin_ui enabled to do that.

@indytechcook - it's required for the update to function properly. $type can be empty just after you have updated the module code, but before you have run update.php. Because the new codebase is looking at the new database structure to get the plugin/type information and until the update has been run, the new database structure is not in place. See my comments in #18 and #19. You can't even load update.php or run updatedb from drush without those checks in place.

Here is a revised patch that actually contains features.inc - missed it out of the last patch. I've also adjusted the hook_features_api() implementation based on the outcome of my discussions in #1193114: Exported DS configs do not include custom styles.

I haven't fully tested the revert functionality yet. I'll do this in the next couple of hours.

Ever so slightly revised patch attached. Just one small change to the block type listing screen, to ensure that the table display correctly for all override statuses. I think you are good to commit this. It gets the functionality in place. We can move it around in the code later if it makes sense to do so.

Looks like this didn't apply properly. The bean_admin_ui/includes/features.inc is not in the repo.

Added in http://drupalcode.org/project/bean.git/commitdiff/879d4d3?hp=66872c0985a...