Description field does not like double quotes & more...(FIXED)
 

When uploading/editing the description field does not like:

"
&
<
>

Those would be considered html characters in a way

In admin options set this to YES

Allow HTML in Product Fields?

LOL. No way.

Why don't you just escape them as you do in the other fields like the title??

Look.... there are valid reasons for using some of those characters without having to enable HTML, obviously you guys know the potential consequences of allowing HTML, you suggest against it on the option itself.


What if something has a measurement as part of its specification in the description? ie 8"x9"


Please fix this the proper way as you did for the classifieds.

Yes and No.

Look at our function it escapes those specific function and converts them but in doing so you are allowing HTML RIGHT.

If you allow the conversion of < > & and " then all html links display hense the function and you see the strip tags where we dont allow any bad things. but I still warn people.

I can tell you to edit the code and add un_htmlspecialchars to that line to convert those characters but thats what the switch I told you to set to YES does

see this code in showproduct.php

The option says:

"Allow HTML in Product Fields?
Please note it is a security issue to allow html in product fields but if you do want to take the risk set to YES!"

We're going to be allowing untrusted (but registered) users to "upload products"

So you're saying that it's no longer a (real) security issue to enable HTML in product descriptions?

If not, then what happens if someone types 11" x 17" in the review comments below? Do I have to enable html there as well?

I understand what you are trying to do, but when you OUTPUT your sanitized it is actually DISPLAYING instead of " -- with HTML off.



Why is it safe in Vbulletin with HTML OFF to type:

`~!@#$%^&*()_+-={}|[]\:"';/.<>

But not in these products in all untrusted user submitted fields?

With HTML off, for the title I can type " and it displays " as it should.
With HTML off, for the title if I type <B>BOLD</B> , it does not execute the HTML, as it shouldn't.

So why can't you use the same routine used for the title for the rest of the user submitted areas?

I am just saying the character's you have all specified allow html to be entered.

You posted these < > so I gave you the proper answer to enable html if you want to display those

Now if you want to turn html off and just want to worry about & and " try this

... err sec I'll test this

I have read on say this on the forums about some switch in the admin screen however in my admin screen I don't show this option or at least have never seen it:confused: .

well are you running the latest ;)

I am running 3.11 that I intalled on 10/19. Was something added to the later build with this? I didn't see anything in the announcements.

From your description it should be in the Edit Settings under All Options correct?

I don't see it and haven't seen this on any reviewpost release.

This was added in Reviewpost 3.0

They are added right in the 2.9-3.0 upgrade process and should be under showproduct options specifically

Chuck,

Do you have ALLOW-HTML enabled in descriptions and reviews on Reeftalk.com?

Much apologies Jeremy for butting into your thread. Sorry :(


Just to follow up Chuck, nope I have never had those fields installed. I have hand installed them though through phpmyadmin. I started reviewpost with the 3.1 release I think. I have looked into a few of the install and upgrade scripts and for fields 237 and 238 I could only find REPLACE INTO query for both of them. I haven't checked all of the upgrades scripts but the ones I did check none had a INSERT INTO query for those field numbers. If you have a chance check on a fresh install if those fields are getting inserted.

Could have just been a mix up somewhere along the line though.

Mike

...again sorry Jeremy but I also have the same problems with the quotes and stuff and am unsure why this happens in reviewpost and not photopost.

They are indeed in the upgrade script mike

Jeremy no I do not have allow html on

Then why should the users of photopost have to in order to have double quotes display as " rather than &quot; etc?

If I go to reeftalk & leave a comment, with a " in there, is it going to display the actual " or the (bug) &quot; ?

There's no reason to appologize.

You are having the same problem because it is a bug in the current distribution.


You know.... I think I know the problem.

::me digs through code::


Ok Chuck....here's the problem:

in Classifieds when I _view source_ of a page containing a double quote, in the source it displays as &quot;.

in Reviews when I do the same, it displays &amp;quot;

This is why it is SHOWING &quot; instead of showing "

&amp;quot; != &quot;

So there is probably a typo somwhere OR maybe the would-be cleanly converted " to &quot; is getting substituted AGAIN somewhere where it shouldn't be which is creating the &amp;quot; since & is another one of those chars that is getting sanitized.


See the problem now?

Got a fix for everyone? :)

Also please see the other related thread - when "allow html" is disabled then the carriage returns are stripped from desc (making one big line).


OTher than that, the whole to BBcode or not to BBcode is something you guys should definitely consider addressing as an additional enable/disable option in the future.

Chuck are you going to be able to look into this today?

We would like to get this finished and be able to launch our site ASAP.

All this bug fixing is really setting us back time wise here.

Jeremy here is the difference though and it essentially does the same thing I stated by turning on html

Basically convert_markups is messing with this

IN showproduct.php

this is what classifieds has

So you can make the change if you wish

Are titles,keywords, etc included in $desc? Or is that just for the description portion?


Did you see what I said about it possibly getting ran through twice?

Do you understand what I'm saying is happening?

There is a bug. Turning on HTML is not the fix.

That is the problem.


&amp;quot; will DISPLAY &quot; (the problem)

&quot; will DISPLAY " (the expected result)