When using apostrophe in a taxonomy it is displayed as &amp#039; in the html-tittle of the page

The problem could be fixed by disabling the module "Metatag: Views" or updating the metatag.inc accordingly:
replacing the check_plain() by filter_xss()

class DrupalTitleMetaTag extends DrupalTextMetaTag {

  public function getElement(array $options = array()) {
    $element = array();
	$value = filter_xss($this->getValue($options));
    $element['#attached']['metatag_set_preprocess_variable'][] = array('html', 'head_title', $value);
    $element['#attached']['metatag_set_preprocess_variable'][] = array('html', 'head_array', array('title' => $value));
    return $element;
  }
}
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

gvancout’s picture

Issue summary: View changes
gvancout’s picture

Component: Integration with other module » Code
DamienMcKenna’s picture

Status: Needs work » Active
haysuess’s picture

This fixed the tag for me, but not in og:title, og:description, or the meta description.

Any word on that?

DamienMcKenna’s picture

Version: 7.x-1.0-beta9 » 7.x-1.x-dev

All occurrences of check_plain() in metatag.inc would have to be replaced with filter_xss().

haysuess’s picture

I replaced the 2 occurrences of check_plain with filter_xss, cleared my caches, and viewed my source code and there are still & # 0 3 9 ; in place of apostrophes in og:title, meta description, and og:description.

Any ideas?

DamienMcKenna’s picture

Status: Active » Closed (works as designed)

This is honestly ok - ' is a HTML entity which should be interpreted correctly by any OG processor, e.g. Facebook, LinkedIn, etc. Remember that HTML code is meant for computers to read, not people ;-)

pedrorocha’s picture

This is really not ok for visitors who see "&#039" in the browser tab title. If the main browser(Google Chrome) in the market doesn't recognize this approach, should it be revisited, right?

pedrorocha’s picture

I fixed by applying the following on html.tpl.php

<title><?php print html_entity_decode($head_title); ?></title>
DamienMcKenna’s picture

Category: Bug report » Support request
Status: Closed (works as designed) » Active

I wasn't able to reproduce this with the current -dev release. I added an ampersand to a node's title, and using the [node:title] token it is output as an ampersand for the title and as the HTML entity in other meta tag values.

What tokens are you using? Is there a difference between the HTML shown for the title tag versus e.g. og:title, which should be using the same token?

rudiedirkx’s picture

I have the opposite problem. head_title isn't html encoded, so it says

<title>Graydon & NL</title>

which is wrong, because & should be encoded to &amp;, like Drupal core does correctly.

It definitely should not strip tags or filter XSS, because "My <strong> page title" is a perfectly valid title and the < and > belong there. Drupal apparently does it too, strip_tags(), so we'll assume that's correct.

I think values should always be html encoded and that's it. Not stripped or filtered. Reality is probably more complex.

(Was wrong in 1.4 and still wrong in 1.5+dev a59eb98.)

rudiedirkx’s picture

Category: Support request » Bug report

Definitely a bug somewhere. Too little encoding in my case.

rudiedirkx’s picture

I can fix it like this, but that shouldn't be necessary:

/**
 * Implements hook_metatag_metatags_view_alter().
 */
function graydonmod_metatag_metatags_view_alter(&$output, $instance, $options) {
  if (isset($output['title']['#attached']['metatag_set_preprocess_variable'])) {
    foreach ($output['title']['#attached']['metatag_set_preprocess_variable'] as $index => &$meta) {
      if ($meta[0] == 'html' && $meta[1] == 'head_title') {
        $meta[2] = check_plain($meta[2]);
      }
      elseif ($meta[0] == 'html' && $meta[1] == 'head_array') {
        $meta[2] = array_map('check_plain', $meta[2]);
      }

      unset($meta);
    }
  }
}

I don't understand how someone could have double encoded values, when I have 0 encoded values...

DamienMcKenna’s picture

I was able to track this down - the problem isn't strings coming through from the {metatag} table, it's values being passed through from tokens. And, of course, the tests weren't covering that scenario. This should fix the problem.

  • DamienMcKenna committed 929b46f on 7.x-1.x
    Issue #2180031 by DamienMcKenna: Fixed double-encoding of tokens.
    
DamienMcKenna’s picture

Status: Needs review » Fixed

Committed!

Status: Fixed » Closed (fixed)

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