First, remarkable how usable the D7a2 release is, congratulations.

I nearly described this as a bug but wasn't sure. AIUI, previous issues have made sure that when a node is created, the summary will be generated. But the summary (teaser) is a separate field and it seems like it ought to be possible also to map to it.

Based on http://drupal.org/node/622700#comment-3669444 I got as far as this mini-module to retrofit it:

function mymodule_enable() {
  cache_clear_all('plugins:feeds:plugins', 'cache');
}

function mymodule_feeds_processor_targets_alter(&$targets, $content_type) {
  $targets['summary'] = array(
    'name' => t('Summary'),
    'description' => t('Overrides the automatically generated teaser of the node.'),
    'callback' => 'mymodule_set_target',
  );
}

function mymodule_set_target($node, $target, $value) {
  if (!is_array($value)) {
    $node->body['und'][0]['summary'] = $value;
  }
}

but although the first function works (having renamed the hook from the one in the manual) the second doesn't seem to do anything.

Any clues gratefully received.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alex_b’s picture

Status: Active » Needs work

Mapping to summary should be a part of the summary text field mapper in mappers/field.inc.

dotman’s picture

Hey Alex, I don't see the option to map to the summary field in Feeds. I'm using version Feeds 7.x-2.x-dev and drupal 7.2 Am I missing something? What addition/change to the file.inc file would I nned to make to see that field for the mapper using node import and a csv?

Thanks.

zambrey’s picture

subscribe

tngcas’s picture

Hey,
I need this functionality as well. Has anyone made any progress towards getting this to work?

Thanks.

drupert55’s picture

Subscribing - I need this, too.

dotman’s picture

i would be more than willing to contribute paypal to the maintianers for a patch. I really need this.

thanks.

Taiger’s picture

I was trying the equivalent on the theme layer. I discovered that ['und'] is not there when you try to use it.
Here is the preprocess function I made:

function videomaker_preprocess_node(&$vars) {
  // makes the summary easily available to print in the node-template as a new node variable $vm_summary
  if($vars['type'] == 'magazine_article') {
  $vars['vm_summary'] = $vars['body']['0']['safe_summary'];
  }
}
dotman’s picture

hey taiger, could you explain how i would apply your code to feeds and which file so I could map a field in my csv to the summary?

thanks.

Niklas Fiekas’s picture

Status: Needs work » Needs review
FileSize
1.47 KB

Put @willmoy's code in a patch. Not so confident this is the correct place to do it, but it seems to work.

denix’s picture

Thanks Niklas, it works fine with Feeds 7.x-2.0-alpha5. I am now trying to find a way to make it multilingual using feeds entity translation.

Peacog’s picture

Version: 7.x-2.0-alpha2 » 7.x-2.0-alpha7
FileSize
1.38 KB

Thanks for the patch, I have re-rolled it for 7.x-2.0-alpha7, which replaces field.inc with two files, text.inc and number.inc.

dddbbb’s picture

Patch in #11 worked for me.

dawnbuie’s picture

This worked for me too - Thank you!
I'm surprised more people haven't registered that this functionality was missing.

timtk’s picture

Am not sure if I am missing something here. I have version 7.x-2.0 alpha 7 and I cannot see where to go to make the summary entry seperate from the main Body.

In the mapping there is not option to map the Summary field.

Peacog’s picture

After you apply the patch in #11 you should see Body (Summary) immediately below Body in the dropdown list of targets when you add a mapping. If you have renamed to Body field, (for example you might have called it Description) then you'll see Description (Summary).

MegaChriz’s picture

I think issue #1329626: Auto generate body_summary for node on import? deals with the exact same problem.

ykhadilkar’s picture

Patch #11 works fine.

I see that language is hard coded in multiple places.
For example 'und' in following piece of code ...
$entity->{$target}['und'][$i]['summary'] = $v;

I wonder if there is better way?

fureigh’s picture

#11 worked for me as well. Thank you!

DrupalChimp’s picture

I'm having a bit of an issue after applying this patch. My body text is filtered HTML. It would import fine before applying this patch. After applying the patch the summary goes in fine, but the body no longer imports. (Not sure if the filtered HTML has anything to do with it.)

Any ideas?

DrupalChimp’s picture

Status: Needs review » Reviewed & tested by the community

Ok, scrap that last comment. It does work. However there's an important point here and that is that the summary must go after the body in the mapping, otherwise it doesn't work.

Otherwise I can confirm that this patch works.

twistor’s picture

Version: 7.x-2.0-alpha7 » 7.x-2.x-dev
Status: Reviewed & tested by the community » Needs work

This patch uses the older style of mapping. Also, the comment from #20 means that it needs serious work. We cannot have order dependent mappings. This needs to be rolled against dev.

chrisrcooper’s picture

Patch #11 is still working against the latest dev, but does appear to need some work to bring it up to par.

MegaChriz’s picture

Status: Needs work » Needs review
FileSize
9.74 KB

This patch is based on the patch in #23 of #1329626: Auto generate body_summary for node on import?.

What this patch does:

Other then the patch in #11 of this issue, the mappings can be defined in any order (I tested this manually).

The patch still uses the old style of mapping as mentioned in #21. It doesn't add any mapping config as I thought that didn't make sense for this case. In UI terms of speaking, the summary field looks like it is an other field.

The trimming option is left out
The patch from #23 in #1329626: Auto generate body_summary for node on import? also added an option to trim the summary with text_summary(). If that should get back in, then that would be candidate for a mapping option. I didn't see a reason to keep that option though, because why should you want to trim data to be imported with the text_summary() function? If you want to trim data, then you can also use the Feeds Tamper module for that. So I left that out for this patch.

MegaChriz’s picture

twistor’s picture

Status: Needs review » Needs work

Thanks for consolidating issues.

  1. +++ b/mappers/text.inc
    @@ -11,21 +11,32 @@
    -  $text_types = array(
    -    'list_text',
    -    'text',
    -    'text_long',
    -    'text_with_summary',
    -  );
    ...
    -    if (in_array($info['type'], $text_types)) {
    -      $targets[$name] = array(
    -        'name' => check_plain($instance['label']),
    -        'callback' => 'text_feeds_set_target',
    -        'description' => t('The @label field of the entity.', array('@label' => $instance['label'])),
    -      );
    

    This should stay the same. We should just add an extra check after for the summary target.

  2. +++ b/mappers/text.inc
    @@ -77,3 +88,68 @@ function text_feeds_set_target($source, $entity, $target, $value) {
    + * Callback for mapping fields of type "text_with_summary".
    + */
    +function text_with_summary_feeds_set_target($source, $entity, $target, $value, $mapping = array()) {
    +  // Handle non-multiple value fields.
    +  if (!is_array($value)) {
    +    $value = array($value);
    +  }
    +
    +  // @todo In issue #1588938, setting a text format per field is proposed.
    +  // If that gets in, this piece must be rewritten.
    +  // @see https://drupal.org/node/1588938.
    

    This entire function is unneeded. Mapping to value, or summary should be the same operation.

We can set the default column to 'value' by doing, list($field_name, $column) = explode(':', $target . ':value')

@see file.inc

MegaChriz’s picture

@twistor
Your feedback makes sense. I'd like to provide a new patch for this issue, but maybe I should wait to see where #2093651: Simplify target callbacks. will go to as an eventually new patch provided here would conflict with the patch provided there (same piece of code is touched).

EDIT: linked to wrong issue.

hanksterr7’s picture

Hi. I applied the patch in #23 and I now see Body: Summary in the list of targets in the Mappings section of the the config of a Feeds Importer instance. This is good! I can also define a Command in Parser Settings, map that command to Body: Summary, set a default value for this Command in my Mailhandler Source instance, and now when I import nodes from email, the Body: Summary is filled in with my default value. All good!
I also now no longer get the "Notice: Undefined index: summary in node_tokens() (line 142 of..." entry in watchdog when I import emails into Group Posts. (that's what got me to this post). Not sure if the patch in #23 was expected to do all of this, but works for me.
My question is: the comments above mention a new vs old style of mapping config. Where are the two types discussed? What version of Feeds has the new config?
Thanks

byrond’s picture

Issue summary: View changes

The latest patch in #2093651: Simplify target callbacks. was committed, and #23 still applies cleanly and seems to work. Looks like it's safe for @MegaChriz to provide an update.

MegaChriz’s picture

Assigned: Unassigned » MegaChriz

@byrond
Thanks for the notification. I've added this issue to my agenda. I don't have time to provide an update right now, but hopefully in about 2-3 weeks.

MegaChriz’s picture

Status: Needs work » Needs review
FileSize
8.76 KB

This patch addresses the issues in #25. I had token mappers/file.inc as an example.

It also splits the automated test FeedsMapperNodeSummaryTestCase into two test methods, because in that test two types of behavior are tested: if mapping to summary works and if the summary gets cleared out when the imported value is empty.

MegaChriz’s picture

Assigned: MegaChriz » Unassigned
trond7’s picture

The patch (both 30 and 23) fails at the latest version of feeds (7.x-2.0-alpha8).
File: feeds.info --> ok
File: mappers/text.inc --> FAILED

Keep up the good work, I really need this mapper.

nadavoid’s picture

@trond7, The patch in #30 only applies cleanly to the current HEAD (latest commit on branch 7.x-2.x, or commit a8468ac9b0e1a5f380b9c803f2b258537a1ba5ff). I tried to apply the patch to 7.x-2.0-alpha8, but there are some things that the patch does in mappers/text.inc that rely on more recent commits.

Ravenight’s picture

#30 worked for me.

hekele’s picture

#30 is working fine.

Ravenight’s picture

Update: #30 is working to import into the summary of a long text field however, when I import it is reverting the primary body field to "Plain Text" format even if it was already processed as "Full HTML".

twistor’s picture

#36, I just wrote a test for your described use case, and it seems to be working correctly. I also tested it manually.

Here's a new version with the added test, it also consolidates some things. MegaChriz still gets credit.

MegaChriz’s picture

I've reproduced the issue in #36. If you set "Text format" on the node processor settings to "Plain text" (see attachment), the body field's format will be set to "Plain text", even when mapping only to the "body:summary" field. This happens with both patches (from #30 and #37).
However, the issue seems not be caused by the patch: when - without the patch applied - you map to the body field, the body format will also reset to the format that is selected on the node processor settings page. So, setting the body's text format doesn't happen only when creating nodes, but also when updating nodes. The body format will not reset when you do not map to the body or the summary field.

Should we try to solve the issue from #36 here, or handle that in #2224643: Support for input format configuration on a per-field basis ?

@twistor, thanks for the future credits :)

twistor’s picture

Ok. That doesn't seem like a bug at all. I guess there's some possibility it could be considered a bug, but if Feeds is controlling that field, then it should set the text format.

#2224643: Support for input format configuration on a per-field basis Seems like a decent work around. It wouldn't fix changing individual nodes' text format, but I would venture to say that's unsupported.

Edit: Ohhh, it took me a minute. We should only set the format when mapping to the field, not the summary.

twistor’s picture

Ok, the issue should be fixed. Added a test.

Cleaned up a few minor things and found a bug in WebTestBase, so that was fun.

  • Commit 47872f1 on 7.x-2.x authored by MegaChriz, committed by twistor:
    Issue #962912 by twistor, MegaChriz, Peacog, Niklas Fiekas | willmoy:...
twistor’s picture

Status: Needs review » Fixed

Thanks all!

MegaChriz’s picture

And thanks for the credits! I still need to test the change in action, but codewise it looks good.

Status: Fixed » Closed (fixed)

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

brtamas’s picture

FileSize
10.36 KB

I tried to upgrade the patch to work with 2.0-alpha9 release.

joey-santiago’s picture

to me the #45 is not enough. Also had to rework the function text_feeds_set_target as the body:summary target is not found on the entity. So i added

  if($target == "body:summary"){
    $entity->body['und'][0]['summary'] = $value;
  }

there.
I'll add this to your patch @brtamas :)