Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By lomo on
Okay... I'm baffled. I've got some knowledge of Object Oriented development and would like to transfer that to building up CCK content types, but I don't see a straightforward way of doing that and from searching, it appears that this functionality has been discussed for "future" versions of Drupal since before Drupal 6 was out (now on Drupal 8.x feature request list). I know Drupal developers do have some ways of achieving this, but I'd like to get some feedback about what ways might be best and most "future-proof" in terms of migrating to Drupal 7 at some point in the future.
In my searching, I came upon the Taxonomy Fields module. But it's not even been released for D6, much less promised for D7. I also found mention of the Content Type Inheritance Module, but it's been almost 1.5 years since the last update to that "experimental" module, it's still in "dev" and it looks like only a handful of sites use it; there's no hint that it will be maintained for D7 or made stable.
While planning my site, which will include a directory of local businesses, I had in mind some basic CCK fields which would be shared by all businesses listed. Luckily the "Location" module provides many of them, but I also want to add several other fields common to all businesses and a few that will depend on the business type.
For instance, with restaurants I might want to indicate the number of indoor/outdoor seats, whether or not they have any area for smokers or for children, English menus (this is "abroad" and my site is for English speakers in my area), among other things. Many of these I can achieve through the use of taxonomy, but obviously not "quantitative data" (e.g. I could use taxonomy to tag that a place has patio dining as well as indoor, but not how many seats in each). And of course there's the issue of permissions. It would be nice if permissions changes made to a "base class" of content type would apply to all "sub-classes".
I'm also planning to create a multi-axis rating system where the different axes would vary by business-type. (I found the guide, Multi-axis Review System using Fivestar with Views Implementation for Drupal 6, of interest, but that would also mean creating totally separate "Review" types, though my more complex reviews could easily be extended from the "base class", so to speak... at least if there were an easy way to extend a content type.
Any tips from a seasoned Drupal developer who has worked around this limitation of core and CCK would be most appreciated. I've been looking everywhere for some hints, but have yet to figure out what kind of "best practices" might apply to what I'd think would be a fairly common use case. Many thanks, in advance, for your advice.
Comments
Did you ...
Did you try using the Ctools import and export facility to clone an existing/base content type? That could allow you to save some (minor) amount of work recycling field type assignments.
I haven't yet tried that...
Thank you for your response. No, but I do have the Chaos tool suite installed. And I guess that might be what is giving me the option to import/export in the content type creation page. (It's hard to not want to install every module Earl Miles has had a hand in developing. ;-) ) In any case, I was considering doing just that, but was wondering if there might be any "more elegant" ways to extend a content type than simply creating a new type with all the features of another, plus some more. Ideally the solution I'm looking for would allow me to add to the "base class" (base content type) and see those changes reflected in types derived from it and changes to permissions, etc, of a "base type" would also be inherited.
I don't expect to figure out a method of doing this that truly takes full advantage of inheritance, though, so perhaps that's as good as I'll get. I'm guessing that this "clone" option doesn't clone permissions?
Anyway, cheers for your contribution to muddling through this step. I'd appreciate any other input anyone can provide, too. Alternative solutions?
See you at the Drupalcon!
What I read is that you have
What I read is that you have a need for conditional fields.
So for example, if they say they have patio dining, only then do you ask for the number of seats.
The Conditional Fields module is useful for cases like this.
You can also mimic OOP with content types by reusing fields (last option on the "manage fields" tab), this way multiple content types can say have a 'shared' location field
I was considering that module...
Cheers for your reply and recommendations.
I had installed the Conditional Fields module, but haven't yet worked with it. I think you are right, but it could get messy with lots of different content types. The question is whether that integrates with taxonomy so that if I categorize a business as, e.g. an auto repair shop, I won't see fields for restaurants, but fields relevant to services provided in such businesses, and if I describe the "service style" as "kiosk" (snack bar), I won't display fields for certain "restaurant-only" attributes, etc.
As far as outdoor (patio) dining goes, I was thinking of just having an integer entry where "0" is default for outdoor seating. But perhaps your suggestion is better when it comes to display.
Were you suggesting that I could use the Conditional Fields module to solve all the issues of having derived "content types" (multiple sub-types of content) or just that it might be worth using in addition to creating semi-redundant content types, because your suggestion to "reuse fields" seems more in line with the latter idea. Perhaps the Conditional Fields could also be useful for my "Business Review" content type since it will have multiple fivestar rating fields, some of which will only apply to certain kinds of content.
Anyway... Thanks for your suggestion to try the "reuse fields" option. That could save some development time setting up content types, for sure. :-) And I'll be sure to see what I can do with the Conditional Fields options, too.
See you at the Drupalcon!
Same issue.
It's always interesting when I find a forum post dated the exact same day that I myself had the exact same questions. I have been thinking about this all day. I have done multiple searches on OOP and Drupal. Examined the same modules and I am just disturbed that I am going to have to write a bunch of custom node modules instead of simply extending one.
I have a hierarchical node system in which nodes will extend others. Think parent is 'item' with field 'weight'. 'Container' extends 'item' with added field 'volume'. 'boat' extends 'container' with added field 'floats' = TRUE.
Do I really have to redo everything everytime I come up with a new subclass???
What if I want a node that is 'backpack' and I need to know how much it weighs, what's it's volume and lastly what color is it??
This should be so easy with an extensible node system. As it stands, I am seriously considering just writing my own code that goes straight to the database and avoids using a node altogether, Instead, I'll make my own forms that extend parent forms.
The sad part is that now I can't rely on the ease of views and CCK for all the other great things they afford me.
I tried the inherit module. Started getting bugs as soon as I installed.
Actually.
I think for my needs. Just reusing CCK fields will work very well! I never really thought about the use of reused fields, but now I see how awesome they really are.
Very true...
Reusing fields is awesome, if you won't be changing them at all for any of the content types that use them. If you need to customize it for one content type though, you can't "reuse" it, since I believe any changes made to a "reused" field apply to all of them.
OTOH, that's good news if you have made a logical change to a field that you DO want to apply to all content types that use it. MANY of my content types will use the "Location" field that I've set up and since it's customized fairly significantly away from default, it's nice to be able to just "reuse" it.
I still haven't dug in enough to figure out if I can use taxonomy with conditional fields to make my content types be "one size fits all". That would be ideal since otherwise I could end up with a LOT of different content types and "review" (rating) types that reference them. Ideally, one review type should reference all of my "content" types and I should just be able to make changes on entry. And also ideally, some of the "taxonomy" (or categories) on my main content type should already be added if I click on a link to add a new business within a particular category.
Lots still to figure out, but I'm pleased with my progress (so far). I would just rather not run too far down a "wrong path" and have to redo everything... especially if I've already started to add content and could lose it... and really especially after I've launched and others' content could be compromised (or lost) by changes I might make in refactoring for design concerns. :-/
See you at the Drupalcon!
subscribing
subscribing
Same problem
I'm working on a project where my client wants to ask questions to his users - with very simple answers (two fields) - over time. So every time they logged in, they would be asked a question. The data will be used to populate a chart that would be one of the key aspects of the site.
I want to have a CCK type, Questions, that will automatically inherit the question from a parent CCK type in addition to two fields for user input. Certainly, if he creates hundreds of questions, it would get ridiculous to have a new content type for each question. I suppose that the reuse fields method could be applied here, but I feel that there is a lot of room for error, and in any case it will be extra work for the client to add those fields for every question.
I believe that Taxonomy fields or Content Type Inheritance Module would have worked for this...
Does anyone have a suggestion for me?
I've used Flexifield with some success
Flexifield create a field that is basically just embedding an entire other content type.
It has it's drawbacks. It's not actively maintained.
The "Status of this module" section of its project page also might have some clues on this type of functionality being built into CCK and Views. The only problem with that functionality is that it requires 3.x of both CCK and Views which at this time are both alpha releases. Since they're alpha releases I haven't explored them yet.
Take a look at
Take a look at http://drupal.org/project/field_collection for d7.