1

I hope this counts as an answerable question.

A publications database I'm migrating from another content management system to drupal, has different types of publications. In the current system those publications are kind of the equivalent of a taxonomy. It is clear from talking to people familiar with the history, and from looking at the state of the database and code, that every couple of years they rearrange things, adding or removing content types and changing the fields available. They used to try to dynamically change the fields available on the form depending on the content type. (peer-reviewed journal articles would have volume/Issue, pages, publication name, etc, where books would have different requirements, and online publications would be still different. This seems to have become very hard to maintain, so the current system now makes all fields available for all content types, and sometimes the same field is used for different types of data (total pages and page range for example). There are thousands of publications and sorting it all out programmatically seems quite difficult, so the thought is to bring everything over using the same fields (cleaning up the data where it can be done programmatically). Having differing fields per publication type is desirable, and in the future they would like to have an approvals process built into the system with differing approval paths per publication type.

Initially my approach was going to be much like theirs, to have one publications content type, and a publication type vocabulary to categorize them. Thinking of the need for future divergence of fields, and the likelihood of a requirement to change the display depending on the publication type, I've modified my approach to start with an identical content type per publication type to allow for things to change over time.

Is this going to cause terrible problems for me down the road if they decide that two types of report are now one publication type? I'm already seeing a little bit of difficulty in the ability to make dynamic templates that cover the entire set of publication types. It has been quite painful to move any changes made in one content type over to all the others.

Would it be more sensible to try the approach of having all the fields we need in one content type and trying to dynamically hide or show those fields depending on the publication type selected?

Is there some other more sensible way of going about this that I haven't thought of? It seems like somewhere along the line I'm going to run into pain either changing the fields or with changing publication types, I'm just not sure which kind of pain is likely to be better.

  • has different types of publications how many types are we talking about here? rough estimate. – No Sssweat Feb 3 '16 at 8:53
  • 16 at the moment – UltraBob Feb 3 '16 at 8:54
2

Initially my approach was going to be much like theirs, to have one publications content type, and a publication type vocabulary to categorize them.

The problem with this approach is that you won't be able to use pathauto to give them different paths per type. Ex: You want the books type to be /books/title-goes-here and the cars type be /cars/title-goes-here

If books and cars are the same content type then node author would have to manually type in the url alias.

Also, how do you plan on theming them? If each type needs to be themed differently, I don't know how you're going to pull that off since they are all the same content type.

I think making 16 different content types is the way to go. You can always re-use existing fields whenever you can.

enter image description here

I'm already seeing a little bit of difficulty in the ability to make dynamic templates that cover the entire set of publication types.

You could use the Panels module which allows you to theme all 16 content types differently or the same. With panels you won't have to deal with tpl (template) files.

Checkout this Panels Video Tutorial series

  • 1
    Thank you, it is good to have confirmation that this seems like the right way to go. I'll leave the question open for a while to see if anyone can tell me why it is a terrible idea and I should never consider it or give me some brilliant alternative. Panels: this is one thing I have to get used to about drupal, my strategy with other CMS's is to go almost all stock, but with drupal it seems like if you don't use quite a lot of modules you can't build anything. I've been seeing panels come up a lot so I'll look into it. – UltraBob Feb 3 '16 at 10:00
  • I think it's a terrible idea. You can use taxonomy to do two things. Provide the needed urls and also, implement conditional fields for adding new content. I recently cut down from about 15 content type to 1 based on this. – Niall Murphy Feb 3 '16 at 20:53
  • @Niall Murphy if you could provide the modules and a more detail explanation on how you're doing this, it would be nice. Also, how are you theming different types? thx. – No Sssweat Feb 3 '16 at 23:18
  • Theming is done like you said.. Use Panels except you narrow down the selection rules to the taxonomy of the node. Or the context module I believe if not using panels. Should be able to do block placement etc based on taxonomy. Or even a small custom module that loads a css snippet using some if statements or a switch on the tid of the node. For the urls, you can set a pattern to use the taxonomy term. Check the token browser in the patterns page. For node creation, you can have conditional fields set up so that fields appear based on taxonomy selection. – Niall Murphy Feb 4 '16 at 5:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.