Presently setting per content-type defaults only works for the set example feed output. Explaining to all users how to set mapper fields for the feedapi nodes the can submit: "choose this vocabulary for keywords, this cck field of choice for author-name etc." is quite confusing - and is often just the same mapping for lots of feeds.

The per content type feeds settings could be extended by having each mapper adding fields (as per hook note in the code) - probably still a good thing to do. But a quick simple addition/alternative:-

Allow (users with correct privs) to set the default content-type mapping from a feed node mapping that they are submitting. Just a check box on the bottom of the standard feedapi node mapper form. This way you get to see a real feed example to choose the mapping from and set the default.

I've separated out privs for this as you probably don't want all users who can map to set the default.

To make it consistent the patch also shows the default mapping even if the feed (the example on the content-type, or another actual feed) doesn't actually have the default fields at that time (yes even some RSS feeds actually sometimes have fields in them sometimes not).

Patch rolled against DRUPAL-5, will roll against DRUPAL-6--1 if people think this is a good approach.

CommentFileSizeAuthor
#8 316606_default_mapping.patch2.7 KBalex_b
#5 DRUPAL-6--1 patch without additional permissions - feedapi_mapper.module.20081012-d6-defaults.patch3.31 KBekes
#4 DRUPAL-5 patch without additional permissions - feedapi_mapper.module.2008101201.patch2.92 KBekes
DRUPAL-5 Patch - feedapi_mapper.module.2008100201.patch1.84 KBekes

Comments

alex_b’s picture

alex_b commented
Status: Needs review » Needs work

I like the feature - but:

can we do this without adding extra permissions but by using the 'advanced feedapi options' permission instead?

ekes’s picture

ekes commented

Agree it can be done without the additional permissions. Maybe I'll make that a different patch?

It does make sense to allow people who can create feed nodes to be able to map those individual feed nodes, but not be able to administer the whole of feedapi!

alex_b’s picture

alex_b commented

"advanced feedapi options" - this permission only exposes advanced options on the feedapi form part of the node form - not the whole feedapi adminstration...

ekes’s picture

ekes commented
Status: Needs work » Needs review
StatusFileSize
new DRUPAL-5 patch without additional permissions - feedapi_mapper.module.2008101201.patch2.92 KB

Right, sorry... and absolutely agree then.

Attached.

ekes’s picture

ekes commented
StatusFileSize
new DRUPAL-6--1 patch without additional permissions - feedapi_mapper.module.20081012-d6-defaults.patch3.31 KB

And a D6 version...

AntiNSA’s picture

AntiNSA commented

I would like to use this feature... but a bit scared of untested stuff as I have tons of stuff installed and cant troubleshoot everything ..... any reason why this isnt or plans to roll this into the official feedapi mapper release?? Im using D6 and would like to know if anyone is having any issues with this, and if I patch it is it going to conflict with any future upgrades?

alex_b’s picture

alex_b commented
Assigned: Unassigned » alex_b

Yikes. I need to review this. Sorry for delay.

alex_b’s picture

alex_b commented
StatusFileSize
new 316606_default_mapping.patch2.7 KB

I'm very happy with the functionality this patch adds to feedapi.

Some adjustments:

* In feedapi_mapper_form() always pass on type (content_type) to submit handler - not only if node id is set.
* Move 'Make this the default mapping for %type nodes' checkbox into 'Edit mapping' fieldset
* Don't store per node mapping if 'make this the default mapping' is selected - store only per content type mapping.

I've not tested this patch.

While this is really great functionality, I think we're not quite where it should be yet. One problem currently is that the checkbox unchecks after submission - that's unusual behavior and could make many think that the submission did not work. Also, when the user comes back to this screen, she doesn't know that the mapping she sees is the default mapping. Another problem with this patch may be that a submission of the content type mapping form might destroy the default mapping (I haven't check this).

Proposed adjustment:

* The checkbox on a per node mapping page should read "Default mapping", it should be off per default and should keep its status once changed.
* Let's check whether the mapping form on content types breaks mappings defined on nodes. It could go away entirely.

Side question: What does this piece of code do? It gives me a PHP notice because $path is not always an array. I'm not sure whether this foreach loop is necessary at all.

// Show stored mapping no matter if elements aren't in the feed as retrieved at this time.
  foreach ($mapping as $path => $path_mapping) {
    $elements[implode('->', unserialize($path))] = $path;
  }
alex_b’s picture

alex_b commented
Status: Needs review » Needs work
AntiNSA’s picture

AntiNSA commented

wokr it Im waiting :)

alex_b’s picture

alex_b commented
Assigned: alex_b » Unassigned
mickfuzz’s picture

mickfuzz commented

This would be great for us!
subscribing

illmatix’s picture

illmatix commented

This would be amazing feature!

Subscribing

alex_b’s picture

alex_b commented
Version: 5.x-1.x-dev » 6.x-2.x-dev
Status: Needs work » Fixed

This is solved now in 6.x 2.x : http://skitch.com/alexbarth/b4bqs/uav-set2-r-map

I'm actually envisioning an even more flexible setup, a little along the lines how filters work:

- on node/id/map and on admin/content/node-type/id/map we should be able to create new mappings, name them, save them.
- on the same pages, node/id/map and on admin/content/node-type/id/map there is a listing of saved mappings with radio button choice of which one is the active mapping.

Will open a separate ticket.

Status: Fixed » Closed (fixed)

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