#24 — Altering a feed clears the HTML formating. Feedfeeder ignores Kupu preferences.

State	Confirmed
Version:	1.0
Area	Process
Issue type	Bug
Severity	Medium
Submitted by	B cacheira
Submitted on	Sep 21, 2009
Responsible	Maurits van Rees
Target release:	1.0

Return to tracker

Last modified on Oct 07, 2009 by Maurits van Rees

When receiving an Atom feed with html content, Feedfeeder parses it correctly and imports it to plone, formating included.

However, if you alter any entry, like in my case, if you attribute it to a category, it'll lose all the html formating tags. The default mode for the entry field is standard text, meaning it does not use Kupu to edit the field.

There's a workaround though. If, before you save, you switch to the WYSIWYG editor of your choice (Kupu, in my case), do nothing else to the text (you can change the categories, of course) and save, the formating isn't altered.

Steps to reproduce:: Import a feed with html entry (a couple of <br> tags make this quite evident)
Edit entry
Attribute/create a new category for that entry
Save
Entry should display as a non-wrapped word block.

Added byMaurits van ReesonSep 21, 2009 07:40 PM

Hello,

This actually works fine for me. Also, when I click to edit an item, I get kupu.

Which Plone version is this? And which exact feedfeeder version?

Can you give an example of a feed where it goes wrong? I tried the feed of my own blog and that went fine:
http://maurits.vanrees.org/weblog/topics/plone/@@atom.xml

Added byB cacheiraonSep 22, 2009 03:44 PM

Plone version : 3.3

FeedFeeder: 1.0rc5

(btw, can I ask which versions you're using please?)

Feed: http://www.mynetpress.com/xml/ers/intranet_atom.asp

After feedfeeder imports the entry, it's displayed with the correct formating. If you try to edit an entry, it starts in plain text mode, not Kupu (user preferences are to use Kupu) and if the editor is not changed and you save the entry, the format (and all html tags) disappear.

Will try to post screenshots of it later.

EDIT: Grammar, versions (3.2.3 to 3.3, my mistake)

Added byMaurits van ReesonOct 05, 2009 11:34 PM

Issue state: Unconfirmed → Confirmed

Responsible manager: (UNASSIGNED) → maurits

Target release: None → 1.0

I get the same problem with that feed. I am using Plone 3.1.7 (but 3.3 should be fine too) and the subversion trunk of feedfeeder; since the 1.0rc5 version that you use there has only been an unrelated bug fix release 1.0rc6.

I did a fix for this issue in subversion in r99031. Feedfeeder now sees that that the content type of the text is html and saves that information so when you edit the item kupu appears.

This does not completely help for this feed, but that is a problem with the feed itself. It claims that the content is html, but this is not really the case; at least I see no html tags in the entries. It is just plain text with line breaks; since line breaks are ignored in html, no formatting is left.

Hm, so actually, the change I did may be bad for this feed, as previously you could at least edit the entry, choose to load kupu and preserve the formatting. With the new code you just lose the probably intended formatting completely.

That makes me inclined to revert my change.

Thoughts?

Added byB cacheiraonOct 07, 2009 04:55 PM

Thanks.

Honestly, I think that change is a step in the right direction and even though my problem stands, in the global scope, it seems to make sense. I'll take it up with the feed publishers and see if I can get them to address this issue.

Also, and I'm sorry to be using the tracker for this, but I've sent a patch for a small bug on one of the templates and a couple of translations... did you get those?

Thanks

Added byMaurits van ReesonOct 07, 2009 08:56 PM

No, I did not get those. Feel free to add them to this or a new issue. Or commit them directly on trunk if you have commit rights in the Plone collective.

No responses can be added.