Jump to:

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 the TITLE attribute 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.

Justification:

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 contaner 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:

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.

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.

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.

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:

When a node is rendered and the title set, always call drupal_set_title() with the flag to allow HTML formatting.

Offer a checkbox on a given node to flag whether or not to allow HTML formatting. I do not like this one.

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.

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.

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 7dvt.com. Works great.

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.

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.

+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?)

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:

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.

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

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.

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.

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.

#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.

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:

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'.

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.

- 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.

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.