Thread

hi, lisa,

see my above answer (i did the test and it was still a problem).

i am using 1.6.0 20070627.

the problem existed long before; i just decided today to fix it once and for all

Alright.  Can you update to the latest build, and I’ll look into this? Thank you.

hi, lisa,

there is a lot of custom hack i put into the EE, so update it to the next build is not something i want to do until i am certain this is the problem.

the issue existed long before 20070627. i am actually aware of this since 1.5.2, but just never realize it wasn’t supposed to be this way.

What kind of hacks do you have, P.J.?

please see PM to you.

the hacks have nothing to do with the feeds. they are related to how images are resized, using the URL fields to store other data, how to deal with blacklisting, and so on.

I just tested this on my site, using the default RSS template.  I got the ampersand encoded, once, as it should be done.

Unfortunately, hacks can have many unforeseen consequences, so supporting a hacked installation really is not something we are able to do, which is why we recommend using plugins, extensions, and modules, to change default behavior.  I am, however, on a later build than you Build:  20070726 so again, I would reiterate to try updating to the latest build and using the default RSS template to get things working.

thanks, lisa, i will do the later build at the next opportunity.

until that is done, is there any harm/danger of NOT using xml_encode tag for the TITLE? under what situation may this create a problem? if i know of the potential situations, i can avoid them until this issue is fixed.

I believe that the only real problem is that the feed won’t validate. This may not be a big issue for you. =)  It’s mostly in dealing with special characters like ampersands.

hmm… this is interesting…

i used the w3 validator to validate the feed with and without the xml_encode, and both validate, so apparently having double ampersands sign (which happens to me with using xml_encode) has not created much of a problem, at least in my case.

P.J. just as a note, to avoid this while using the plugin, just use &, don’t enter &a;m p ; - this lets the plugin do the work and you just enter the text you actually want. =)

thanks for the tips.

this is indeed odd. i am always entering & instead of using the “& a m p ;” in the title. and without the xml_encode tag, it comes out normal.

i checked the actual data stored in mySQL database. it is stored as & instead of “& amp ;” the database is utf-8 encoded.

a long time i did a massive change changing my entire datase from the default ISO encoding used by early versions of EE to utf-8 encoding. i did use with phpmyadmin in mySQL. is it possible that this change is causing the discrepant behavior?

Hi, P.J. I’m looking into this a bit further right now.  Thank you for the detailed information.

Hi, P.J. - the plugin has been updated to cover this scenario.  You can find it here.

You’ll want to use the parameter:

protect_entities="yes"

as described in the plugin’s documentation.

wow, that is amazing! you did a whole plug-in mod.

not to sound ungrateful (because i am very grateful), but does this mod fix my problem? this is because when in my data entry for title, i use “&” and not “& a m p ;” and this is how it is also stored in mySQL data tables. So, at least in my case, i never have “& a m p ;” to convert to a double “& a m p ;”. Somehow, my system is doubling the translation (i.e., converting it twice)? Could that be the trouble?

{title} always gets parsed with Light XHTML Typography when output by a Weblog entries tag, P.J., so & gets converted to & there.