Date: 2009-08-01 18:12
Posted By: blast blast (blast)

This is still an issue in 1.6.3 and no one tell us if it's a bug or a "new
feature"...
      

Date: 2009-08-06 05:52
Posted By: Steve Merrony (SteveHM)

Also prevents use of IMG in links.
      

Date: 2009-08-19 16:32
Posted By: Robert Campbell (calguy1000)

The text parameter is for text.
if you want to do anything else, use the href parameter, and write your own
html.
      

Date: 2009-08-20 04:02
Posted By: Bob Sideshow (sideshowbob)

Sorry Calguy but I disagree. Surely one of the main ideas behind CMSMS is to
make it simple for regular, non technical users. "Write your own HTML" isn't a
useful solution.

The WYSIWYG editor clearly allows users to create a selflink and apply some kind
of style (e.g. <em> tag), this is a perfectly reasonable and common thing that a
user does.

Either remove the selflink feature or make it function in a way that it doesn't
deliver unexpected results to the user.

I am not the only person who is affected by this issue, it seems likely that
many existing sites could be adversely affected by this change when they
upgrade.

Obviously security is important and you dev guys have the final say on this one
but please consider the user's point of view as well. Perhaps a compromise could
be found, a config option maybe?

kind regards,
Bob
      

Date: 2009-09-09 17:22
Posted By: blast blast (blast)

I can't understand this choose... What are the benefits of html escaping text?
This "new feature" has negative impacts on all installed sites.
      

Date: 2009-10-12 15:28
Posted By: Mark Steer (markSt)

I'd like to add my voice to this.  I upgraded a site today that relies on being
able to enter html tags in the text= field of the cms_selflink tag.

The users of this site CANNOT be expected to write the code necessary to work
around this problem.

I just don't see the issue with allowing tags in the text field.  Please revert
the behaviour to the older way.  I don't want to have to patch the code to get
perfectly reasonable functionality back.

Thanks for listening.
      

Date: 2010-01-28 15:06
Posted By: Scott Zetlan (szetlan)

This seems to me to be a problem with the cms_htmlentities() function,
(lib/misc.functions.php), which for some reason doesn't call the PHP built-in
htmlentities, but instead calls "my_htmlentities" which doesn't do the right
thing.

In my_htmlentities, there should be a check to prevent double-encoding of
entities.  Without that check, text like AT&T gets converted to
AT&T.

But a call to the built-in could pass the last parameter as False, preventing
the double-encoding problem.

And let me just take a little time-out here to berate the PHP core developers
for having this last parameter default to True, instead of False.  WTF, guys?

My suggested solution: alter lib/misc.functions.php, and do the following:
1. comment out line 257
2. uncomment line 256, and add "False" as the last parameter in the function
call
3. Profit!

HTH,

Scott
      

Date: 2010-01-28 15:23
Posted By: Scott Zetlan (szetlan)

Okay, it appears that in a number of places where cms_htmlentities is called,
the second parameter is passed as an empty string when what you mean to pass is
NULL instead.  So that breaks on the admin screens, such as listcontent.php.

So here's my latest attempt at cms_htmlentities:

function cms_htmlentities($string, $param=ENT_QUOTES, $charset="UTF-8",
$convert_single_quotes = false)
{
    $result = "";
    if(is_string($param) && $param == '') { $param = NULL; }
    else { $param = intval($param) }
    $result = htmlentities($string, $param, $charset, False);
    #$result = my_htmlentities($string, $convert_single_quotes);
    return $result;
}

      

Date: 2011-01-07 13:57
Posted By: Ronny Krijt (ronnyk)

Fixed in 1.9.