Feeds Tamper: String to ID

A Feeds + Feeds Tamper plugin that resolves strings pulled in from feeds importers and maps them to Drupal entity IDs, so they can be used as entity references.

Adds support for freeform Entityreference linking when using Feeds.

This means that you can pull in a string label from a feeds source (eg venue="Smithtown velodrome"), and if you have a local node (or user or other entity) that matches that string, it will use entityreference to create a link.

Unlike the others, this does not require that ALL your linked nodes are owned by Feeds importers, only the ones you curate yourself.

The automated lookup (conversion of string to entity ID) can be done either fully automatically (title match) using the entityrefererence autocomplete search, or fully customized, by using views.

Although built around feeds_tamper where it can be fully configured, you can also just use it without the feeds_tamper module dependency if you are content with a best-guess string-to-title match (no options).

Use case:

• Consume an RSS feed, including the remote <author> tag, but don't treat them as local users or just taxonomy tags, instead link to a local biography page that you maintain for each author.
• Consume an 'events' data source, that includes a freetext 'location' field. In cases where your Drupal site has a page about that location, make that field a link to that page.
• Consume a list of products. Where that product has a known manufacturer as a data field, turn that into a reference to a page on your site about that company.

These cases are all for curated lists of target entities, where you are not expected to maintain a complete lists of all locations, all manufacturers or all authors - just the ones you want to support.
If you want to pre-populate your site with a complete list like that, and also have access to the complete list from the service you are consuming, then one of the other cross-referencing feeds+entityreference modules may suit you better.

This module will not auto-create referred items for you, it will only link to existing content.

Comparison with other modules

The base Feeds.module existing entityreference support (also the other modules feeds_entityreference and entityreference_feeds) assumes that both the referrer and the referree content are managed by feeds import processes, and tries to do do the job of re-linking them after importing. They use GUIDs and support referential integrity, but are less flexible when it comes to user-moderated input or you don't have acces to (or want to support) a full downloaded list of all possible values.

This module is built to support simpler cases, where the feed data source only supplies half the story and we need to use the input to refer to our own original or selected content.

feeds_entityreference and entityreference_feeds both had little-to-no activity or usage when I trialled them, and the documentation or code comments were sparse. In both cases, it seemed like they were not trying to solve quite the same problem as stated here.
IF this addition fits with either roadmap, it could possibly be merged, but only if usage examples were made clearer for those ones.

Usage examples

Easy version: consume an rss feed and link to a local authors bio page.

• Set up a content type where the feeds imports will land (eg Article)
• Set up another content type that the first will reference (eg Person)
• Add an entityreference field from Article->Person (eg "Attributed Author"). Configure it to use 'autocomplete' as a data widget.
• Create some content of type 'Person' with titles exactly matching the names of the 'author' field that will be imported.
• Set up the feeds importer using most default settings and mappings for RSS.
• Add a mapping from the "Source:Author name" to "Target:Attributed author: Entity ID"
• Use feeds_tamper to add a "Transform: Convert string into entity ID" action to that mapping rule.
• Choose the simple "Entityreference autocomplete" method of string resolution.

Now, if you run the Feeds import, the recognized "Author name" tags will turn into entityreference links.

Interesting version: consume a products list and link the manufacturer to a local page.

Sure, in manyt cases just tagging it with a taxonomy term would be enough, but we want full entities, and to make a deliberately tricky example...

Say that the 'title' of your 'manufacturer' page wasn't the same as the text that's coming through from the datasource. so we want to do synonyms.

EG, your node structure looks like
title: "Phillips"
But the data sometimes says:
manufacturer name: "Phillips & co; llc.", or "Phillips and company", or "Phillips inc"

This means that you can't trust autocomplete or any other canonic method. Call in views.

So you should:

• Add the alternative labels as data on your content type (multiple values). You could choose not to display them even, and leave the field admin-only.
• Create a simple view that takes a string argument and returns just the entity id of the node that has that string as one of its alternative labels
• Proceed similar to above to :
  • set up your product content type,
  • your entity reference field from the product to the manufacturer,
  • and the feeds mapping rule
  • and add the feeds_tamper : "Transform: Convert string into entity ID" process
• Now use the second "Feeds Tamper: String to ID" option : which is to use a 'view' as the lookup tool.
  Select your new view from the UI.

Now when importing, the view will try to find the appropriate match to incoming labels. You should be able to do any other view tricks, like limiting to certain content types or other criteria.

Details

Multiples

Multiple values are supported! If the target field is set to allow multiple values, and the input contains multiple different values OR the lookup produces multiple valid matches, then all will be linked.

Tampering

You can use other feeds_tamper methods before the conversion to massage the strings, eg convert case or "explode" on " and " so that you can turn handle data like Joe Bloggs and Richard Cranium correctly.

Your own view as a resolver engine

Instructions for constructing the view are on the admin UI.

Basically, you should construct a view that:

• Takes a string as a 'Contextual filter' argument.
• Displays 'fields'
• Returns a row containing just an ID (eg the node:nid) as the first column (not linked).

This view will then be invoked each time a string input is being processed. If it returns one or more valid reults, those IDs will be returned.

If the view doesn't show up on the "Feeds Tamper: String to ID" UI

The list of available views is carefully filtered to ensure that only views constructed a certain way will fit. It MUST use 'fields' as a display, and it must take one (and only one) argument.

TODO

nodereference support would be possible, but seriously, migrate from nodereference to entityreference please.

This can also be used to replace/suppliment the existing taxonomy_term_reference fields and probably user_account mapping also, but there is little point in doing that right now. The only maybe advantage would be adding fuzzy or clever matching to taxonomy term linking, but maybe.

Auto-create is out-of scope. it has a lot of other logical overhead, so it won't happen here.

Credits

Some inspiration and some code snippets were cribbed from
feeds_entityreference - the set_target method
feeds_tamper_php - the tamper plugin api framework
EVA - latest way to work with views in code
entityreference - the autocomplete and API

---

This development supported by:
Sparks Interactive

and partially sponsored by:
New Zealand Film Commission