When anything needed to be encoded as HTML entity is put as a site name it is encoded twice when when displaying.

Steps to replicate:
1. Go to Home › Administer › Site configuration
2. Put following string into Name field: foo & bar
3. Save configuration

Browser will display:
foo & bar
When you look into page source you will see:
foo & bar
inside
element.
Obviously, output string is encoded twice.

The same also happens for Slogan field.

Values in database are put in plain:

testmakbet=# select * from variable where name in ('site_name','site_slogan');
name | value
-------------+------------------
site_name | s:9:"foo & bar";
site_slogan | s:9:"one < two";
(2 rows)

I can see the bug on drupal 6.14 downloaded from drupal.org. It is clean installation without additional themes, modules and languages, configured for default theme. PHP 5.2.6-1+lenny3 from current Debian stable. Webserver: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny3 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g.

BTW, this is quite opposite behavior to #519518: XHTML: how get '&' or '&amp;' entity handled consistently in Drupal node title and in title attribute of node title h2/h3.

Regards
Artur

CommentFileSizeAuthor
#3 bootstrap(d6-14).patch629 byteskurkuma

Comments

BradGriffith’s picture

What theme do you have enabled? Garland?

I am using Nitobe, and a similar thing happens with that theme. I was able to work around the problem by using the $site_name variable without wrapping it with check_plain().

In Garland's page.tpl.php, lines 26-46 are as follows:

          // Prepare header
          $site_fields = array();
          if ($site_name) {
            $site_fields[] = check_plain($site_name);
          }
          if ($site_slogan) {
            $site_fields[] = check_plain($site_slogan);
          }
          $site_title = implode(' ', $site_fields);
          if ($site_fields) {
            $site_fields[0] = '<span>'. $site_fields[0] .'</span>';
          }
          $site_html = implode(' ', $site_fields);

          if ($logo || $site_title) {
            print '<h1><a href="'. check_url($front_page) .'" title="'. $site_title .'">';
            if ($logo) {
              print '<img src="'. check_url($logo) .'" alt="'. $site_title .'" id="logo" />';
            }
            print $site_html .'</a></h1>';
          }

Because $site_name had already been escaped, check_plain was not needed. I don't know how to make a patch file, and I don't know whether this would be treating a symptom when the root cause should be addressed instead, but you can take out the check_plain function in any and all of the places above where it is causing a problem.

I will be interested to hear what thoughts others have, too.

rosk0’s picture

I'm not sure that this is the correct issue to writу to...
my problem is that the site name does not properly escaped (if using " double quote it doesn't escaped)
i using drupal 6.14 end pixture_reloaded 3.2

kurkuma’s picture

StatusFileSize
new629 bytes

I think the problem is within check_plain(), used by drupal_get_title() to dump the page title and populate the $title variable.
check_plain() calls htmlspecialchars() and this one transforms all special characters in sequence. To avoid "double conversions" the function has to be called without the default value for the last parameter double_encode. From the function docs: When double_encode is turned off PHP will not encode existing html entities, the default is to convert everything.
Check the PHP manual (http://php.net/manual/en/function.htmlspecialchars.php).

I have attached a patch for it.

kurkuma’s picture

Status: Active » Needs review
nedjo’s picture

Version: 6.14 » 8.x-dev
Status: Needs review » Needs work

This specific bug looks to result from check_plain() being called twice, so the second call should be removed.

It probably makes sense to use the $double_encode argument, now that it's available. We can't for Drupal 6, since it was added in PHP 5.2.3.

Should use single quotes around the third arg.

sun’s picture

crea’s picture

Status: Closed (duplicate) » Active

That issue is now "closed (won't fix)" so this is probably still relevant.

dawehner’s picture

Issue summary: View changes
Status: Active » Fixed

This is no longer the case with our rewrite of the escaping system.

Status: Fixed » Closed (fixed)

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