Eliminate unnecessary content types

[patdunlavey]

At the moment, we have 23 content types. This is confusing at best, and a configuration headache. The only real reason to create different content types is when you have a functional distinction that you need to capture. For example, I created a new content type for the 728x90 pixel banner ads because we need to validate upon submission that the images are correctly sized; and node submit validation is a function of the content type.

We have a separate content type just for the home page - good grief!

A number of content types have twin versions with " (m)" which seems to correlate with those content types being used in the nodes that instantiate the main menus. E.g. there is exactly one node of content type "News (m)", titled "News", which is placed on the "Secondary links" menu, with the menu link title "News". Doesn't BreakingD understand that any node can be placed into the menu structure??! You don't need to create special content types for the purpose! The "Documents" content type is identical to the "Page" content type. The only justification I can see for this is to control who can author what. But since they're functionally identical, what exactly are you controlling? We're using taxonomy to expose content out into different sections of the site, and TAC-lite to control who can apply those taxonomy terms. That really should cover it.

I would propose that we, first, get rid of those content types that have no current or clearly envisioned usage (Image, Profile and Courses content types have no nodes at all). Then eliminate those "(m)" content types. Finally, audit the remaining content types and condense them down to a small functionally distinct number.

[ousaweb]

I think that the (m) content types are ones that "automatically" add and arrange the content that they're linked to (i.e., create a page that sorts/files them... for instance, the news page, http://orienteeringusa.org/news , has the right-hand columns that I have nothing to do with -- the information is updated with news posted in the various months, and with the various news types). I only realized this recently. Deleting them will delete that functionality.

Documents, Banners, and Sponsors are the other (m) content types to which items are added this way, rather than just creating a node and linking it the old fashioned way. I don't know if the similar items without the (m) are also needed (perhaps as an archive of all of that content)...

[ousaweb]

I believe 'Image' was set up when DanF was still involved (before the decision to "move things along" by going outside to BreakingD); I don't know whether 'Profile' and 'Courses'(?) were meant to be used or just something someone installed. I personally don't envision 'Profile' being used unless it's needed down the line in commerce. And I wasn't aware of 'Courses' and have no idea what that's for.

We should have you on board from the beginning! BTW, is anyone else (Greg) on Github or is it just you and me at the moment?

[patdunlavey]

I think I'm starting to understand what BreakingD did, and maybe even a bit why. Their approach is not conventional at all. Basically, they pushed down into a number of specific page template files a lot of what is more normally done using blocks and regions in a single page template. In the Drupal theming system, you can have a different page template called for each content type, but that's not the usual approach for most content. The more traditional approach is to define one basic page layout in your theme with a content region, one or two sidebars, header and footer regions. Then you create blocks (which are, conceptually, another kind of content) and you configure the individual blocks to appear on some pages and not others (based on the page's path). If a particular region is not showing any blocks for a given page, then your theme's page template should be smart enough to adjust accordingly, e.g. expand the content area when just one sidebar is being used. A drawback to this conventional approach is that a lot of the site design is contained in the content and its configuration, i.e. the database. An advantage of BreakingD's approach, whether intentional or not I cannot say, is that more site design is held in code, which means that you can version control it, fork it for different sites, etc. Ultimately, however, I think it's an approach that does not really understand "the Drupal way", and leads to a lot of confusion and maintenance headaches. I suspect that BreakingD developed a lot of their practices working in non-Drupal contexts.

Anyway, I created a new issue on the broader problem with this, and will leave this issue to deal with just eliminating the clearly unnecessary content types.