Hey again twistor, one more suggestion for your consideration...

BACKGROUND: In my scenario, I'm using feeds to import data from a CSV into simple database tables (managed with Data module). The file I have to work with isn't ideally formatted, and so I'm using feeds tamper to convert the data to something that views handlers can better work with... n/y to 0/1, simple year to UNIX time, legacy ID to drupal uid/nid, etc, etc. (I can contribute these back if they seem like they might be universal enough :)

My content type will be created on a regular basis (weekly, monthly, whatever), and I'm using feeds to import CSV data from that period. Situations may differ, but it's my guess that anyone doing something similar will only want to ask the non-technical end-user to upload the file, and not to select the machine-code plugin name (under the correct source field name, which may not be known) every time they create a new node.

SO... Is there a foreseeable way to allow default feed tamper plugins on a per-filter-importer basis? That way, I can just hide the feed tamper fieldset on the node edit form so as not to confuse. Feel free to point me in the right direction if you have any thoughts :)

CommentFileSizeAuthor
#5 feeds_tamper default patch.zip4.84 KBbrycesenz
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

twistor’s picture

Assigned: Unassigned » twistor

Oh boy do I have thoughts! I haven't come to a conclusion yet however. Defaults are definitely needed. Also, an option to hide the fieldset altogether is a good idea. Looks like we're going to need another interface for setting defaults and options. hmm...

As a side note, the plugin api has changed (not substantially). It will most likely change again as I find new use cases for plugins.

patcon’s picture

ok cool, thanks yo. I've got to look into it, but what would you think about have the default option on the feed importer settings page. To under processor, there'd be an extra link below "Settings" and "Mapping". Would this make sense?

Or even, skip the extra link for "processors", and have a link beside each source field at admin/build/feeds/edit/school_results/mapping

There could be an option under "Settings" to set defaults, and if unchecked it would be as it is currently, and if checked, each source field could have a link directed to admin/build/feeds/edit/school_results/mapping/[source]

Does that satisfy use cases?

brycesenz’s picture

For what it's worth, I agree patcon. The Feed Importer admin section already allows for setting default values for XPath queries, etc. By allowing this section to administer what is set as the default for each importer, you don't really need to change any of the other UI.

brycesenz’s picture

On second though, I think this wouldn't be too hard to implement with a slightly different interface.

What if, for each instance, the user had to select which feed importers (and fields within those importers) the Tamper instance would be exposed to. Additionally, the user could indicate whether or not the Tamper instance should be a default for that particular importer field. These settings would then be saved back into the 'settings' field in the 'feeds_tamper_instance' table.

This would I think have three benefits:
1. Solving the default issue (obvi).
2. Allow the user to selectively expose the Tamper instance to only certain fields. This avoids clutter on the Feeds Tamper page, and potentially prevents administrators from choosing a tamper instance that would break on certain fields.
3. This UI would keep all of the settings related to Feeds Tamper together, rather than scattering the defaults to the Feed Importer administration interface.

Thoughts? I'm hoping to have a beta of the above changes ready to test within the next few days.

brycesenz’s picture

Version: 6.x-1.0-alpha3 » 6.x-1.x-dev
Status: Active » Needs work
FileSize
4.84 KB

Ok, I added functionality to the Tamper Set creation page which allows the user to choose the fields for which the Tamper Set is available and whether or not the Tamper Set is enabled by default for those fields.

Issues
1. I don't know how to create a patch, so I'm just attached my versions of 'feeds_tamper.module' and 'feeds_tamper_ui.inc'.
2. The new functionality breaks the Rewrite plugin, which also looks to set the fields for which the Tamper Set is available.
3. I have tried to make the "Enabled by Default" checkbox dependent on whether or not the user has made the field itself available, but the code that I am using to try to invoke the ctools dependency is not working. As a result, the UI is a little ugly. Any help would be appreciated.

Incidentally, this also solves issue #962846: Feeds tamper items can only be attached to one feature.

scotjam’s picture

Any intent on including this patch in #5 in Feed Tamper?

cheers
scotjam

twistor’s picture

Status: Needs work » Fixed

The design has changed quite a bit. This is no longer an issue.

http://drupal.org/cvs?commit=481366

scotjam’s picture

I get the following error...

Fatal error: Function name must be a string in ... sites/all/modules/feeds_tamper/feeds_tamper_ui/feeds_tamper_ui.admin.inc on line 111

when i try to add a plugin using the page /admin/build/feeds_tamper/edit/product_feed

Any ideas why?
cheers
scotjam

scotjam’s picture

Update! I installed the 6.x-1.x-dev version and it now works.
No more issues.

cheers
scotjam

Status: Fixed » Closed (fixed)

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