Selectable input format for created nodes

When nodes are created, it might be the case that they are done as an anonymous user in the cron process.
I've not checked the code, but remember the hacks to get around this in the older RSS aggregation modules.

That sounds about right, itsthe same for an admin user who might have rights to use a more flexible input filter, but still gets the default 'filterd html' filter when creating a new node because that's the default for all roles.

There is a default role per content type module on d.o -- maybe combining this will help with defaulting the input format for a feed item? Not an ideal solution, and something i feel should be rectified directly in FeedAPI eventually.

Subscribing. Needing a feedapi internal solution. That would be great

I was able to get this behaviour now by first making a admin role, then giving this admin role a default input filter (the superadmin without creating a role for it, is not shown in the input filter page and uses the default filter. So using the default filter per role module and setting the wanted filter to default for the admin role made it ok).
Now the feed items are shown with the correct input filter.
This is on drupal 5.7 with feedapi 1.1.

Greetings,
Martjin

A temporary fix I made on my site: Hardcoding the input format. This will make feedapi use the input you specify for all feeds.

In feedapi/feedapi_node/feedapi_node.module at around line 275 (just before the comments) add:

$node->format = 2;

On my system full html is input format 2, if you look at the source of your admin -> input format page, you can find the number you want. On a fresh install filtered html is 1, full html is 2, and setting this value to 0 will give you the default input format.

The nodes are created with the content type default setting for filters on the body.

#248912: Per feed workflow defaults, raher than just using feed item content-types default workflow should already work for those on D5 for changing the node body filter settings per feed. I don't know how much it would take to move it do the D6 version, and doubt I'll have time for that in the foreseeable.

Yeah, I've been overriding the $node->format in hook_nodeapi() for now on a site i worked on.
Does the job, but not a great solution.

Yeah, I've been overriding the $node->format in hook_nodeapi() for now on a site i worked on.
Does the job, but not a great solution.

@5 I've added this line, and indeed it uses that input format when it creates the node (tags are no longer stripped out), however, the node is still has the default "0" for format, so it ends up displaying as filtered html. Did you make any other changes to get this to work?

May be also the parent feed needs to have the same inputfilter choosen!
greetings,
Martijn

Subscribing.

Here is a patch to FeedAPI.
This adds an input format inheriting functionality. So turn on feedapi inherit to the given content-type and turn on "Feed item nodes will use the same input format as the parent feed node" checkbox.
Then simply set the desired input format at the feed node while creating it.
Please try out this patch and share here the feedback!

#12 won't address all issues. e. g. the following is a very common one:

* You need to create node items with full html allowed.
* You don't want your users to enter full html.
* But your users should be able to create/update feed nodes.

Would an explicit filter setting on the feed content type edit form work?

This patch takes alex_b's suggestions form #13. It creates an explicit filter selection in the feed settings.

I tried the patch in #14 on a site I'm building and imported 100+ items from a feed using "Filtered HTML" (we use Markdown everywhere else but it the feed items featured European style quotes beginning with emdashes that got displayed as unordered lists). Works as expected. Very nice!

changing the title to better represent the current state of the issue.

We've been using this patch on a production site for two weeks now. Would be nice to see it committed for the next release.

thanks patch does the job. this should be RTBC

Exactly what I was looking for and works fine. +1 for committing this

This is committed to DRUPAL-6--1, thank you everybody.

Here's a version of #14 that applies to DRUPAL-5. Do we need a patch for #12 as well, or does the latter supersede the former?

No need for rolling a backport of #12. I need somebody to review #24 on D5 though.