By jkamentz on

I'm considering using Drupal for a web site for our horse farm. (Currently, we have almost nothing, so no history to port.)

I'm trying to grok the Drupal way of doing things, but I've only gotten a little way into it with the time I have for this project. I'm a programmer by trade (Java) and know a little HTML and CSS, so that might help when making explanations. Unfortunately, I don't have much php or database experience. (I do know some SQL.) I'm reading through the IBM articles (about half way through), but at the moment, am having trouble applying the information to my site.

Basic desired design:

I'd like different main sections for the site -- about us, news, shows, horses for sale, the general breeding program, etc.

I'd like /horses/ or similar to be pages about individual horses. Such a page would indicate whether that horse was for sale, maybe have a picture with links to more, some paragraphs of description and then maybe a pedigree chart. I'd also like to be able to include side blocks with references to other parts of the site like shows or news if they relate at all to this horse.

Here's what I think I know :-)....

Drupal (5.x at least) works by mapping the url to a primary node of some sort, queries for related nodes and then generates content for all of them into divs or whatever to produce the page output. CSS or similar then arranges the various blocking into headers, sidebars, etc. etc.

It seems like node / page handling is often with a fixed length handler chain of php methods for general, engine and theme or something like that (at the moment I forget the specifics -- it was several months ago when I was last reading up on Drupal). Most of these handlers (if defined at all), merely re-direct things to invoke the phpTemplate "engine" to use a template file, possibly picked by a naming pattern.

On other parts of the site, I might want references to the same horse, but in more summarized fashion. For example, only a horse's individual page would show a pedigree chart. If referenced elsewhere, thumbnails would be used (if any picture shown at all), etc.

So, how exactly do I go about creating such pages? I can imagine three basic ways of doing this, but don't know if ANY are how things actually work and are done.

1) Create a custom node type for horse and somewhere in that template do everything. So, a page-level template of some sort includes / makes calls to generate blocks like related (news, horses, shows) and pedigree. This way pedigree only shows up on the individual horse pages because that's the only place it's invoked.

2) The horse node type (if it even needs to be a separate node type) is just a little piece -- the descriptive paragraphs. The other pieces and blocks are also separate nodes and their content is templated separately. Somehow (unknown mechanism) Drupal associates them with filtering, so that pedigree chart for a horse is associated with the horse's node, but is filtered / enable such that it only makes it onto the page for that individual horse.

3) To do this requires a custom plugin / module / whatever, where approach one is taken, but done directly by php code.

I'm just having trouble right now wrapping my mind around it and figuring out how things should really work when it comes to actually implementing my site.

PHP, or at least the Drupal code examples in the IBM articles seem far different from object-oriented Java where things are sub-classed, inherited, etc. What I saw looked more like a (fixed-length) chain of handlers.

Another question regarding node types. Would it be difficult to allow general site content to be entered in mediawiki format? Can that capability be applied across many node types, or would one have to define custom node type(s) specifically for this and it would only work with those? On the one hand, it seems like output filters would handle this, but how would they distinguish nodes whose source content was plain text or html from wikitext without some hacking?

Thanks, in advance.

Joel

⋅ Categories: Drupal 5.x, Drupal 6.x

Comments

yelvington’s picture

yelvington commented

You might want to read http://api.drupal.org/?q=api/file/developer/topics/oop.html, although I think you may be overthinking it. It's not necessary to know anything about how Drupal is implemented.

A few basics:

URLs in Drupal are commonly aliased, so /horse/flicka and /horse/fury might actually refer to /node/1234 and /node/1334 respectively. You can make those aliases manually (a field in the node edit form), or you can install the pathauto module and create rulesets that automatically generate the aliases. In the latter case you might take advantage of Drupal's powerful and flexible taxonomy system, which can be tapped by pathauto. You might categorize horses by colors, so you might have /horse/sorrell/flicka as a URL, and /horse/sorrell could be mapped to a view of alll the sorrell horses.

When Drupal gets a request that evaluates to a node, it fetches all the node data, organizes it into an object, and hands it to the template engine, which combines that data with other components to make a complete page. Those other components would include a page design (template), but it's also likely to include other database items such as blocks that might appear in the left or right columns of a normal web design.

Those blocks aren't nodes. They're part of a much smaller and simpler set of data that conditionally can appear on pages. You can create blocks manually, and there are many that are provided by modules. Whether and where they might appear is a point-and-click assignment that is global to the theme (set of templates) that you're using, but you can impose rules that determine what type of pages get which blocks.

The template engine actually calls on a series of templates to build a page. There's a top-level page template, but there also can be smaller templates to format the node content, block content, et cetera. You're right that templates may be chosen through a naming pattern. At many levels in Drupal there's a rule like "use the best match," and the template engine does a lot of that. In the case of templates, there are default hidden inside the template engine, and any implementations in your theme are actually overrides.

It's important to know that the template does not actually do the work of querying the database, et cetera. The business logic is all upstream from the template engine, By the time the template gets involved, the data is mostly cooked and the template engine is only responsible for formatting (or reformatting in some cases) the components, then combining them on the output page.

All of this describes the process of delivering a single node.

But there are other types of pages that are views in which multiple nodes might be delivered, either in complete or in a summary version. That gets to your question about having thumbails on a list view, but a large version on the individual node display. That kind of presentation-level logic is easy to introduce into the node template, which gets called repeatedly to generate the sort of "river of news" page you might see on the front of a weblog.

This is a meandering explanation, but I hope it was helpful. In general you don't need to know any of this stuff. User-level tools such as the Views and Content Construction Kit modules generally let you create the kind of site you're envisioning without writing any code. On the other hand, if you want to create custom designs or extend/override normal behaviors, the door is open for that kind of thing.

rernst’s picture

rernst commented

If you're not already using the views module, download and install it. Create a view for your horses that lets you That way, your site's users can

Use the cck module (and the related cck modules for extra field types): it will let you put fields on the horse content type.

Complex data type representations like pedigree might be a bit out of scope for a CCK field: you might need to do some custom work there.

Using views + cck will save a lot of programming effort, and spare you from fighting with custom php snippets.

If you require custom module development, or consultation on building a Drupal site, I offer those services. If you're interested, please feel free to use my contact form to get ahold of me. A good consultant will save you a considerable amount of time and stress.

nevets’s picture

nevets commented

I would start by laying out each of sections I want for the web site. For each section I would then decide what information I want available. For some such as 'about us' it may actually be a single page, for things like news. shows and horse it is probably a list. For thing like 'about us' you might use the 'page' content type and you could enable the path (and maybe the path auto) module to allow to alias the path. For other content if you need just a title and body you might use the story type and a vocabulary to differentiat them or create simple content types for each. For other content types that need more that a title and body I would suggest using the content construction kit (CCK) module to allow you to create a content type with additonal fields. For those sections/pages that are a list of content I would suggest using the views module to make a page listing either by content type or content type and vocabulary term.

For things like the horse I would consider using a single content type to hold all the information and using theming to present different views of the same data. If the content type was called horse you could copy node.tpl.php to node-horse.tpl.php and make parts of the information dependent on the current path. You could also use the panels module and views module to help with this goal.