The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.CSV would be pretty handy but I'm sure there are other formats that are not xml that would be pretty handy to pull into FeedAPI. Can you say killer app? ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | feedapi_eparser_load_settings.patch | 939 bytes | b-prod |
| #2 | feedapi_eparser.patch | 3.43 KB | b-prod |
Comments
Comment #1
neclimdulI think this is actually possible now! Wow that happened a lot faster than I thought.
Comment #2
b-prod commentedHi!
Here is a patch that allow other modules to add their specific form in the eparser fieldset (in the node edit form), through a new hook: hook_eparser_settings_form. The settings are stored (serialized) in the database, in a new field: settings.
I needed that for a CSV parser I created within eparser, in an other module, to specify the CSV delimiter. If you agree with my patch and is interested with CSV parser, I can also include the CSV parser in epaser core.
Comment #3
neclimdulAwesome! I'd come across a similar sort of need while trying to implement a JSON parser.
2 comments. 1) I'd kinda like the form function to be part of the plugin object similar to the way views does it so things are a little more encapsulated. 2) I'd kind of like to do #560162: Move UI to node tab first so this is a little easier to manage.
Comment #4
andrewlevine commentedWe can do this now...reopen and clarify if there was anything else you wanted done with this.
Comment #5
b-prod commentedHi!
New way to store settings via multistep form is a great idea. But there is an omission in the code: the settings are not loaded when instancing parser.
Correct this is very quick and simple, the patch only modify 1 line and add another one.
Comment #6
neclimdulcommited