Cloning of all supported Entity types by bundle_copy

I exported a content type, did a find replace... and then imported it. My database then became corrupt, and I had to restore the site from a back up. I think it should be doable, but be more careful than I was. It's not simply find replace.

Their are also lists for each field in the export, showing which content types they are used in. So you'll need to add on their I guess. Equally this change to the list might confuse other content types.

eg.

'bundles' => array(
        'node' => array(
          0 => 'page',
          1 => 'article',
          2 => 'display_clothing_womens',
          3 => 'display_clothing_mens',
          4 => 'display_clothing_kids',
          5 => 'display_windsurf_boards',
          6 => 'display_windsurf_masts',
          7 => 'display_windsurf_booms',
          8 => 'display_windsurf_sails',
          9 => 'display_windsurf_fins',
          10 => 'display_windsurf_bags',
          11 => 'display_windsurf_harnesses_lines',
          12 => 'display_windsurf_extensions_base',
          13 => 'display_windsurf_packages',
          14 => 'display_sh_windsurf_access',
          15 => 'display_sh_windsurf_access',
        ),

I just thought I'd give you my experience. It could be risky. Definitely back up your site and give it a try, but read the entire export carefully. I would not try this on live site given my experience.

Has anyone else had success with this?

i exported type Article and did these replaces:

article => junk
Article => Junk

and did the import.

seems to work fine.

likely not too hard to make a patch for this; might give it a shot.

Ok, let's call it fixed then.

i think until the module supports this feature this should remain active; but changing to a feature request.

and here is patch to add this feature.

i throw a validation error if a user enters a new name but is trying to import more than 1 bundle; i also attempt to fix names that are entered to align with std bundle naming practice.

also, in this patch i added weights to the menu items so they sit at the bottom of the Content Types menu rather than mixed in with the types.

please test.

oops...

was a pretty simple patch; basically just changes the bundle name where it shows up... worked fine in my tests but failed with field collections.. which i think possibly nothing to do with patch; likely just bundle copy not yet supporting collections (although thought i have tested that). did test with field groups... will try it out.

odd error though; basically saying you have no bundles.

hmm.. nope.. my bad.. my test node had both field groups and collections and worked fine.

my cloned node structure looks like this: http://screencast.com/t/w626ZGs6z

oh yes, this won't work.. lol.. not related to your error though i dont think; i can't do a simple replace as some of my field names include the name of the bundle type...

yes, saw what you posted. that won't be correct either; at least not as a string search/repalce. look at your section on fieldgroups (not fieldsets) and see all the places that could potentially have the name of your bundle in there...

hmm.. well i tried just changing the name/type in $data['bundles'] and $data['fieldgroups'] and left instances and fields alone; but that doesn't work - i end up with a new type with all my groups but no fields.

so went back to simple string replace on the $data eval string but this time did only whole word matches

this should now fix the issue with fields having bundle name in them - for example... type = Event and a field field_eventinfo

i still get this for many of my imports though: http://drupal.org/node/1622868#comment-6128156 so can't test too well.

I Created a new patch to clone the content type.
please test.

@daffodil - will gladly test out your patch but even if it is functional it will be difficult to get committed as you do not adhere to drupal coding standards. please check this out: http://drupal.org/coding-standards

@liquidcms I read the coding standards and do my code according to the standards.I again create the patch.I also worked on the cloning of taxonomy,User,Field API fields and Field groups.

Unfortunately the patch in #21 produces an error if trying to clone any field groups.

I have just looked into this further and I can clone field_groups manually by giving them a new identifier. I didn't realise that field_groups couldn't be reused but that appears to be the case.

I will test it on my end and I couldnot produce the case .so can you please provide some more details like the modules versions that you are using of cck and drupal or anything else you may think that will be the case.

Hi emilekott
as I mentioned earlier I need more details as I am not getting any error.Also mention the error that you are getting

Greetings. I got this to work (cloning a content type within the same site to a new name) by changing first near the top:

'type' => 'article',
'name' => 'Article',

to

'type' => 'newtype',
'name' => 'NewType',

and then simply copying and replacing the rest of the way down thus:

'bundle' => 'article',

with

'bundle' => 'newType',

Unfortunately this does not carry over your field display customizations with Display Suite.

I decided to take a different tack on this problem. Since we are copying on the same site we do not need all the export code generation, dependency checks, and import decoding that are required (and complicated) for copying between different sites. To do a clone all we need is the source bundle and the new bundle name.

I have created a simple clone tab visible on the content types page that does just that. I have used it to copy very complex bundles. Right now I have only tested with nodes but the submit code is very simple and should work with all entities. I have field groups working but have not implemented field collections.

I went through the core code to see where the names have to be changed and have made specific changes rather than blanket search and replace.

Apply patch to clean 7.x-1.x-dev not in combination with any other patches on this page.

Sorry should have marked this needing review.

Thanks for the patch, it's working perfectly!
As a side note, I have to say that a few days later, doing a "Run updates", Drupal showed up this:

Notice: Undefined index: clone_menu in bundle_copy_menu() (line 88 of /var/www/vhosts/.../httpdocs/sites/all/modules/bundle_copy/bundle_copy.module).

Notice: Undefined index: clone_menu in bundle_copy_menu() (line 93 of /var/www/vhosts/.../httpdocs/sites/all/modules/bundle_copy/bundle_copy.module).

Not sure if it's due to the module or my site. The Clone menu element is present in Structure > Content types and working as expected, though.

Hi Julien. You could try this edit in bundle_copy.module -> bundle_copy_menu() around line 91.

// ORG
foreach ($bc_info as $entity_type => $info) {
    $items[$info['clone_menu']['path']] = array(
      'title' => 'Clone',
      'page callback' => 'drupal_get_form',
      'page arguments' => array('bundle_copy_clone', $entity_type),
      'access callback' => 'bundle_copy_import_access',
      'access arguments' => array($info['clone_menu']['access arguments']),
      'type' => MENU_LOCAL_TASK
    );
// NEW
foreach ($bc_info as $entity_type => $info) {
    if (isset($info['clone_menu'])) {
      $items[$info['clone_menu']['path']] = array(
        'title' => 'Clone',
        'page callback' => 'drupal_get_form',
        'page arguments' => array('bundle_copy_clone', $entity_type),
        'access callback' => 'bundle_copy_import_access',
        'access arguments' => array($info['clone_menu']['access arguments']),
        'type' => MENU_LOCAL_TASK
      );
    }

You probably have another module that alters bundle_copy_bundle_copy_info(). If this fixes it let me know and I will re-roll a full patch.

Yes, may be Administration Menu. So, I made the changes, ran update and no more errors. Thanks!

I have not a live site yet on which I could test this patch.So I will commit it if anyone of the community member changed its status to reviewed and tested by community.

This patch works fine with change from #30, but I don't think that it has the best approach.

Ideally, you should reuse bundle_copy_export_submit() and bundle_copy_import_submit(). If they can't be reused exactly, then they should be broken into smaller functions that can be reused by the cloning callback. The current approach just isn't very DRY, and it doesn't utilize good encapsulation.

Updated patch. Added fix from #30. Added Display Suite and Flag integration to clone feature.

*Still not using best coding practices,* but it works.

Is patch in #36 compatible with Bundle Copy 7.x-1.1? Many thanks.

I rolled that patch against the current dev version, at the time.

i am using this to clone content types' fields, on the same site- and its been working great:
http://drupal.org/project/field_tools

just fyi...

I've just tested Bundle copy 7.x-2.x-dev. The release notes say:

"Added the new feature Cloning content types on same site."
https://drupal.org/node/1863660

Indeed, the module adds a new "CLONE" tab (and also "EXPORT" and "IMPORT") to:

Administration > Structure > Content types

For example, I've tested adding a new "Subgroup" content type for Organic Groups, cloning the default "Group" content type. In the CLONE tab:

Source Bundle:
Group

New Bundle Name:
Subgroup

And click in "Clone".

Wonderful, the new content type was created, almost exactly like the original, excepting of course the name "Subgroup" and the machine name "subgroup".

Naturally, I added my planned change, in:

Administration > Structure > Content types > Subgroup > Edit > Organic Groups

checking "Group content", in addition to "Group", so that a new "Groups audience" field for parent group is created.

And changed the content type description to "Group within another group."

And that was all, excepting one very small glitch in:

Administration > Structure > Content types > Subgroup > Edit > Comment settings > Default comment setting for new content

The original was "Hidden" and the copy "Open". Just this one difference, very easy to correct.

All the rest of the content type, the many settings in Edit, Manage Fields, Manage Display, Comment Fields, Comment Display, Panelizer... everything was perfectly cloned.

Great work, and thank you very much!

Updating the version to 7.x-2.x-dev, according to the release notes on this feature.

@juan_g: Let's not worry about some of the missing settings, as there's a separate issue for that: #1972950: Many node type properties not copied.

If there's another positive review (hopefully by me, once I try it), I think we can RTBC this.

The patch doesn't apply so it needs a re-roll.

Cloning node content types works without the patch. If you're simply cloning those, you can get by without it.