HTML Markup in *title* and /abstract/

You can use HTML markup in the abstract right now, but I see there is a little bug/issue in that you have to turn on HTML markup on the "Full Text" field for it to work. I'll fix that.

As the the title markup, you can also include the 'a', 'b', 'i', 'u', 'sub', 'sup', 'span' elements in the title field and it will display correctly in biblio generated listings, BUT as you have found, Drupal generated title listings will show the markup characters. You might be able to fix/work around this at the theme level by not printing out the Drupal generated title in certain areas (e.g. node.tpl.php).

Cheers,

Ron.

I just pushed some changes to the 6.x-2.x branch which allow unique "format" settings for each textarea on the input form.

This required an extra column in the database to store the format settings, so running update.php after installing the new code is mandatory.

Ron.

http://drupalcode.org/project/biblio.git/commit/881d4a1

Hi John,

It seems that the title is handled by the page.tpl.php file in most cases, which is why your node-biblio.tpl.php didn't have any effect.

It also seems that the title is sanitized in the template_preprocess_page(&$variables) function, so in order to achieve what you desire (at least in terms of title formatting :-), you would have to stick the following function at the end of the biblio.module file...

function biblio_preprocess_page(&$variables) {
  if (isset($variables['node']) && $variables['node']->type == 'biblio') {
    $node = $variables['node'];
    $variables['title'] = filter_xss($node->title, biblio_get_allowed_tags());
  }
 }

This will re-filter the title with a less strict filter, leaving 'a', 'b', 'i', 'u', 'sub', 'sup', 'span' html tags.

In answer to question 2... The format selection is done just below the abstract textarea on the input form itself, so it can/must be set for each node when you create it.

Cheers,

Ron.

If it does what you want, I'll include it the module. There's no great risk because the title is being rendered on the same page in the exact same format anyway, and it has been filtered for XSS attacks.

In "theory" OAI-PMH should be able to deal with it since it encodes (escapes) prior to sending and decodes upon receipt.

Hmm, you can't win them all :-) Unfortunately, the title will be handled in the default fashion anywhere it's not processed through the template_preprocess_page function (such as when that email is created).

This leads back to a debate that was had some time ago re the merits of filtering before saving to the db or after retrieving from the db. In my opinion, threat filters should be run before saving the data, but Drupal will actually save data that contains an XSS attack vector in the database, then (hopefully) filter it out every time that content is loaded.

This version is no longer maintained. If this issue is still relevant to the Drupal 7 version, please re-open and provide details.