Download & Extend
Content Type Inheritance Module » Issues

I could sure use this

Posted by Michelle on December 17, 2008 at 8:02pm
Project:Content Type Inheritance Module
Version:6.x-1.x-dev
Component:Miscellaneous
Category:task
Priority:normal
Assigned:netaustin
Status:active

Issue Summary

I have a local area directory that I'm going to be cleaning up and porting to D6 in the coming months. I have these content types: Business, Church, General, Lodging, Medical, Non-Profit, Restaurant, Service, Store, Website. "They all share the same 15 or so fields. But some of them, like Restaurant have more fields. Every time I make a change to the fields, I need to change it in all 10 node types. I've often wished I could base all the others on "General" and have them only list the fields that are changed.

So I'd like to encourage you and hope this becomes a module without a "don't use" warning at some point. I'm sure I'm not the only one in this boat and anything to make life simpler when dealing with a ton of content types is very welcome.

Thanks,

Michelle

Login or register to post comments

Comments

#1

Posted by netaustin on December 17, 2008 at 10:18pm
Assigned to:Anonymous» netaustin

Michelle,

I would appreciate it if you'd check this out and give it a spin! I won't be able to release this as stable until it's been thoroughly vetted by the community.

Austin

#2

Posted by TomSherlock on June 8, 2009 at 3:40am
Version:<none>» 6.x-1.x-dev

Austin,
i agree with Michelle: this is something i could use.

I'm trying to create four different profile types (Parent, Teacher, SchAdmin, Staff) using profile_content to create the profile and placing it on the user's account page. There is a core set of fields that all four profile types share, such as title, first name, last name, e-mail, telephone. And then there are fields that only two share, such as Parent_committees and Teacher_committees and then their are fields unique to each user profile type.

I'll download it and try it out. Hopefully i don't encounter any severe bugs as i'm still a newbie to Drupal.

chx had pointed me this way, btw.

Thanks,
Tom

#3

Posted by John Pitcairn on March 24, 2011 at 9:56pm

+1. I'm just about to begin looking at a content structure that might really benefit from this.

#4

Posted by Michelle on March 24, 2011 at 10:29pm

Sorry, netaustin, I guess I totally dropped the ball on this a couple years ago. :( I ended up vastly simplifying my node types so don't need this at the moment.

Michelle

#5

Posted by zilverdistel on March 25, 2011 at 8:48am
Title:I coud sure use this» I could sure use this

#6

Posted by adan on April 5, 2011 at 8:11pm

Hi,

In an another approach, I've developed a basic module, Webform submission attachments (WFSA), to combine webform submissions with nodes, merging node fields with webform fields in creation, edition an node display.

With it, it's possible to have a kind of flexible node subtype support. I'd appreciate any feedback. Still in development, but functional.

#7

Posted by jason.fisher on May 2, 2011 at 1:16pm

This module represents functionality that I believe should be in core.

I am considering it as a method of abstracting 'sets' of fields by their logical function. e.g. a "Mapping" set may include a map and a viewfield.

If you share "Mapping" with the content types "house", "park" and "checkin", you would have one set of views/fields/workflows for that Mapping component.

A facet could be had across content types simply by their hierarchical relation, or the hierarchical relation of their fields. e.g., by the nature of the shared fieldgroup, if the location of the shared widget is in the same location on the screen, that widget becomes a UI facet by which all other content rotates. Other content being the fieldgroups unique to each content type.

CTools Page Manager could represent a 1:1 relation with the construct in a manner similar to overriding the node_view template page.

I wonder if this functionality shouldn't be centered around sharing fieldgroups instead..

  • Shared fieldgroups could represent the same functional need without having to learn another UX construct.
  • Extend the 'manage fields' tab with a "Add existing fieldgroup .. " option.
  • Fieldgroups get a checkbox/setting "inherit" on any setting/manage form.
  • Allow fieldgroups to be created that are not part of a content type.
  • Do not duplicate node IDs
  • Create an 'entity' for each fieldgroup, allowing Views to access the fieldgroup data for filters.
  • Node: Fieldgroup would be added to Views to allow filtering something "By All Content That Has: [ Mapping ]", constructing SQL that looks like: WHERE node.type IN ('house', 'park', 'checkin').
  • Fieldgroups would be page manager compatible. You could 'view' a fieldgroup at a URL for management purposes. The management panels may be overridden.
  • The fieldgroup displays on a page should receive a 'gear hover' that has extendable options. i.e. a gear that triggers local tabs, with the default 'edit', 'clone', 'override'.
  • The override option would be an extension of the Panels UI, allowing mini-panels to be constructed as the fieldgroup output. The default for any override would be the mini-panel of its parent.

Something to think about..

#8

Posted by jvieille on May 22, 2011 at 8:13am

No replies from the maintainer since a long time ago.
This is a very important feature that should deserve much more attention.
This approach is very intuitive.

Austin, are you still here? The Drupal audience has gained some maturity since your initial release of this artwork

#9

Posted by justingeeslin on October 17, 2011 at 9:37pm

I'd like to see if this module would catch on.

Is this module still alive?
How does ( or how could ) this module mesh with D7 (with Entities instead of CCK)?

nobody click here