At the forefront, I understand that:

  1. This is a deficiency with many CMS systems -- Drupal is not unique
  2. The requested feature if implemented simplistically would break syndication feeds. (I've seen Dave Winer spit gears when people embed markup in newsfeed titles; apparently RSS geeks can get very perturbed about this.)

What I'm looking for is a way to insert markup in an entity's title field and actually have it displayed on the page. I understand that it's possible to hack your themes to make this happen via non-HTML markup code, but this should be a core feature.


Invariably, when producing a site that has any kind of "marketing" purpose, it's important to present page title information that's formatted at the character level, or which includes character entities. For example, I'm currently working on a site to promote a new book. Some pages will have the book's title as the title of the page; other pages will have ordinary titles; other pages will incorporate the book title.

Here's the thing: Book titles must be rendered in italics. No way to do that using Drupal, unless you hack the theme to use non-HTML markup, or unless you suppress display of the Title field and use a header container at the top of the text. Which is tedious, to say the least, and places significant maintenance burdens. (This is another case where Drupal's content management interface is user-hostile to non-technical users.)

Book titles are one example. Here are a few other common sorts of page title presentations on "marketing" sites that you can't do in Drupal:

  • Embedded entitites or typographically-sensitive presentation (e.g., proper right/left quote characters, em dashes, etc.: “Wheetabix®—They're Super-Fantastic!”
  • Special formatting, as with branding treatments: "More Information About LudoTRAC"

BTW, while the examples are fictionalized, both of these are scenarios I encounter on every site that I implement. As noted, there are themable workarounds, but it really shouldn't be necessary to do it that way. For one thing, relying on the theme to do that lifting is user-hostile, as noted -- it reinforces the (very) common perception that Drupal is "only for geeks", and not suited for sites where less-technical users might have to maintain content. For another, if you have to embed pseudo-BBCode markup (or the ilk), you'll be sending out garbage in your newsfeeds. Not good.

HTML tags will need to be removed when rendering the entity title in a tag or in an RSS field, but HTML entities (special characters) should remain.

Comments’s picture

Version: 4.7.3 » x.y.z

new features go into devel version.

coreb’s picture

Version: x.y.z » 6.x-dev

moving from x.y.z to 6.x-dev version queue

moshe weitzman’s picture

subscribe ... i needed to hack check_plain() in order to support this. lets get some help from core instead.

Christefano-oldaccount’s picture

@moshe: any chance we'll see what you did for the observer going into 6.x-dev?

moshe weitzman’s picture

my solution really was an unspeakable hack that is inappropriate for core. we need some buyin that markup belongs in titles, and then some architecture about how to support them. i don't have that answer off the top of my head.

escoles’s picture

Such synchronicity -- the Observer writeup was fantastic, and now this.

I have to confess I don't really deeply understand why there would be no buy-in on the idea that there needs to be markup in Title fields. I've never understood it, even as I know that some people literally find the idea of markup in a title field to be offensive, somehow. My allusion to Dave Winer is a reference to the fact that I remember him once going off for a screenfull of blog about the evils of having HTML markup in the titles of feed items. In that case, I think the real driver was that it illustrated something he hadn't thought of, and so didn't want to admit was important. But here, we have a concrete example of a case (a newspaper) where there's a clear need for certain kinds of markup in titles. As examples go, this should be a no-brainer.

What happens instead is that people hack around it. My solution the last time I had to deal with this was first to hack the theme and add what amounts to BBCode markup. That wasn't going to work, ultimately, so I suppressed display of titles and included the title in the body field.

In other words, I did stuff manually, when the CMS should have been able to take care of it for me.

If the Drupal folks really want Drupal to be successful, they're going to have to figure out how to make it attractive to businesses with marketing-oriented needs. One of those needs is to include markup in article titles. It's something I'm going to have to find a way to work around every time I argue to use Drupal in a customer website.

Christefano-oldaccount’s picture

Hear, hear.

dvessel’s picture

Version: 6.x-dev » 7.x-dev

Me don't see any patches. tagging for 7.x-dev

Crell’s picture

Mark me down as another person in favor of allowing formatting in node titles, although said formatting will need to be stripped for the page header <title> tag. So then the question is how do we do it? #242873 is relevant here, as it provides a mechanism for avoiding the check_plain(), albeit in the wrong place IMO. :-) Once that patch goes in, I see the following alternatives:

  1. When a node is rendered and the title set, always call drupal_set_title() with the flag to allow HTML formatting.
  2. Offer a checkbox on a given node to flag whether or not to allow HTML formatting. I do not like this one.
  3. Run the title through the same filter as the body. Given that the filter system is being revised by Gabor, I'm not sure how feasible this one is until he's done. He may need to weigh in here.
  4. Contrary to the above patch, always call drupal_set_title() with HTML allowed and then filter just in drupal_get_title(). That way the page header can strip tags, the page title can run a filter or whatever, and both can be easily overridden at the theme layer. Because the raw form is stored, the preprocess function does not need to do any wacky de-escaping if someone forgot to specify that HTML is allowed, although the default preprocess function can still default to running everything through check_plain(). This is my preference.


bjaspan’s picture

D7 should be able to solve this quite nicely as a contrib module called, say, Formatted Titles. It can work something like this:

1. Using the Field API, the module adds a new field, Formatted Title, to every node type or node types selected by the administrator. It's a user-formatted text field.
2. The module uses hook_form_alter to remove the Title widget from every node form for which it is enabled; the Field API takes care of adding the Formatted Title widget as it will for every other field.
3. The module uses hook_nodeapi('insert' or 'update') to set $node->title = strip_tags($node->field_formatted_title[0]['value']).
4. The module uses the D6 theme improvements (which I still haven't grokked) to change $vars['title'] to the formatted version for node page views, Views fields, menu items, etc.
5. Sites can use the formatted title in additional locations by overriding the appropriate theme function.

I'm using exactly this approach (with a manually-created Formatted Title field, of course) at Works great.

Ain't Drupal 7 gonna be awesome?

moshe weitzman’s picture

I'm not so sure that will work for things like 'recent forum topics'. those are a set of links where each link goes through l($node->title). at the point of this call, $node->title has had its tags stripped so we are going to get an unformatted title here.

bjaspan’s picture

Well, if 'recent forum topics' were a view, then it would work because Filtered Titles module would override theme_views_field_node_title() (or whatever it is called). If 'recent forum topics' is a custom function, then it would require overriding theme_forum_recent_topics (or whatever). The idea would be that Formatted Titles would automatically use the formatted title in *most* places, would use the safe $node->title everywhere else, and a site developer could incrementally theme the additional special-case locations to use the formatted title as desired.

Here's another way that D7 can solve the problem:

1. Title becomes a normal field instead of a special case.
2. The Title field can be configured to allowed HTML or not.
3. The Title field's display settings control whether it is output as Plain Text or Formatted Text.
4. The theme/engine, which owns the <title> block in the header, is responsible for outputting it with valid contents. Since it can no longer assume Title is plain text, it should run it through strip_tags().

I guess both of these ideas can be summarizes as: We should make title *less* special instead of *more* special. IMHO, Title should really be nothing more than another field on a node.

moshe weitzman’s picture

That second option looks much stronger to me. So if you want to do a node link you would do something like:

  l(field_format($node->title, 'title'), "node/$node->nid));

There is a caveat though: $node->title is no longer a safe field to output directly. I'm good with that.

yang_yi_cn’s picture

maybe we should have a $node->title_formatted and a $node->title for backward compatibility

Robin Monks’s picture

I find formatting in titles to be too complex, and from a user experience standpoint, clumsy.

I personally don't think this is something that should be going in core. If a contrib module can do it, more the better.


jp.stacey’s picture

+1 for this. I think almost every client we have would want at some point to put markup in titles. To me this is a question of frequently requested functionality from the user base rather than personal preference of what feels neatest.

As regards the content of $node->title and what extra fields to put on the node, this depends a lot on the knock-on effects. Crell's point #4 has to be looked at sooner or later, because we can't have drupal_set_title() and drupal_get_title() being no longer conscious of (a) the node going in and (b) the context - h1 tag, title tag or RSS feed - coming out. But that doesn't necessarily scratch the surface of what should appear in e.g. rendered views.

I think for the sanity of the rest of the community, you'd want to be in a situation where anyone could presume $node->title were always in some way "safe": both XSS-safe and also title-tag safe, so no bare tags but broadly speaking stripped-out tags too. That probably means having some sort of filter requirement along with sorting drupal_get_title in the node module. This could be a checkbox for the title, which I don't mind as much as Crell, or the same filter as the body (but what if a node doesn't have a body, but just CCK fields?)

bjaspan’s picture

With Field API now committed, I maintain that my suggestions in #10 or #12 are best. Title should become less special, not more. I am not quite sure yet if Title should be a normal field, though (I'm pretty sure body should).

As for Moshe's objection in #11 that l($node->title, 'node/'.$node->nid) will not show formatted content given the approach in #10, the problem there is with l(). We should not be using it for node links. Instead, we should define:

 * Return a renderable link to a node.
 * @param $node
 *   The node to link to.
 * @param $text
 *   The text to display in the link.  If omitted, uses $node->title [or formatted title, if we add them].
function node_l($node, $text = NULL) {

Incidentally, this would also vastly improve the performance problems with URL aliases to nodes, since a node's primary alias could become part of the node object instead of requiring a text-based join to a separate table.

mdupont’s picture

Subscribing. The problem is still present in 6.x and 5.x (see #167176: ampersand in site title not transformed to HTML leads to invalid html code and #211475: Enable HTML in titles). Even some special characters will bring problems, like an ampersand (which could give "&amp;" in the title), or an image (the <img> tag will be displayed in the title bar). They should be either stripped (formatting tags) or correctly interpreted (special characters). Let's get rid of this longstanding issue.

Ryan Palmer’s picture

I think one false assumption that has been made here is that titles with HTML simply stripped of tags will be appropriate for display in so-called "title safe" areas.


Cable VertMC Surface 2W & 3W (Cable Vert<sup>MC</sup> Surface 2W & 3W)

Roughly speaking, this is the French title for a product with a registered trademark or copyright. In English, a ® (&reg;) would have sufficed and could have been included in title-safe areas, but I'm not aware of a French equivalent and as such require the letters "MC" in superscript. The tag-stripped version of this string simply doesn't work.

Given this, I still feel the issue of allowing HTML in titles is an important one and would add the following:
* maybe the issue I raised isn't a huge concern, and we should charge on and let users deal with the consequences of their stripped titles looking funny in certain places
* maybe only a particular sub-set of tags should be supported
* or we can leave this in the domain of a contributed module

jeffreyd’s picture

I'm following this discussion with great interest.

A related use case is chemical compounds or math equations in the title: eg. H2O (H<sub>2</sub>O). Removing the subscripts on the compound doesn't change the meaning, but does spoil readability and convention. This is not the case with math equations. Removing the sub/superscripts completely changes the meaning (and looks like poor notation): eg. X12 * X22 = X3 (X<sub>1</sub><sup>2</sup> * X<sub>2</sub><sup>2</sup> = X<sub>3</sub>) becomes X22 * X22 = X3.

I agree that the Title field is overloaded with conflicting purposes that are complicating this problem. The Title field should be debased in status to a normal field (+1 bjaspan, comment #17). The various purposes for it should then cleanse it as they need it to be.

The new architecture in D7 is promising, but still too far off for my current problems. The BBCode route is undesirable to me, and would be too complicated for some of my authors. So I'm left with browsing contrib, hacking core (NOT), or modding/theming my way into a corner [sigh].

I'll keep my eyes open for other options. Thankfully, we have this semi-recent discussion going on.

joeebel’s picture

Count me in for HTML formatted titles. My client needs to display the Trademark symbol, ™, in titles. Sure could use that!!

bjaspan’s picture

Titles became a field in D7. I don't know the full details yet, but I wonder if this issue is now moot.

Ryan Palmer’s picture

#24, yes indeed. Also, have we overlooked the Page Title contrib module?

escoles’s picture

page title module isn't relevant to the original scenarios [except insofar as I don't know if it can display char entities].

webchick’s picture

Version: 7.x-dev » 8.x-dev

Too late for features in Drupal 7.

bjaspan’s picture

I just looked at the Title field in the Field UI and see that there is no 'edit' link on which I could turn on formatting. So, I guess even though "title is a field" it is still a very special-case field, so in fact this issue is not moot and I guess it will have to wait for D8.

lduerig’s picture

Well, also just encountered this barrier, my client needed a trademark symbol in the title. I don't know if this qualifies as an evil hack or not, but if anyone else needs a simple symbol like that and doesn't have time (or interest) to investigate if this is a correct solution, I solved this very easily. I just switched on my FCKeditor, used the "insert symbol" button to pick up the ™, switched to source, copy-paste-voila! No core hacking or additional modules necessary.

I'm sure you could get those symbols from many other sources, as well, but that one was just sitting right there on my page.

escoles’s picture

#29 is a workable solution for inserting symbols any situation where the entity will not be converted to ASCII, as long as the default size of elements is acceptable. Should be fine in a Drupal context -- but if you ever have to download the characters by FTP, they could get transformed & broken.

Default R [®] and C [©] are deemed to be too large and not positioned correctly by our designers and creative director, so it wouldn't work for us -- we need more markup for the entity characters.

Also, it still leaves you unable to present other markup, such as italics or boldface. That's the really thorny issue, not the entitities. You need that kind of markup to present approximations of logotype treatments, like "silEPuttee", or something.

The only workaround I've found for the latter is to use a CCK field that's filtered text, and insert conditional logic that uses that field wherever it exists, in preference to the main title field. But this is also a problem for menu entries and that solution doesn't help there, either. (That's a separate issue but it has a related core cause.)

just curious, so testing -- they do come through in the same size as entities, ANSI keyboard-entered characters, and work OK when inserted by keyboard into Word & pasted here:


loominade’s picture


keddy8’s picture


cherryz’s picture


loominade’s picture

There's an easy workaround. You need the following Modules:

Activate the modules. Add a cck field named 'title' to the content type (allow markup, mark the field as 'requered'). Set the 'Automatic title generation' to 'Automatically generate the title and hide the title field' and add the token '[field_title-raw]' as 'Pattern for the title'.

now the node-title became a cck field.

unfortunately this doesn't allow formatting menu entry's

escoles’s picture

loominade, i think that still requires you to configure the CCK field to display as the node title (i.e., code new templates). The Automatic Node Title module isn't required for that -- you can just use CCK. Seems like your solution would probably simplify the forms, but would require a slightly more complex integration.

mattbk’s picture


ohnobinki’s picture


danielhonrade’s picture

#34 works

- after auto_nodetitle installation
- create a field in manage fields in you content type
- Label: Title
- Name: field_title
- Type: Text
- configuration: Text Processing, choose -> Filtered text (user selects input format)
- choose Automatically generate the title and hide the title field
- choose [field_title-formatted] from replacement patterns
- edit page.tpl.php to print the new title source in place of the old one.

<h1 class="title"><?php print $node->field_title[0]['value']; ?></h1> instead of

<h1 class="title"><?php print $title; ?></h1>

- It's now possible to have a title with <h1><span class="something-different">Drupal</span> Development</h1>

BrightBold’s picture


Scott J’s picture

I have started an issue for this at the new Title module.

5keptic’s picture


JayD’s picture

Has anyone been able to get the procedure described in #38 to work? The [field_title-formatted] does not seem to get generated. [field_title-formatted] is not displayed in the "click a token to insert" box. When I enter [field_title-formatted] manually into the "pattern for the title" box, "[field_title-formatted]" is displayed as output in the title field indicating that the token did not get generated.

drupal_was_my_past’s picture

Status: Active » Closed (duplicate)
jhedstrom’s picture

Category: Feature request » Task
Issue tags: +Needs issue summary update

This was not a duplicate of #1188394: Make title behave as a configurable, translatable field (again). See

Re-classifying to a task (it is possibly a bug), since there are perfectly valid use-cases for HTML tags in titles (think 'code', 'sup', 'sub').

jhedstrom’s picture

Status: Closed (duplicate) » Active
jhedstrom’s picture

Component: base system » field system
Priority: Normal » Major
ianthomas_uk’s picture

Issue summary: View changes

Clarify that issue summary is talking about entity titles, rather than the tag or attribute.

ianthomas_uk’s picture

Possibly a duplicate, certainly related

alexpott’s picture

This is a complex issue - see #2555931-4: Add #plain_text to escape text in render arrays and #2555931-7: Add #plain_text to escape text in render arrays. It's not possible to satisfy all use-cases simply. And what's more for the same entity in HEAD different rules apply - vocabularies are handled different from forums (which are vocabularies!).

effulgentsia’s picture

Version: 8.0.x-dev » 8.1.x-dev
Category: Task » Feature request
Priority: Major » Normal

Embedded entitites or typographically-sensitive presentation (e.g., proper right/left quote characters, em dashes, etc.: “Wheetabix®—They're Super-Fantastic!”

This can be done via Unicode. In fact, I just now tested copying and pasting that exact string into the title field of the node edit form and it worked.

Special formatting, as with branding treatments: "More Information About LudoTRAC"

This certainly does have a use case. is a module that allows it. That module has ~4K sites using it, which doesn't seem like quite enough to me to support the idea that this is such a common need that it's worth moving from contrib to core, but moving to 8.1, in case someone can come up with a good solution that's backwards compatible.

In my opinion, $entity->label() should always return plain-text (Unicode characters are ok though), so that non-HTML consumers have a reliable way of displaying entity labels for whatever format they choose. But, a patch that distinguishes "the entity label" from "the label/title to display in HTML contexts" could potentially solve for all needed use cases.

alexpott’s picture

@effulgentsia the problem is things like making scientific words correct... eg. Tyrannosaurus Rex and no that should not be em tags :)

jhedstrom’s picture

Or E=MC2 is very different than E=MC2 :)

effulgentsia’s picture

#52 can be achieved with Unicode: E=MC²

I agree that #51 is a use case, but I don't think that use case existing contradicts #50.

jhedstrom’s picture

Thanks @effulgentsia, I'd forgotten that was possible!

BrightBold’s picture

I'm glad to know that copy-paste will handle much of what's needed here through Unicode. As an aside, though, I don't think the install base of HTML Title is a good measure of desire for this functionality; it's missing a Views handler so it can only be used on sites where you never need to put a node title in a view. That's pretty limiting.

mohit_aghera’s picture

I am working on Html title module's Drupal 8 port.
You can find related contrib port tracker issue here

mohit_aghera’s picture

Basic functionality is done as per above comment.
Feel free to try from git repo

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.