Using CCK and Views to change a content-type's frontend appearance

Events happening in the community are now at Drupal community events on www.drupal.org.
DrupalCuckoo's picture

Hi,

I've created a new content type with CCK and called it "Blogs2". Very basic stuff (Title, Description, Additional Plain Textfield for an URL). When I click "Create Content -> Blogs2" I can create a new "Blogs2 Node" (Image 1).

After saving my new node, I get this view (Image 2). The Textfield for the URL is at the bottom of the description so you can't see it right now.

I've also created a new View to show an Collection of all created "Blogs2 nodes". This is what it looks on the frontend (Image 3) and here's my "Views Configuration" for this Collection Page (Image 4).

My Question is: how can I change the appearance of the "Blogs2 Node" (see image 2)? I'm using "Autopath" to generate paths. The Collection Page has this URL www.tld.de/blogs2/ and every "Blogs2 Node" has an URL like this pattern: www.tld.de/blogs2/[node-title] (in the case of image 2 the node-title would be "google").

I tried to create a new "Page" within my View to overwrite the standard display but it didn't worked out.

What do I have to do to solve my problem?

Thanks for any help. :)

Comments

The quick answer: In the

Garrett Albright's picture

The quick answer: In the directory for the theme you're using (looks like Garland in your case), find the file named "node.tpl.php" and copy it, naming the copy "node-[nodetype].tpl.php" - so "node-story.tpl.php" or "node-page.tpl.php" or what have you. Then empty your site's cache. That file will now be used to display content of that node type, so you can now edit the "node-[nodetype].tpl.php" file to modify the way that nodes of that type are displayed.

The long answer: You might not actually be asking a theming question, because you seem to give a lot of information irrelevant to that, such as how the paths are created. If you're not, please clarify your question. But if you are, then what you're basically asking is "how do I theme Drupal?" which is a pretty big question which entire books have been written to answer.

Thanks for your answer. The

DrupalCuckoo's picture

Thanks for your answer.
The "quick answer" is a way I thought about but I wasn't sure if it's the right solution for what I try to do. I'm not really asking how to theme drupal.

Let me give you an example what i'm trying to do:
In te first image you can see a textfield with the label "Webseite" (german for "website"). Here you can enter an URL (http://blahblah.com). The type of this textfield is "plain text" so Drupal will not automatically wrap this text with html to make it a real link. But I've seen in Views that you can take a field and wrap it's content with html so it becomes a link. To do so, I need to alter, overwrite or replace the display of my "Blogs2 nodes" (see image 2).

This is just a little example but to know this would help me a lot.
How can i do achive this?

Thanks for your help :)

Perhaps the Link CCK field

Garrett Albright's picture

Perhaps the Link CCK field can do what you're looking for?

…But in some ways, you're still basically asking how to theme Drupal, which is something that can't be easily answered in a post here. It's a pretty big topic…

So, you're telling me that if

DrupalCuckoo's picture

So, you're telling me that if I want to alter the standard output of any content-type I've created with CCK, I need to create a new template file for this particular content-type (node-myContentType.tpl.php)? But what's Views good for if I can't do such a thing? Is Views only good for creating new views?

My example of wrapping the content of a plain textfield with html was just a "fake problem" I chose to try solving it with Views (but thanks for the link).

I know that Views basically is just a query creator but there must be a way to alter the standard output of an content-type.

Thanks again :)

Is Views only good for

Garrett Albright's picture

Is Views only good for creating new views?

Or editing pre-existing Views, yes. The comments below make me wonder if maybe I'm misunderstanding what you're asking for - are you really trying to use Views to change the appearance of a single node? That's definitely not the way to go about it.

It looks like node-[type].tpl.php is the answer that you're looking for.

malks's picture

I'm thinking though that using a single item view would be a PHP free way of getting the result that the OP requires? Create two pages from the same default view and you can have two different formats of a node? Wouldn't that be easier than having to do logic in your PHP or am I missing something?

Anthony.

It may be a way to do the

Garrett Albright's picture

It may be a way to do the job. It is not the right way.

why's that?

malks's picture

Curious on your views (ha ha) on why it would be a wrong way to do it?

Simple: Because Views is for

Garrett Albright's picture

Simple: Because Views is for creating lists of nodes (as well as lists of other things, but we're talking about nodes for now). That's what it's designed to do from the ground up. Though it does give you a great amount of control over what fields of a node it should display in its lists, it's not designed to be a tool to customize how a single node looks. That's using a hammer to drive in a screw. Maybe it works for you, for now, but if you ever hand that site off to a more experienced Drupal developer, they're going to wonder what you possibly could have been thinking.

Instead, do yourself and your successor a favor and learn to use a screwdriver - learn to use Drupal's theming layer, the intended way to get this job done.

Guess we'll have to agree to disagree.

malks's picture

I still think the edge case of a single item list is valid especially as the OP didn't seem keen to write PHP code. I'm not a big views user, but find it great for rapid development applications, and while in this case I would personally use templates to theme the node, using views to style single nodes still seems to fit in that pattern for me. So if it works for someone, good luck to them I say.

Thanks for your thoughts.

There are several main

merlinofchaos's picture

There are several main reasons not to do this:

1) hook_nodeapi will not be called.
2) Views will not mark the node as having been read.
3) node/% is exactly one menu callback, so you have to have Views answer for every node in the system. You can't have it be selective. (People often wonder why this is and forget that node/1 is handled by precisely the same code as node/2 even though node/1 is type 'page' and node/2 is type 'story'. Sure eventually they branch but it all starts at the same place).

If you want Views to handle a node for a specific type, you have to use Page Manager (and Panels) because it will handle all of the above issues.

That's fantastic background.

malks's picture

I'm enjoying this discussion, and even though it's not my chosen path to implement I'm going to defend the single item view one more time, and maybe learn something along the way :)

1) and 2) might be show stoppers if that function is required, but 1) isn't really in the hunt if it is a view only rather than edit access of the node?

3) If I read the OP's original requirement right (what happened to the OP btw?), then node/% wouldn't be overridden but rather something like blogs2/[node-title] would be what you are accessing?

But what's Views good for if

merlinofchaos's picture

But what's Views good for if I can't do such a thing? Is Views only good for creating new views?

You clearly have no idea how offensive this comment is.

I'm sorry. This wasn't my

DrupalCuckoo's picture

I'm sorry. This wasn't my intention.

Perhaps create a new view that displays only one node?

malks's picture

I'm going to jump in and try and answer this even though I don't consider myself a great views user... Remember views is primarily used to create "lists" of data, so if you want to change the look of a single node, would having a view (list) that only returned one node (that is, it had an argument which was passed an nid value) and then restyling that as required solve your problem?

Anthony.

Whoa!

derekwebb1's picture

Not including Drupal itself, Views is the single best project on Drupal. It is probably the only module that I can say without hesitation "I always use". Views' usefulness is nearly incalculable however it is not used for styling content types (a node). It is great for building lists of content (that is developing complex DB queries without necessarily writing SQL code). You may then style the elements of those lists using the templating mechanisms made available by Views. Views is extremely full featured in this respect and, coupled with preprocessors, allows you to build your content displays in more ways than all of us combined could imagine.

Now, it could be done, though as others have pointed out, that is not what Views is made for. The theme layer is there to give you the ability to style individual nodes. So, you would create a node template called node-blogs2.tpl.php, copy your regular blog or node tpl code into it and re-work it as needed.

Using Views in the manner you have proscribed is a very bad idea. Using views to build lists of your nodes, users, or other entities, is a good idea.

If you are going to take Drupal to the next level you will have to come to terms with the fact that the theme layer exists for a reason. Use it and you will be happier with your results. And others, should they join you in your projects, will not desire to strangle themselves or you when making additions or changes...

There are also ways of templating individual CCK fields so that if Blogs2 has different fields (named differently - not necessarily different in function) than Blogs, you can apply different classes, and subsequently styles, to them. Theming fields is also a good idea since you are then able to move them around using CCK field management mechanisms.

At any rate, thats just my two cents.

Cheers, Derek

A comment on theming fields: http://drupal.org/node/269319#comment-893493 and http://drupal.org/node/269319#comment-911336

Sorry for my late reply. I

DrupalCuckoo's picture

Sorry for my late reply. I had no internet connection last week.

First of all, thanks for all of your answers :). They give me a different view on Views (haha!) so I think I should learn how Drupal really works before I jump right into it with such detailed issues.

But I still think that solving my Problem by creating a design-template for my content-type wouldn't be the right solution. This is why I think so: My content-type contains the fields "Title", "Body" and "Weblink". The output of these three fields are all standard text. If you forget for a second that the "Title" Field has the html format to be an Headline and the breaks in the "Body" Field are changed to paragraphs there's no html formating that would give the output a function (such as changing the "Weblink" Field into a real html link). Headline and paragraphs are not functional, they're design related.

A design template should never give the output a new function. In my case, altering the "Weblink" Field to a html link by using the design template would break the seperation between content and design. A design template should only be used to change the look of something but never to change an function. The output should provide a link by itself.

Ok you could now argue that if I want the "Weblink" field to behave as a link, why did I give it the field-type of a plain textfield and not a url link field. First, the standard CCK module doesn't have such a field type (now I know that I can install a additional module to expand the functionality of CCK) and second, I thought I could do this with Views (because Views offers me the option to change a selected field into a link field). But maybe this is also the wrong way.

I hope you understand now why I don't want to solve my problem by using a design template.

Let's say you split the functions of Drupal into a "content layer" (in this layer the functions of any content are also included) and a "design layer" (this layer is only responsible for changing the look and feel of the "content layer", therefore it sits ontop of it) where would you put "Views", "CCK" and "Design Templates"? I would say CCK is in the "content layer". Views would be in the "design layer" because it pulls content together to present it on one side. But since it can give fields additional functions like changing it into a link, I'm not sure where it belongs to. "Design Templates" are completely in the design layer" respectively "Design templates" represent the whole "design layer". This layer do not change the functions of any content.

So, how can I solve my problem? Maybe you could comment on the last thing (where I talk about splitting Drupal into different layers).

Thanks for any help. :)

Solving your problem

RalphSleigh's picture

The right answer: change your text field to a link field. If you have lots of data in this field already converting it could be tricky.

The slightly less right answer: Override the theme for that field using a template something like content-field-weblink.tpl.php

For custom themeing this module is your friend: http://drupal.org/project/devel_themer Use it to tell exactly what functions or template files are being used to generate any bit of output, and what overrides and variables you have available.

On the other point: I think CCK is part of the model, and views the controller, but both also contain view code to output results. In Drupal the distinction between model+controller and view its pretty clear, any function that starts theme_xyz() is part of the view and can be overridden in your custom theme. Best practice is to ensure you don't have any logic in your theme code, hence the slightly less right answer as it violates this as you said (as do some of the convenience options for turning a field into a link in the views module).

.

michelle's picture

You're really limiting yourself if you won't change anything at the theme layer. Drupal's preprocess functions are extremely powerful and let you change the data that goes to the templates. If you're talking about not putting functions in the actual template files, yes, that's true. But don't ignore the power of the theme layer's preprocesses.

Michelle

Michelle said: You're really

DrupalCuckoo's picture

Michelle said:
You're really limiting yourself if you won't change anything at the theme layer. Drupal's preprocess functions are extremely powerful and let you change the data that goes to the templates.

As I said before (and as you mentioned by yourself): creating a design template to change the "Weblink" Field into a real Link Field would be the wrong way. I will make a design template but only to configure the look and feel of my page, not to add additional functionality to it.

Michelle said:
If you're talking about not putting functions in the actual template files, yes, that's true. But don't ignore the power of the theme layer's preprocesses.

Yes, that's what I'm talking about :-)
How can I add a link functionality to my "Weblink" Field without creating a design template?

RalphSleigh mentioned, that I should use the field type "links" inside CCK to create a field with the needed functionality.

The right answer: change your text field to a link field.

Is there an alternative way to change a field's functionality (again, creating a design template is not a option)? If not, I'll go this way but if there's a different way then please let me know :-)

Preprocess

michelle's picture

Well, in this case, using a link field to begin with makes the most sense. I was speaking in more general terms. By stubbornly clinging to this idea that you can't change anything in the theme layer, you are shooting yourself in the foot. The whole point of the preprocess system is to make changes before printing the content.

Michelle

Hmm ok I see your point ...

DrupalCuckoo's picture

Hmm ok I see your point ... it's slowely making sense in my brain ;-). Could you provide me some usefull links about "preprocessing"? Thanks :-)

But, am I write when I say that using themes would break the seperation of content and design? Is this the way Drupal works most of the time? I was thinking that trying to keep those to things completely seperated should be the highest goals when it comes to making a design template.

I'm not very good at

jtbayly's picture

I'm not very good at following ideals, although I think they make good guides for how you should think about something. Then, after you understand the concept, you need to grasp the reality. That's when you discover that real life doesn't give you the luxury of perfectly following the ideals a lot of times. :)

But yes, in my opinion (which frankly, isn't worth much in this particular discussion, because I've never even modified a .tpl file! HA!) you want to separate the content and the design. But it's almost like there is a spongy layer in the middle where things get blurry. Is that content, or design, or neither? You basically want to do a cost-benefit analysis of the various options. If the technically best answer is stupidly hard to achieve the desired results, and doing the next best isn't likely to cause any sort of major confusion or difficulty in the future, go with the theoretically second best, because reality is harsh and just shot your first choice in the head.

What I mean is, sometimes you do want to do things with the theme, that just don't feel quite right! But given the difficulty (or impossibility) of the other options, it's the right way to go. At least that's what I've found, I hope that helps. (I make other people edit the .tpl files for me when those situations arise.)

Yeah. There are some pretty

jtbayly's picture

Yeah. There are some pretty sweet things you can do to the content right at render time. For example, you could take all of the text and turn it into pirate talk if somebody selected the pirate theme in their preferences. That would be an example of using the theme layer to heavily modify the content. Obviously, you don't want to do that prior to the theme layer! Maybe this is stretching things or not helpful. If so, ignore me.

Actually, you should do that

Garrett Albright's picture

Actually, you should do that before the theme layer - and with this module, you can.

Just goes to show what I

jtbayly's picture

Just goes to show what I know.
:)

What do you mean with "before

DrupalCuckoo's picture

What do you mean with "before the theme layer"? How can I create a layer between the content layer and the theme layer? Can I have a layer just for content altering? Michelle mentioned "preprocessing". Is this what you mean? How does this work? Could you give me some links? :-)

Thanks for your help :)

Layers

michelle's picture

The module he linked to is a filter. Filters are applied before the content is handed over to the theme.

Preprocessing happens in the theme layer. It's where you modify what Drupal gives you into the form you want to print in the template. Best practice is to have mostly variables in the template and avoid calling functions or having other code as much as possible. So you do all the heavy lifting in the preprocess functions and hand off the results to the template.

You can find out more about how Drupal theming works here: http://drupal.org/theme-guide/6

Michelle

Thanks for the Link! :-) I'll

DrupalCuckoo's picture

Thanks for the Link! :-) I'll have a look at it.

Links seem like a good example

jtbayly's picture

Sometimes you might want a link to be displayed as a link (a href) but other times you might want to display the text of the link. It probably depends on the location in the site. So you can use the theme layer to decide based on what page is being viewed, how the content should be displayed.

I think you're talking about

DrupalCuckoo's picture

I think you're talking about the same Michelle is talking about, right? Your example made me see themes in a different light, thanks! :-)

Yes. I meant that to be a

jtbayly's picture

Yes. I meant that to be a response to her comment.

Views Developers

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: