CCK type duplication doesn't create columns (other than nid and vid) in new content table

+1 Having a similar problem.

CCK node type [Type A] works fine.
Duplicate Node Type A to create [Type B].
Try to create new node of Type B.
Get same warnings..

    * user warning: Unknown column 'field_intro_text_value' in 'field list' query: INSERT INTO node_content_accomodation (field_intro_text_value, field_intro_text_format, vid, nid) VALUES ('Devondell House is an award winning Bed and Breakfast in Salthill, an easy walk from Galway City Centre.', 1, 9, 9) in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_map_image_field_value' in 'field list' query: INSERT INTO node_content_accomodation (field_map_image_field_value, field_map_image_field_format, vid, nid) VALUES ('', 1, 9, 9) in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_relatedtour_nid' in 'field list' query: INSERT INTO node_content_accomodation (field_relatedtour_nid, vid, nid) VALUES (4, 9, 9) in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_summarybullet1_value' in 'field list' query: INSERT INTO node_content_accomodation (field_summarybullet1_value, vid, nid) VALUES ('', 9, 9) in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_summarybullet2_value' in 'field list' query: INSERT INTO node_content_accomodation (field_summarybullet2_value, vid, nid) VALUES ('', 9, 9) in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_summarybullet3_value' in 'field list' query: INSERT INTO node_content_accomodation (field_summarybullet3_value, vid, nid) VALUES ('', 9, 9) in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_summarybullet4_value' in 'field list' query: INSERT INTO node_content_accomodation (field_summarybullet4_value, vid, nid) VALUES ('', 9, 9) in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_main_text_value' in 'field list' query: INSERT INTO node_content_accomodation (field_main_text_value, field_main_text_format, vid, nid) VALUES (' The Devondell Bed & Breakfast has 4 rooms (2 doubles, 1 twin & 1 single) all with ensuite bathrooms. Open from the 1 st of March to the 30 th of November, the Devondell offers rest in a relaxed, friendly atmosphere and an extensive breakfast menu.\r\nRecommended in the Lonely Planet, Frommers Guide, Bridgestone 100 Best B&B of Ireland Guide and winner of the Allied Irish Bank best Bed & Breakfast Award for the Galway area.', 1, 9, 9) in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_intro_text_value' in 'field list' query: SELECT field_intro_text_value AS value, field_intro_text_format AS format FROM node_content_accomodation WHERE vid = 9 in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_map_image_field_value' in 'field list' query: SELECT field_map_image_field_value AS value, field_map_image_field_format AS format FROM node_content_accomodation WHERE vid = 9 in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_relatedtour_nid' in 'field list' query: SELECT field_relatedtour_nid AS nid FROM node_content_accomodation WHERE vid = 9 in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_summarybullet1_value' in 'field list' query: SELECT field_summarybullet1_value AS value FROM node_content_accomodation WHERE vid = 9 in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_summarybullet2_value' in 'field list' query: SELECT field_summarybullet2_value AS value FROM node_content_accomodation WHERE vid = 9 in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_summarybullet3_value' in 'field list' query: SELECT field_summarybullet3_value AS value FROM node_content_accomodation WHERE vid = 9 in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_summarybullet4_value' in 'field list' query: SELECT field_summarybullet4_value AS value FROM node_content_accomodation WHERE vid = 9 in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_thumbnail_image_0_fid' in 'field list' query: SELECT field_thumbnail_image_0_fid AS fid, field_thumbnail_image_0_title AS title, field_thumbnail_image_0_alt AS alt FROM node_content_accomodation WHERE vid = 9 in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_pano_image_fid' in 'field list' query: SELECT field_pano_image_fid AS fid, field_pano_image_title AS title, field_pano_image_alt AS alt FROM node_content_accomodation WHERE vid = 9 in C:\drupal\includes\database.mysql.inc on line 120.
    * user warning: Unknown column 'field_main_text_value' in 'field list' query: SELECT field_main_text_value AS value, field_main_text_format AS format FROM node_content_accomodation WHERE vid = 9 in C:\drupal\includes\database.mysql.inc on line 120.

I'm having the same problem with 4.7 version of CCK. Duplicate Type A to produce Type B .Duplicate doesn't add columns, other than nid and vid, to the new Type B table.

Unless someone else looks at it before I do, i'll have a look early next week and try to get to the bottom of it. Seems it's a bug still around from 4.7 so we'll be fixing both versions.

Cheers,

--
Sammy Spets
Synerger
http://www.synerger.com

Changed the issue title to better reflect the problem and switching it to critical and 4.7 since it goes back that far. Since it's released to the public i'd call this bug critical to normal functioning of the module.

In case it makes a difference, the two fields that weren't created in the duplicate type in my environment were an integer and a node reference. I don't think it matters though. :)

Since this bug is assigned to dado, I suppose dado is going to fix it!

Here is a patch for 4.7. It needs testing so i'm flagging it as needing review. All i've done is have the system create the database fields when the type is saved and there is an original_type_name set. FYI: i'm retrieving nfi.type_name for the next bug fix i'm submitting. More on that later.

Reported again at http://drupal.org/node/85025. I marked that one as a dup. Problem still exists.

Hi KarenS,

Great that we have another person experiencing the same bug. I'm about to send a mail to the drupal developer list to get some attention to this bug. In the meantime, please apply the patch submitted above and post your success/failure here so we can get this issue moving along.

BTW: When I first filed this issue another problem existed. Once this bug is squashed a very serious bug turns up when using views and the duplicate types. The CCK views code does not handle multiple field instances properly. I've been working on a solution to that, but haven't had a chance to reach the goal yet. I'm uncertain if that problem has been addressed in the meantime. We'll see once this one is pushed through.

Cheers,

--
Sammy Spets
Synerger
http://synerger.com

Sammy, I'm confused about why duplicating types would create any new problems in views, and you're not clear about what the 'serious bug' is. The only reason why this issue would impact views, that I can think of, is if we don't get the types and fields named and defined properly, i.e. we use something that will create a duplicate table name or duplicate fields in views.

I don't have time to dig into this right now, but you can have shared fields now (I use them all the time and they work fine in views). When you duplicate a type you are making all the fields shared fields. Somewhere in the code is a place where the content module keeps track of whether fields are shared or not and turns a switch that indicates that these fields belong in their own table. If the content type you are copying from is using fields that are not already shared, thoes fields will need to be pulled out of the individual table and pushed to a separate table, and the switch needs to get set that indicates that these fields live in their own table. If that wasn't done, it would create problems later because those fields would exist in two tables (a separate table or the new content type table for the new content module and the original table for the original content type).

I'm not explaining this very well, but I think we need to look at the tables that are created and make sure the fields are all going to a single new shared table and that the switch that indicates they are shared fields gets set. Maybe I'm off-base and your code already does this and the views bug you are talking about is something else. If I have time later I'll try to test your patch and see what is happening with the tables, but I'm not sure how soon I can get to this.

My curiosity got the best of me so I tried your patch out. It doesn't work for me. It tries to add the fields from the original table back to the original table, which of course fails. Even if it added them to the right table, it was doing what I was trying to say should not happen, it was going to duplicate the columns in two tables.

You're onto the beginning of the solution, though. The current code creates the duplicate fields in the instances table and stops there. We need to figure out a way to finish the job.

@KarenS: thanks for applying the patch and testing it. I'll test it and adjust it now. I understand where you're coming from with shared fields etc, but that does not make sense to me.

As I see it, node_field stores the field name -> field type values and node_field_instance associates those with a particular node type (cck type). The node_field table has a 'multiple' field in it as well and, without looking at the code, I can only assume it stores a usage count to prevent deletion of fields that have current instances.

IMHO both node_content_ tables should have values for all fields of their records and not have part of their data in the original table. That would make for a very bad schema design.

The bug in this case exists with node types that contain node reference fields. If you just use text fields in the node type the duplication will work properly.

As far as the pending 'serious bug' is concerned, the bug exists (definitely) with node reference fields. The problem is that the CCK views hooks use the 'fields' element of the information array. This element only contains one entry per field even when the field is duplicated. Thus in a view displaying the nodes of type A will show the field in question whereas the view displaying nodes of type B will be empty string, or vice versa depending on the order in which the DBMS returns the records in node_field.

This is all very complicated to explain and i'll follow up with an exact way to duplicate the problem once this issue is fixed. No point going into it further right now because it doesn't exist yet.

Cheers.

I've confirmed it's still broken with all other fields as well. Also confirmed my patch above works ok. Another patch is required for content_alter_db_field() in content_admin.inc. The problem with that is it uses luck to guess the content type to modify when the type is duplicated. The bad line is:

$new_field['type_name'] = db_result(db_query("SELECT type_name FROM {node_field_instance} WHERE field_name = '%s'", $new_field['field_name']));

Unfortunately, there are 13 calls to this function throughout the code so it's going to take some time to go through them and patch them to have a content type in their calls.

Here is the patch to fix the problem with that function. Please test it.

The 'multiple' field discussed earlier is for flagging the field as having a multi-select widget rather than a single entry option.

I'm a little concerned at the applicability of the changes I made to the .install files. One of them, content.install, might be ok, but the others appear to be in functions that update the system to an older design of CCK. My changes may not be applicable for that level of update and i'd need info from someone with knowledge of that era.

Enjoy.

I'm still trying to figure out all the changes you are proposing, but I did want to say that I disagree about changing the database schema. Here's how things work now:

1) I create a content type for a contact record and I add a phone number field to it. My database will have a table called node_content_contact with a nid, a vid, and a field_phone_number_value field.

2) I create a new content type for a different kind of contact record called contact_alt. When I add fields to it I can create new fields or select an existing field. The phone number field I created earlier will show in the drop down to be added to this node type. If I select that field, it will be added to my field list. The database will change at that point. The phone number field will disappear from the node_content_contact and move to a new table called node_data_phone_number. My phone numbers from both content types will then be in that table (node_data_phone_number) and my two content types will be left with only the nid and vid columns.

3) In views, I will see a single field called Phone Number which I can use to filter views. I can then create a view and filter it to limit it to my two content types and add and expose a the phone number filter. My view will then look through both content types for any phone number I type in.

If I wanted different behavior, i.e. I did not want to create a phone number field that would be shared between two content types, I would have added a new field (which would have been given a different name). This idea that fields can be shared between content types is clear in the descriptions you see when you create fields (which explains that field settings are the same in all content types in which a field is used and widget settings can be different for different content types).

Based on that behavior, I would expect that the duplicate function would work as follows:

1) I create my contact record as I did above, with a phone number field.

2) I duplicate that type, which creates a second contact type with only a nid and a vid, and moves the phone number field into a separate table to be shared by both content types, leaving only the nid and vid -- the same schema that was created in my example above.

The cck views integration was written based on the above behavior. Each field creates a field, filters, and arguments in views that are based on that field's name, depending on the fact that the same field name will not exist in more than one table.

I think that schema makes perfect sense and is very useful and powerful (in views, for instance). I have no interest in changing that behavior, and changing that behavior will break things for anyone else that has things set up based on the way this schema currently works. For instance, I have numerous configurations where I share fields like phone numbers, dates, and email addresses between content types to make it easy to search for those things across different content types.

ok... I get ya. more work to do. I'm glad someone is actually giving me insight into the design of CCK.

I can reproduce this bug using the steps described.
I agree with KarenS that the 'shared fields' feature is a fundamental CCK design feature!

Hiya,

I've got this same bug...
Thanks so much for your efforts in developing a fix!

- Jeff

When I looked at the callbacks for edit vs. duplicate:

line 112, content.module, uses this code for editing a content-type:
'callback' => '_content_admin_type_edit',

line 128, content.module, uses this code for duplicating a content-type
'callback' => '_content_admin_type_edit',

I don't see any code to duplicate the table. It should clone the records-- insert them into node_field_instance-- read the rows from node_rield_instance using something like the content_database_info($field_name) function to get a list of fields and column types to add to your table.
I only really started to play with Drupal after I CCK 4.7-- did the older versions have functional duplication? Can that older functionality be "re-added" in a patch?

Nope, this is a relatively new feature that as far as I know has never worked completely right. Unfortunately I don't have time to dig into it right now (or for the next week or two), but if no one else comes up with a solution by then I'll work on it.

I think I have it solved.
It's not building a new duplicate like it should.

There are two main problems: first, it's not passing out the original_type_name and type_name as hidden values. I fixed that

• If it's a duplicate (arg(4) and agr(5) are assessed -- JIC)
• It parses the $db_url for login info
• It uses a mysqldump statement to get the CREATE TABLE statement
  • note: this called "mysqldump" by itself. Depending on your server, this may have to be absolute path to your mysqldump application.
• It swaps the old name for the new name
• It executes this new create table statement

Another bug: it was doing an INSERT into from SELECT if it found there was an original_type_name. This is only needed for duplications. It would but not ciritcally if you did an edit. Now it only does that if it's duplicating a table.

Attached is my copy of the content_admin.inc with the fixes in place.

I appreciate the effort, but that isn't the right way to do this. Content module has lots of built-in functions for manipulating the database, you don't need to do any database dumps or sql queries. Since I had a pretty good idea what it would take to make this work, and I'm really not trying to keep everyone guessing by saying over and over "that's not the right way to do it", I went ahead and put a patch together.

I'm going to post it as a patch instead of committing it to give others a chance to test it. This is for 4.7. The fix is likely to be quite different for 5.0 because content types are in core in 5.0.

Anyway, I believe this is the right fix and that it works correctly, but it would be good to get confirmation.

Guess I should assign myself to this...

Also, the fix slightly alters the function used when you add an existing field to an existing content type so I can call that function from the duplication operation, so we need to be sure that operation still works correctly, too. (That's when you select a field to add from the drop-down list instead of typing in a new one).

Did some more testing and found one change (needed to eliminate my test for the type name $new_name which isn't always created). I'm pretty sure it is working right now and I'll probably go ahead and commit soon unles someone finds a problem with it, but here is the updated patch.

I simplified it to eliminate the change to the other function and committed this change.

I'm still seeing this problem with 5.1.