By dave bruns on

I'm building a site that will have a number of custom content types with custom CCK fields. I'm wondering if there are any significant advantages or disadvantages in trying to share CCK fields across more than one content type?

For example, I have a content types called 'event' and 'program' and they both have a CCK field 'location' attached to them. My instinct is to keep things separate and have two distinct CCK fields 'field_event_location', and 'field_program_location', so that there is no dependency between the two content types that has to be managed later.

I realize I'm skipping over obvious questions (e.g. do the content types need to be displayed together in views/calendars?) but I'm really just looking for a gut response from folks who have experience managing custom content types with fields that could be shared.

Thanks in advance for any thoughts.

Dave

⋅ Categories: Drupal 6.x

Comments

BradM’s picture

BradM commented

I've not shared any across content types, only because I haven't had a need to do so. Maybe if a content type is to be chosen from a drop-down list, then it would make sense to just create one "location" field and then share it across types...this way if you need to add/delete places, you only have to modify one field.

no2e’s picture

no2e commented

I'm interested in this topic. What are (all) disadvanteges of sharing CCK fields?

I've got a nodereference field. The selected Content Type can be selected by several other content types. Shall I create a new nodereference field for each additional content type, or shall I use the very same field for all content types?

no2e’s picture

no2e commented

Let's say, I have content types "DVD", "VHS", "Laserdisc".
Should I use the same CCK Date field for "Publication date",
or should I create an own CCK Date field for each content type?

Same for fields like "Author", "Production country", "Price", "Language", etc.

What are the advantages, what are the disadvantes of this?

chasz’s picture

chasz commented

i am very interested in this, because i DO want to share CCK fields across contenttypes.

1. am too lazy to create the same fields again.
2. there is no obvious advantages for having separate cck fields.

they are just input fields to enter data into the DB

gforce301’s picture

gforce301 commented

I share fields all the time accross CCK content types. It depends on how you need to configure the field. Some properties of a field are independent per content type and some are not. This is identified when editing the field.

Mainly I use it to make things easier on myself. For instance, any time I have a CCK type that needs a date I reuse the same date field as long as it's common configuration will work for my new content type. This has the advantage for me of the field always being referenced as $node->field_date, which just makes it easier on me when I have to write code to use it. It is always called the same thing no matter wich content type it is used for. It has no drawbacks that I am aware of other than the property restrictions I mentioned.

chasz’s picture

chasz commented

well tell us how you are sharing the cck fields? apart from remake the same field for each contenttype

gforce301’s picture

gforce301 commented

Did CCK change that much in D6? In D5 when you go to add a field to a content type with CCK you are presented a list of field types to add: text, date, node_refference, etc.., depending on which field modules you have enabled. Right above that is an option select and if you have already created some fields on a different content type they will be listed in the selector with a big "Add Field" button right underneath it.

Did they remove this in D6?

WorldFallz’s picture

WorldFallz commented

It's now on the 'Manage Fields' tab, but it's still there.

===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz

gforce301’s picture

gforce301 commented

I am glad this handy feature of CCK has been preserved.

chasz’s picture

chasz commented

either i have misunderstood or you have

Are we talking about cck field types or "custom" cck fields?

cckfield types: text, image, links etc are shared thoughout the website

BUT if i make a custom cckfield called MY_FAV_LINK for the contenttype PAGE.....using the shared ckkfield type, links, then this field is NOT shared between STORY, PAGE etc contenttype.

i have to remake this field for ALL contenttypes

chasz’s picture

chasz commented

hmmm sorry there is an existing field option LOL

edit: however you need to remake your fieldgroup names

gforce301’s picture

gforce301 commented

Yes but then the conversation was not about field groups ;)

minesota’s picture

minesota commented

If sharing is possible and suits the content types of your site this is the best thing to do I beleive
because resources are well utilized then, less database load, easier management etc

no2e’s picture

no2e commented

Thanks gforce301 and minesota for your opinions/explanations.
So I'll share my "common" CCK fields from now on.

gforce301’s picture

gforce301 commented

One advantage that I forgot to mention: In views when choosing a field to add to the view, this will keep the drop down list shorter (easier to work with) as a field is only listed once no matter how many content types it is used in.

ressa’s picture

ressa
he/him
commented

If you share a field between different content types, the settings will change on a global basis if you change for example the max. length of a field, when you add the shared field to a new content type. Just something to keep in mind, but powerful if you know it!

SanDiego’s picture

SanDiego commented

I realized that when you share a field between different content types a separate table is created.

E.g. say you have two content types company and employee, both of which needs to store phone. If you use separate fields then you would have the following structure:

content_type_company (Table)
field_company_phone (Field)

content_type_employee (Table)
field_employee_phone (Field)

If you use a shared field "field_phone", you would have the following structure:

content_type_company (Table)
content_type_employee (Table)
content_field_phone (Table)

When you list the fields of the employee table, for example, you will have to do a JOIN. Doing a JOIN for many such fields might slow down things but I am not sure if it would be significant.

mattcasey’s picture

mattcasey commented

My first intuition was wrong, I assumed it would be faster with one less field if you shared it, but in fact it requires a separate DB query for the extra table. Here's a related blog post that echos parent. Of course, he recommends avoiding CCK altogether if you're really concerned about performance and only have a "handful" of fields.
http://www.morningtime.com/Drupal-6x-Performance-Guide/II-Advanced-Drupa...

bonked’s picture

bonked commented

http://www.morningtime.com/Drupal-6x-Performance-Guide/II-Advanced-Drupa...

The link above is somehow broken, This is the correct link and helpful to the discussion..

---
"If you are thinking, you are winning. Resistance is victory"

littleneo’s picture

littleneo commented

I was wondering about this thanks SanDiego.

in Drupal 6 at least, starting from the last example (shared field "field_phone"), if you remove field_phone from employee the table content_field_phone elements goes back to the content_type_company as a field :

content_type_company (Table)
content_field_phone (Field)

content_type_employee (Table)

very consistant, Im drupalized.

now I need to know if this module also clone datas, so you can safely reverse back to non-shared fields if there's a need at some point.