I discovered this when the readmore link failed to show up red after I upgraded. Nothing except herculean efforts with theme files seems able to fix this.

I discovered the problem. Line 232 from ed_readmore.module has two distinct faults in it:

$link_text = str_replace(' ', ' ', t(filter_xss(variable_get('ed_readmore_text', ED_READMORE_TEXT_DEFAULT))));

Firstly, the replacement of spaces with the nbsp code replaces spaces inside html elements. For example,

<font color="red">

becomes

<font&nbsp;color="red">

which doesn't work. This replacement is wrong and unnecessary. If I want a hard space, I can perfectly well write one myself, but if I don't want one, it wrecks the text in an unfixable manner.

Secondly, the filter_xss is overly defensive. No, we don't want xss attacks, but the text of the readmore element is entered only by the site admin, not by any old Tom Dick or Harry. This filter removes simple and safe things like a font color tag. The site admin should be trusted to decide what tags they want to output on their own site, surely?

After fiddling with themes for hours and getting nowhere, I eventually had to replace this line with the following, just to get the same old functionality back:

$link_text = t(variable_get('ed_readmore_text', ED_READMORE_TEXT_DEFAULT));

Comments

todd nienkerk’s picture

todd nienkerk commented
Title: Too much html being deleted - e.g. cannot set font colour » Too much markup being deleted (e.g. cannot use <font> tag)
Category: bug » support

The <font> tag is deprecated in XHTML 1.0 transitional (and doesn't exist in XHTML 1.0 strict or XHTML 1.1 at all). Changing the color of the font is simply a matter of assigning the color attribute for span.read-more:

span.read-more {
  color: red;
  /* whatever style you want here */
  }

Regarding the insertion of &nbsp;, I believe this was fixed in RC4.

Regarding XSS filtering, Drupal security standards do not distinguish between public and admin-level access to certain configurations. It doesn't matter that, in theory, only site admins have access to Read More link settings. Drupal security standards require that we assume any input could include an attack of some sort and therefore require filtering.

todd nienkerk’s picture

todd nienkerk commented
Assigned: Unassigned » todd nienkerk
Status: Active » Fixed

Removed all replacements of breaking spaces with non-breaking spaces in 6.x-5.0-RC5.

rhouse’s picture

rhouse commented

Hi Todd,

Changing the color: Tried that, didn't work. This is probably sensitive to the exact contents of themes.

Re both issues: I strongly object to the patronising attitude here (which is probably not down to you, as you refer to Drupal security standards). Clearly there IS a big difference between publicly accessible and inaccessible fields. My attitude: this is my site and if I don't care about xhtml standards, that is my lookout. I may have perfectly good reasons for such an attitude, too. (24 hours futzing around with styles and getting nowhere qualifies.) And as for whether I wish to run the risk that I myself deliberately try to launch an xss attack on myself, well, the stupidity of it beggars belief.

Maybe we need to maintain a list of anti-blockheadedness fixes for modules crippled by drupal stupidity?

But thanks, I appreciate that you are not the source of this arrogance.

todd nienkerk’s picture

todd nienkerk commented

6.x-5.0-RC7 now allows the following HTML tags to appear in the link text: em, i, strong, b, cite, code, span, font.

Here's the thread in which the exclusion of the font tag was discussed: #84797: font tag.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.