Let mappers declare mapping targets
| Project: | Feed Element Mapper |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Mappers should be able to declare what they're mapping to.
Now _feedapi_mapper_get_field_names() tries to determine what fields are available on a node. The result of this function is an array of field names as strings that is then being used in an argument to invoke hook_feedapi_mapper('list', $node, $field_name).
This is backwards.
We should invoke hook_feedapi_mapper('list', $node) without $field_name and let the mappers decide what the mapping targets for the given node type are.
E. g. : In the case of the taxonomy mapper, this would just require checking which taxonomies are available for the node type at hand.
Fixing this will remove _feedapi_mapper_get_field_names(), _feedapi_mapper_get_node_form() and helper functions - some rather hackish pieces of FEMP.
#1
My first shot at this improvement.
Outstanding tasks:
I'm feeling very good about this change. This was completely backwards before. Let's get this into the next beta release.
#2
I saw the following issues when i applied the patch:
- under the Description of available mappers, only the taxonomy shows up
- Error message: notice: Undefined variable: field_name in /home/aaron/developmentseed/feedapi_mapper/feedapi_mapper.module on line 598.
- at Edit mapping, the select boxes are empty, only the 'No mapping" option appears
#3
This fixes the notice
#4
Here is a new version.
I see the following problems:
- The description will show up in all cases when the related module is enabled. (could be solved by filtering out by actual mapping targets)
- the location module (6.x-3.1) become incompatible. A title is a must now for the location entry.
#5
Just read the patch, this is looking good. Didn't actually test it yet. We should address the descriptions issue, let's hide them if a mapper is not available.
Outstanding:
* Update API documentation
* Fix descriptions.
* Add human readable names to all mapping targets: http://skitch.com/alexbarth/bms15/untitled1
I assign this to you, Aron.
#6
I tested the patch in #4. Applies fine. I am mapping to textfield, textarea, links w/ single and multi value, and date fields, and these are all working.
#7
#8
#9
I applied this patch to local copy of feedapi_mapper head. Applies fine. I then used it for mapping content, link, and date. I also tested http://drupal.org/node/433260 while doing this. Everything is working fine.
#10
Committed, please update your working copies.
I created a follow up issue for handling descriptions of mappers that aren't available: #439164: Grey out descriptions of mappers that are not available.
#11
Automatically closed -- issue fixed for 2 weeks with no activity.
#12
Hello.
Although I'm not totally clear about what this is used for, can it be used for creating associations between the node and the mapped field AFTER a feed is mapped to e.g. emvideo?
I am trying NOT to have to delete all of the nodes and lose their URLs/node IDs by 'Removing Items' then 'Refresh'(ing).
I'm using the 'movie' content type and FeedApi Node to create nodes from feeds.
I'm using Drupal v.6.13.
Thanks.
#13
Hello again.
I guess I should have changed the Status from 'closed' to 'active' for my previous reply?
#14
#12
"I am trying NOT to have to delete all of the nodes and lose their URLs/node IDs by 'Removing Items' then 'Refresh'(ing)."
That sounds like a contradiction to me. What are you trying to do?
This is not related. Please open a separate issue.
#15
Thanks for your reply, alex_b
Feel free to close this if you still think this is unrelated.
There is no contradiction in my previous reply.
The mapping feature is nice to have but its shortcoming is in existing nodes that are created before applying 'Map'. It's fine for nodes added after mapping but unless the existing nodes are deleted via 'Remove Items' and then 'Refreshed', only a handful of nodes on the next feed update will make the new association between the mapped URL and the embedded video. This leaves the feed items pages with a maybe 2 out of 10 nodes with the embedded video. The remaining 8 have no video unless they are deleted and recreated which drives up the node id numbering system and also can affect search engine pages that had already been indexed.
There need to be a way to be able to make the association to the existing nodes using the 'Refresh' feature which it does not do currently.
So the bottom line is the mapping feature needs to somehow repopulate the array(?) which it does not do sufficiently right now.
Where should I add this observation? Is this a separate issue?
Thanks.
ADDED#1: The index also needs to be rebuilt because the one (1) node that doesn't show on the page listings with the other feed nodes is found via 'Search'.
ADDED#2: In database table 'content_type_movie', the following 3 columns have the value 'NULL':
field_emfield_embed, field_emfield_value, AND field_emfield_provider
The nodes associated with these NULL values don't have the video embedded. It's as though the mapping routine didn't rebuild the database table values for existing nodes upon 'Refresh'. Also, it doesn't seem like re-indexing was done after the retrieval of the latest feed update when one additional item was added. I believe this is why the total number of items listed on the feed node pages differs by one from the number of published nodes in the database and why that additional node DOES show up in 'search'.