Posted by Julien PHAM on May 11, 2006 at 9:59am
| Project: | Content Construction Kit (CCK) |
| Version: | 4.7.x-1.x-dev |
| Component: | content.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi,
How work teasers with CCK text field type? I mean, in my .tpl.php file, I did a php checkout with if $teaser, and it works fine, but how can I then print the teaser ? $node->teaser does not work.
Does CCK handle teasers now?
And if not, what I did before is that I stripped the content of one text cck field, but how can I access such a field in cck? The field is named "text".
Thanks
Comments
#1
If not: I have code for this. Can make it into a patch if needed.
Can someone who is working with a recent head pls comment?
#2
It looks to me like there is only a body value in the current code, no teaser. There was a feature request a long time ago to add an option to each field as to whether or not to include it in a teaser. Might be a good time to resurrect that. I think the database configuration has stabalized now, so maybe this could be added sometime in the near future??
#3
Just noticed the second part of the question about accessing an individual field value. I posted something in the handbook (http://drupal.org/node/62468) about how to see what fields and values are available.
#4
This is a working implementatation. We modified more then just this, so the patch might not apply cleanly.
It patches the .install and the .module, and you have to hit upgrade.php to fix the database changes.
#5
And this is how the interface looks.
We allow for :
show in teaser only
show in teaser and body
show in body only
show nowhere.
with two checkboxes.
#6
wow! Drupal checks mime by extension. talking about oldfashioned concepts :)
here is the same file with .png
#7
Looks very interesting. I'll try it out.
#8
How to apply this patch? I do not know how to apply patchs with ONE file for several modules ;)
#9
I think there is a little problem.
The latest CVS version of content.install is the 1.9 one, and the patch is for the 1.6.
The latest CVS version of content.module is the 1.59 one, and the patch is for the 1.36.
#10
Julient. did the patch fail?
I know its a patch against an older version, but IMO that should not really matter in this case. since the code that is affected is not very much changed. Is that correct?
#11
a UI request to save for later if Ber's approach gets applied : it would be really handy to have these two checkboxes (in teaser / in body) on the content type fields overview (the table on ?q=admin/node/types/content-my_type/fields).
Something like :
On line per field
columns :
- label (editable textfield)
- name
- type
- ops (configure | remove)
- weight dopdown select (or up / down arrrows a la views edit form ? or (hem...) JS-prototype style drag and drop reordering ?)
- show in body checkbox
- show in teaser checkbox
+ Submit button under the table...
Composing your nodes theming for field-rich content types might be a real PITA otherwise...
(Sorry Ber, that's not a real patch review - my cck code files are already reasonably patched...)
#12
Yes the patch fails as there were some changes between the two versions, some different lines so it cannot find the strings to replace, especially in the file : content_admin.inc
#13
@yched. No. I am very much against these in-table forms.
first: Who decides what options get in that table and what not. Why tease/body there, but required not? and why not put the "tag/title" textfield there? ETc. That is a neverending story.
second: Having it all in one place is consistent.
third: Forms in overviews are confusing. They also require you to have the overviews, instead of simply the objects.
fourth: Drupal core has done a great job getting rid of most of its forms-in-overviews, and is moving towards a consistent object-action model. We should try to make CCK fit into that.
So: no: I vote against putting these in the overview table. Let us please stick to the Core concept of object-action.
* object-action in this sense means that you have an object (e.g. a field) that has several actions: view, use, edit, etc. Each of these actions have a single dedicated page. field_123 has a dedicated page with all its settings on field_123/edit.
Bèr
#14
Ber :
Who decides what options get in that table and what not. Why tease/body there, but required not? and why not put the "tag/title" textfield there? ETc. That is a neverending story.
Not a good argument IMO. That's the definition of a _choice_ (and the definition of UI design) : no objective and unquestionable criterion, but reasoning, discussion, and maybe adjustments...
The question is : what is the (a ?) right balance between usable and cluttered ? Meaning, what are the few options that are worth showing up in the fields overview for the "common needs".
It seems to me that it's what the community is there for. With some people (JonBon and JVD here ?) having the final cut.
"there can be a debate, so let's not" doesn't seem a right motto...
second: Having it all in one place is consistent.
That's a quite restrictive concept of "consistency", that goes against "usability".
UI is choice. A good UI is good choices, not lack of choices.
The "overview with common operations / complete settings page per item" pattern is quite common is software UI, and denotes in no way a lack of consistency, but rather mature conception of the featured functionnality (what is "common operation" / what is "advanced.setting")
I'd say it's even more required for web apps UI, due to page delivery time.
third: Forms in overviews are confusing. They also require you to have the overviews, instead of simply the objects.
My opinion is that forms in overviews are extremely handy. Can you imagine admin/block overview without the form items ? Argh :-)
The few that are currently included in drupal ui (admin/node, admin/block, book structure overview...) are IMO the best parts of the UI (or at least point in the right direction). There could have been other choices done there, and some other options might be more suitable for my particular needs, but I'm glad the current ones are there. I often wish admin/menu, for instance, would have more of that.
Besides, in this case, the overview is already there (and required indeed : that's where you know what you have in your content type). Overviews are a good thing to have.
fourth: Drupal core has done a great job getting rid of most of its forms-in-overviews, and is moving towards a consistent object-action model. We should try to make CCK fit into that.
I wasn't aware that the historical trend was in that direction. Please no ! If this is the case, then it's a real pity IMO. Once again, that's an acception of "consistency" that is not what clever UIs are made of.
I have no doubt that you already had to order 20+ items in a menu / vocabulary / whatever, setting weight on each item's page - makes you want to scream :-)
#15
sorry about the poor formatting of my post above.
wrong use of 'quote' instead of 'blockquote' tags + preview broken :-)
#16
The patch does not seem to apply with the current cvs, so I did not test it, but I like it.
#17
I'd like to add that I don't think that the larger issue of "how to present forms" should be debated here. We need this feature, let's try not to block it because of a debate that amounts to a matter of personal taste. This UI may not be perfect for everyone, but at least it is very consistent with the rest of Drupal. If anyone wants to propose a better UI afterwards, he can simply submit it as a separate issue. ;-)
#18
assigning this to myself. Thursday I have a big CCK day scheduled, so I hope to upgrade this patch to 4.7.
#19
FYI: This issue was a duplicate of that one.
#20
I spent a few hours trying to adapt Bèr's patch to the latest CCK code. My PHP skills are basically nonexistant, but I got some of it to work. I keep getting an error that has me stumped:
Any ideas? No teasers is kind of a dealbreaker with CCK.
#21
Um. I wiped my database, reinstalled CCK, and I'm still getting the same error when I try to create a new content type. The only thing I can think that's changed is I upgraded from 4.7 to 4.7.1.
#22
@talkingwires: See http://drupal.org/node/64905, the patch in #8 should fix the problem.
#23
Thanks. I've got it so it doesn't spit out any error messages now, but it just doesn't seem to be inserting the "in teaser" and "in body" fields into the database. I think this is beyond me. Hopefully someone who is more skilled in PHP will take a crack at it.
#24
FYI: Nick Lewis has made an interesting post on his blog about theming teasers with CCK nodes.
#25
Bèr,
did your Thursday give you a chance to update your patch to 4.7?
--
Olav
#26
Here's a mod of Nick Lewis' CCK teasers hack:
<?phpfunction _phptemplate_variables($hook, $vars) {
switch ($hook) {
case 'node':
// Create CCK teasers hack
if ($vars['page'] == 0) {
switch ($vars['node']->type) {
case 'content-case_study':
case 'content-white_paper':
/* Believe it or not, all you have to do is pass the field through
the existing node.module function node_teaser()! */
$vars['content'] = node_teaser($vars['field_body'][0]['value']);
$vars['links'] .= ($vars['links'] ? ' | ' : '') . l('Read more...', 'node/'.$vars['node']->nid);
break;
}
}
break;
}
return $vars;
}
?>
#27
From a User point of view, Bèr's approach to the teaser is much more friendly than the ContentTemplate module one, and obviously to the hack above.
It reminds the Flexinode teasers way and could be more suited for a final release. ContentTemplate could be still used by advanced users who want to have more control over the style of their teasers/bodies.
Are teasers this way going to to happen anywhere soon, or is anyone planning to resurrect this patch?
#28
Here is a rerolled patch against 4.7 for content.module. we still need to reroll the patc for content.install.
#29
no. here is the patch.
#30
The patch does not apply to the latest CVS version, but applies to content.module 1.56.2.2. So I manually added the needed database columns (show_in_teaser, show_in_full_article) and tried it. I'm getting the following messages, and node content is not displayed:
* warning: implode(): Bad arguments. in modules\cck\content.module on line 307.* warning: implode(): Bad arguments. in modules\cck\content.module on line 308.
Those lines 307 and 308 are in content_view():
function content_view(&$node, $teaser = FALSE, $page = FALSE) {$content = _content_field_invoke('view', $node, NULL, $page);
$node->body = implode('', $content['body']); // <---------- line 307
$node->teaser = implode('', $content['teaser']); // <---------- line 308
$node->readmore = ($node->body != $node->teaser);
}
In my test, $content ends up being an empty array. Maybe I missed something?
#31
Hello,
Having the same problem as the earlier user. any further update available on this one.
Thanks
#32
you get these implode warnings because there is no content in teaser and body. yet.
please create a better update path, that adds the fields to the body and the teaser by default!
#33
Some groundwork for this feature has been laid with the introduction of formatters. One can now call
<?phpcontent_format('field_foo', $node->field_foo[0], 'default', $node);
?>
to get the full version of a text field, and
<?phpcontent_format('field_foo', $node->field_foo[0], 'trimmed', $node);
?>
for the teaser version. This should help pave the way.
#34
this patch doesn't seem to apply at all any more.
JonBob, where would the best place to make those calls be? In a $op='view' case of content_field()?
#35
i'm looking at updating this patch but the problem seems to be that content_view() only calls _content_field_invoke() rather than _content_field_invoke_default(). so there's not really any place to check if a field is enabled for the teaser. i suppose that some of the hook invoke code could be copied into content_view()...
#36
another patch has been committed to handle this
#37