If you're using the rendered teaser of a node and then using strip_tags to send the markup to facebook, you could end up with all sorts of buggy-looking artefacts from contextual links or field formatters etc... I think it would be better to use text_summary() on node body?

So 

        //'description' => $node->teaser, // TODO: how in D7?
        'description' => drupal_render(node_view($node, $view_mode = 'teaser')),

into

'description' => text_summary($node->body);

Patch to follow

CommentFileSizeAuthor
#13 fb_body_text_summary.diff1.46 KBDave Cohen

Comments

lightsurge’s picture

lightsurge commented

Above should be $node->body[LANGUAGE_NONE][0]['value'], but I suppose the field to use for a teaser should be configurable on the content type edit page really, using the body might not make sense for some sites and sometimes it might even be unset.

Overall though I do still think using text_summary() on a configured field would be better. Or I suppose you could go one step further and create a view_mode, but I still think that would be awkward and therefore maybe overkill.

Dave Cohen’s picture

Dave Cohen commented
Category: bug » feature
Status: Active » Needs work

According to http://api.drupal.org/api/drupal/modules%21field%21modules%21text%21text..., text_summary() function appears in Drupal 7 and is not in Drupal 8. I'm open to better ways to produce the post text, but I don't want to introduce something that makes the Drupal 7 version different from both Drupal 6 and (when it is implemented) Drupal 8.

Dave Cohen’s picture

Dave Cohen commented

Remember also you may implement hook_fb_stream() to change the description. Look for $op == FB_STREAM_OP_PRE_POST.

lightsurge’s picture

lightsurge commented

Apparently text_summary() is still in 8.x, but doesn't appear in the documentation.

http://drupal.org/node/221257#comment-6915814

Anonymous’s picture

Anonymous (not verified) commented

I just did the same as was proposed in #0 after I found references to all sorts of content not available in my theme posted on a facebook page. Like "read more - edit - delete - posted by …" and so on for a node without body text or summary. This was a funny one, spent half an hour fiddling around with metatags:opengraph because I thought it might break something using empty tokens, before I finally ended up browsing fb_stream.module's source and stumbled across the "//TODO" :-)

It works fine now, FB just goes on and grabs a piece of actual content from the page instead of stuff only visible to logged in users like contextual links.

Dave Cohen’s picture

Dave Cohen commented
Assigned: Unassigned » Dave Cohen
Status: Needs work » Needs review

Sounds good I just need to test and commit.
Thanks.

Dave Cohen’s picture

Dave Cohen commented
Status: Needs review » Needs work

I don't think text_summary($node->body) is right, nor $node->body[LANGUAGE_NONE][0]['value'] (why LANGUAGE_NONE?)

If anything, I think the original drupal_render(node_view(...)) is closest to right. Possibly there should be another view_mode specifically for facebook posts.

lightsurge’s picture

lightsurge commented

text_summary($node->body[LANGUAGE_NONE][0]['value']) is actually much closer to $node->teaser (as in the 6.x version of this module) than drupal_render(node_view($node, $view_mode = 'teaser')) is.

And why render a node just to have facebook strip out all the tags, leaving artefacts like the remnants of contextual links? I can see a use-case for choosing a different field for fb_stream, or setting a token-based template for the fb_stream output, but having thought about it personally I wouldn't go as far as a view mode. Just don't think there's enough space in a facebook message to bother with that.

Dave Cohen’s picture

Dave Cohen commented
Status: Needs work » Fixed

I'll leave it as text_summary($node->body[$node->language][0]['value']), with the possibility of changing it if that turns out to have problems.

There's always hook_fb_stream() as a chance to override that behavior, for content types where another view mode makes more sense.

rhoean’s picture

rhoean commented

$node->{'body'}['und'][0]['summary'],
this piece of code has worked for me without any problems thus far

kulma’s picture

kulma commented

$node->body[$node->language][0]['value'] didn't work for me for a multilingual site as $node->language was different from the field language.
field_get_items() however did work.

$field_items = field_get_items('node', $node, 'body');
$description = text_summary($field_items[0]['value']);
Dave Cohen’s picture

Dave Cohen commented
Status: Fixed » Needs work

Thanks that looks better.

Out of curiosity, what is your $node->language vs what keys are in $node->body?

Dave Cohen’s picture

Dave Cohen commented
Status: Needs work » Needs review
StatusFileSize
new fb_body_text_summary.diff1.46 KB

Here's a patch that uses field_get_items().

kulma’s picture

kulma commented

$node->language is 'en' while the field language is undefined.

Based on my limited experience with drupal i18n modules I think this is by design. Fields are set as untranslatable by default, which means they will be saved as 'und' regardless of node language. You would need to enable the entity_translation module to make fields translatable.

Thus a lookup for $node->body['en'] will fail. I guess $node->body['und'] would work with the current i18n, but that would fail with entity_translation enabled. Using the field api will make it entity_translation proof!

Dave Cohen’s picture

Dave Cohen commented
Status: Needs review » Fixed

Pushed this change, at long last.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.