aggregator: make filtered HMTL tags configurable

+1

I know it works because it's identical to what I did.

This has come up before: http://drupal.org/node/14104. Could you possibly use input filters instead of a setting for this?

sorry. -1.
IMHO aggregator should be small, clean and lean. No options, features or whatevers. (node aggregator does this for free, and much more. If you want advanced aggregation, then please add your development to this module, or to another -new- advanced aggregation module)

-1 for this approach and a big +1 for running aggregators through filters that can be configured.

I have to add that I would rather have this patch than nothing, since as Uwe correctly points out, the behavior is hardcoded and not suitable for many common cases.

can we not use the default filter system here?

Yes, the filter system could be used, but if you really want lean and mean this really minor patch gives you much of the functionality of one of the filters that ships in core without a lot of UI development. It will NEVER make the 4.7 code freeze.

I suggest applying this patch for 4.7 and working on using the filter system in the aggregator later.

-1. Filters.

Clarification: Adapting the aggregator to use the filter system is a big enough job that doing so in time for the code freeze is unlikely. Seriously, how important is is? It HAS been raised before...

Meanwhile you get a significant improvement for two lines of code. There is literally no down side to applying this patch that I can see...I really don't understand why it would NOT be applied.

"In time for the code freeze" is the wrong justification. Forcing a patch through just so it can beat the code freeze allows quick and dirty code, as opposed to the right code. Encouraging quick patches allows the least tested and least designed code to get in during the point when the code should be most stable and eyeballed. I'd much rather the right code than a bunch of quick patches that do things half-assed (in design, not quality - your patch is just fine for what it attempts to do, just not the best way to do it).

Is there dirty code in the patch? Isn't that kind of theoretical?

You don't apply the patch, no gain, no loss. You apply the patch, one gain, no loss.

That's my opinion. I'm done.

Well, I'm happy to agree with everyone here. Let's apply the patch the Uwe has provided, as he can then turn around and do planet drupal, and we don't forget that the right way to do this is with filters.

Committed to HEAD. IMO, this doesn't have to integrate with the filter system. It could, but it doesn't sound like a requirement to me.