Drupal structure? Help me structure my structure!

August 30, 2009 4:12 PM

I'm trying to create a magazine via Drupal, and I'm having some problems using node references. Should I be using books or taxonomies? Or can you just help me iron this problem out with what I'm doing now?

I'm having trouble trying to determine the best possible structure for a Drupal 6 installation.

Some information about the site I'm making:

it's an online magazine organized into less than 10 articles grouped underneath a single issue. I don't have a use for categories for each article or each issue -- all I need is the structure.

Each article has around ten images associated with it. In addition, I need to designate a 'representative image' for each article that will show up as a thumbnail in the issue page. Also, each article will have small links to the other articles within the same issue.

So far I've been creating three node types: 1) an Issue type, 2) an Article type, 3) an Image type, using Imagefield. Each Image references the Article that it's part of, and each Article references the Issue that it's part of. Also, the 'representative image' for each Article is a node reference to an Image. I'm using custom php code to tie it all together, and it's working, albeit I'm working pretty slowly. Here's a diagram:

Issue --- Article
      --- Article
      --- Article --- Image
		  --- Image
		  --- Image

But now I'm starting to think that I'm overthinking this, and that I should use the book module. The problem with that is that the book module seems to have limited flexibility in terms of making custom themes/layout. I can't even find a good google result how to customize the Book tree that appears within the Book navigation menu.

So what should I be doing in terms of structure? Should I be using Taxonomy, or Book? Or should I just continue to customize things by using node references and hacking php code to tie everything together? Has anyone had similar experiences with Drupal and found the best possible way for this sort of website? Thanks!

posted by suedehead to Computers & Internet (6 answers total)

I'd stay away from the Book module for this and instead move forward with the article nodetype and a way of linking them together. Theming the book module can be a rather painful experience.

From your post, it sounds like you are currently using nodereference inside of an issue node to pull together your nodes. This is a totally valid approach. However, you might run into some complexity when it comes time to order your articles inside of an issue. Is ordering articles a requirement for you?

An alternative approach, which would allow you to order the articles, would be to use the excellent Nodequeue module and a different queue for each issue. You haven't mentioned how frequently you intend to publish, but if it's not too frequently, nodequeue could work.

Another option would be to use taxonomy or a CCK field to classify what issue each article belongs to. Then, you could use the Views module to pull together each issue using the date as an argument.

There are really a lot of ways to skin this cat. However, I would stay away from the Book module for this one. Book module is more useful if you are trying to create an very hierarchical document, like a user manual.

Here are a few case studies that further explain how to create publications in Drupal:
New York Observer - http://drupal.org/nyobserver
Popular Science - http://drupal.org/popular-science
In Fisherman - http://drupal.org/node/497008
posted by JuliaKM at 5:47 PM on August 30, 2009

I agree with JuliaKM, book module is probably the last thing I'd pick. If you're looking for have a final issue that lists all the articles and clicking to each article shows you all the images, then yes, you'll need some php to pull the right things into the right places, but you can do this all at the theme level, which means how things look is fairly compartmentalized from how they are strung together and you can completely change navigation/interface/UX by coming up with a new (or forking your existing) theme.
posted by Brian Puccio at 8:10 PM on August 30, 2009

I should add that some consider any sort of logic in the theme itself to not be the best idea and abstract it out into its own mini module that the theme would then call in the appropriate places, this separating presentation from business logic.
posted by Brian Puccio at 8:11 PM on August 30, 2009

Response by poster: Ah, thanks guys. Ordering articles is not a requirement at all. Nodequeue sounds interesting, and I'll try that out maybe.

Another option would be to use taxonomy or a CCK field to classify what issue each article belongs to. Then, you could use the Views module to pull together each issue using the date as an argument.

This is pretty much exactly what I'm doing -- I do have an issue node, but I'm using a CCK field from each article to reference the issue node. Should I be doing it the other way around -- having an issue node that has multiple references to each node?

Also, Brian Puccio, do you have any tutorials or guides to mini modules?

Thanks a bunch!
posted by suedehead at 12:38 AM on August 31, 2009

Best answer: Ah, I came back to my own question, having learned much much more of Drupal.

If I would do it again, I'd probably use the nodequeue model to order the article nodes, and would add the images within a single node as Imagefields, later resized with imagecache.
posted by suedehead at 5:29 PM on February 16, 2010

Best answer: Okay having learned much much much much more of Drupal, will fix this question for the ages:

The best way to do this is to use CCK node references, on both sides, and to synchronize them with Corresponding Node References. That way, upon Article creation, you reference an Issue with a checkbox. Later, in the Issue, you can use the autocomplete/sort form to sort the Articles.
posted by suedehead at 2:56 AM on June 4, 2010