Sometimes when viewing nodes created by FeedAPI there are HTML-encoded characters being displayed as text on the page. For example, see this screenshot:

The titles contains the text " rather than a quotation mark, and & rather than an ampersand.

The problem is that actual ampersand characters are being encoded as &, so we need to translate them back to the true '&' character. To do this, we will use a preprocess function to filter the output of the page before it is rendered. Replace theme with the name of your theme and replace your_content_type with the machine name of the content type you are using for feed items.

function theme_preprocess_page(&$vars, $hook) {
  if ($vars['type'] == 'your_content_type') {
    $vars['title'] = str_replace('&', '&', $vars['title']);
  }
}

This code replaces the string & with an actual & character in the titles of these nodes.

You will need to employ similar code in views that use this content type. Here is an example:

function theme_preprocess_views_view_fields__videos__page(&$vars) {
  $vars['fields']['title']->content = str_replace('&', '&', $vars['fields']['title']->content);
}

Again, replace theme with the name of your theme, and the rest of the function named depends on how you are theming your views. In this case, I am operating on the page display of a view called 'videos'. This will vary depending on your use.

Comments

akahn’s picture

Oh yeah, and I'd like to post this as a child of the FeedAPI handbook page when that becomes possible.

alex_b’s picture

Great contribution. While str_replace is perfectly possible, I'm wondering whether you couldn't use l(title, path, array('html'=> true)); instead?

The fact that HTML encoded characters are showing up is sometimes not avoidable - e. g. when they already come double encoded. But I thought that the most common problems where fixed with _feedapi_process_text() - #377110: Still problems with HTML character encoding

Could you post the feed you're using for the items in your example to #377110 ?

akahn’s picture

You're right, using str_replace() is pretty quick and dirty. I think you even recommended that I use l() with the html => true option, but I forgot about it before writing the code. Probably the actual documentation should use l(), unless there exist some cases where using str_replace() would make sense and then the doc could present both options.

Sure, I'll post the feed in #377110: Still problems with HTML character encoding.

aron novak’s picture

Status: Active » Closed (duplicate)

akahn: let me know if the situation became better with the next daily dev build. I mark this as a duplicate of http://drupal.org/node/377110
If you still having problems, please re-open that ticket.

akahn’s picture

Hey Aron, just to clarify, this was meant as a draft for a handbook page. But if this issue is moot after the next dev build then there won't need to be any docs! I'll let you know when I get a chance to try out a newer version.

Yorgg’s picture

where should this code be? In the theme layer or? I am not exactly sure.

Best Regards,
Jorge.