Fixed RSS Feeder formatting issues

aruffell

Member
So trying to set up some RSS feeds and obviously you can have content or description.

So I don't want the whole content so am using this:

Code:
{description}
 
[url="{link}"]Continue reading...[/url]

Upon previewing the feed entry, it shows as:

Another day, another Apple lawsuit, although now they are on the receiving end. Last week Randolph Divisions and Hearpod Inc. filed the paperwork stating that Apple’s “Earpods” is infringing on their “Hearpods” trademark. The company manufactures the Hearpods and they are hearing aids, which was trademarked since February 2005. That was quite awhile ago, therefore [...]

Any ideas on getting it to format correctly?

Thanks.
 
I had to modify the code to support descriptions with HTML entities in them (by decoding them). This will be fixed in 1.1.5.

Otherwise, you can change this in library/XenForo/Model/Feed.php:
Code:
'description' => $entry->getDescription(),
to:
Code:
'description' => html_entity_decode($entry->getDescription(), ENT_COMPAT, 'utf-8'),
 
The point was to differentiate from something that's only fixed in 1.2. 1.2 being a superset of 1.1.x, anything fixed in/for 1.1.5 would be included in 1.2. If I'm fixing something in the 1.1 branch, I can't say it's been fixed for 1.2 regardless of release dates.
 
Need to do a bit of testing, but it was quite straightforward so it's in 1.2.
Yes!
th_snoopyDance.gif

Absolutely! :D Can stuff be sent via the XF mailing address or is there a separate PO box for you? Any preferred flavors you & the Mrs. would prefer (eg: the chocolate cupcakes, the peanut butter KandyKakes, etc.)?




PS: For those wondering why this makes me happy, you'll be able to make use of the enclosure tag for other stuff besides just NASA's pic of the day. Ref: http://en.wikipedia.org/wiki/RSS_enclosure
 
The point was to differentiate from something that's only fixed in 1.2. 1.2 being a superset of 1.1.x, anything fixed in/for 1.1.5 would be included in 1.2. If I'm fixing something in the 1.1 branch, I can't say it's been fixed for 1.2 regardless of release dates.

Interesting :)

The assumption I made was that you have a code base you're working on for the next release. If you're at the stage where you've incorporated extra features then it'd be 1.2, if you're fixing these bugs but you're not at the new feature stage yet it'd be 1.1.5.

Or do you have parallel code sets where you could in one instance be adding new features but bug fixes are done in parallel on a different version of the code? I guess I'm asking is the code that modular that bug fixes don't affect new features and vice-versa?
 
Interesting :)

The assumption I made was that you have a code base you're working on for the next release. If you're at the stage where you've incorporated extra features then it'd be 1.2, if you're fixing these bugs but you're not at the new feature stage yet it'd be 1.1.5.

Or do you have parallel code sets where you could in one instance be adding new features but bug fixes are done in parallel on a different version of the code? I guess I'm asking is the code that modular that bug fixes don't affect new features and vice-versa?
Most development occurs in separate branches (coming from a developers stand point), Basically there is 2 parallel versions of code going. Once a bug is fixed, that change is propagated through every necessary line of development through simple commands in the version control system. Meaning, its easier to fix in older code (1.1 in this case) and send changes forward in versions than just fix in v1.2 and again in v1.1.

Also, it gives customers a more stable release by fixing in v1.1. (y)

I knew already, but I chose not to mention it, you filthy Pens fan you! ;)
So... what place are your Philthy Phillies? 12th now? Lemme check, but I know we are #1! ;)
 
Top Bottom