At the forefront, I understand that:
- This is a deficiency with many CMS systems -- Drupal is not unique
- 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.
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 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.
Comment | File | Size | Author |
---|---|---|---|
#80 | 2023-01-04_110843_screenshot.png | 30.33 KB | tgoeg |
Comments
Comment #1
killes@www.drop.org CreditAttribution: killes@www.drop.org commentednew features go into devel version.
Comment #2
coreb CreditAttribution: coreb commentedmoving from x.y.z to 6.x-dev version queue
Comment #3
moshe weitzman CreditAttribution: moshe weitzman commentedsubscribe ... i needed to hack check_plain() in order to support this. lets get some help from core instead.
Comment #4
Christefano-oldaccount CreditAttribution: Christefano-oldaccount commented@moshe: any chance we'll see what you did for the observer going into 6.x-dev?
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commentedmy 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.
Comment #6
escoles CreditAttribution: escoles commentedSuch 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.
Comment #7
Christefano-oldaccount CreditAttribution: Christefano-oldaccount commentedHear, hear.
Comment #8
dvessel CreditAttribution: dvessel commentedMe don't see any patches. tagging for 7.x-dev
Comment #9
Crell CreditAttribution: Crell commentedMark 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:Thoughts?
Comment #10
bjaspan CreditAttribution: bjaspan commentedD7 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.
Ain't Drupal 7 gonna be awesome?
Comment #11
moshe weitzman CreditAttribution: moshe weitzman commentedI'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.
Comment #12
bjaspan CreditAttribution: bjaspan commentedWell, 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.
Comment #13
moshe weitzman CreditAttribution: moshe weitzman commentedThat second option looks much stronger to me. So if you want to do a node link you would do something like:
There is a caveat though: $node->title is no longer a safe field to output directly. I'm good with that.
Comment #14
yang_yi_cn CreditAttribution: yang_yi_cn commentedmaybe we should have a $node->title_formatted and a $node->title for backward compatibility
Comment #15
Robin Monks CreditAttribution: Robin Monks commentedI 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.
Robin
Comment #16
jp.stacey CreditAttribution: jp.stacey commented+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 havedrupal_set_title()
anddrupal_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?)Comment #17
bjaspan CreditAttribution: bjaspan commentedWith 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.
Comment #18
mdupontSubscribing. 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 "&" 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.
Comment #19
Ryan Palmer CreditAttribution: Ryan Palmer commentedI 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.
Example:
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 ® (
®
) 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
Comment #22
jeffreyd CreditAttribution: jeffreyd commentedI'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.
Comment #23
joeebel CreditAttribution: joeebel commentedCount me in for HTML formatted titles. My client needs to display the Trademark symbol, ™, in titles. Sure could use that!!
Comment #24
bjaspan CreditAttribution: bjaspan commentedTitles became a field in D7. I don't know the full details yet, but I wonder if this issue is now moot.
Comment #25
Ryan Palmer CreditAttribution: Ryan Palmer commented#24, yes indeed. Also, have we overlooked the Page Title contrib module?
http://drupal.org/project/page_title
Comment #26
escoles CreditAttribution: escoles commentedpage title module isn't relevant to the original scenarios [except insofar as I don't know if it can display char entities].
Comment #27
webchickToo late for features in Drupal 7.
Comment #28
bjaspan CreditAttribution: bjaspan commentedI 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.
Comment #29
lduerig CreditAttribution: lduerig commentedWell, 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.
Comment #30
escoles CreditAttribution: escoles commented#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:
ANSI/entity/Word
™/™/™
©/©/©
®/®/®
Comment #31
loominade CreditAttribution: loominade commentedsubscribing
Comment #32
keddy8 CreditAttribution: keddy8 commentedsubscribing
Comment #33
cherryz CreditAttribution: cherryz commentedsubscribing
Comment #34
loominade CreditAttribution: loominade commentedThere'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
Comment #35
escoles CreditAttribution: escoles commentedloominade, 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.
Comment #36
mattbk CreditAttribution: mattbk commentedsubscribing
Comment #37
ohnobinki CreditAttribution: ohnobinki commented+
Comment #38
danielhonrade CreditAttribution: danielhonrade commented#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>
Comment #39
BrightBoldsubscribing.
Comment #40
Scott J CreditAttribution: Scott J commentedI have started an issue for this at the new Title module.
Comment #41
5keptic CreditAttribution: 5keptic commentedsubscribed
Comment #42
JayD CreditAttribution: JayD commentedHas 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.
Comment #43
drupal_was_my_past CreditAttribution: drupal_was_my_past commentedMarking this as a duplicate of #1188394: Make title behave as a configurable, translatable field (again).
Comment #44
jhedstromThis was not a duplicate of #1188394: Make title behave as a configurable, translatable field (again). See https://www.drupal.org/node/1188394#comment-10045432.
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').
Comment #45
jhedstromComment #46
jhedstromComment #47
ianthomas_ukClarify that issue summary is talking about entity titles, rather than the tag or attribute.
Comment #48
ianthomas_ukPossibly a duplicate, certainly related
Comment #49
alexpottThis 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!).
Comment #50
effulgentsia CreditAttribution: effulgentsia at Acquia commentedThis 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.
This certainly does have a use case. https://www.drupal.org/project/html_title 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.
Comment #51
alexpott@effulgentsia the problem is things like making scientific words correct... eg. Tyrannosaurus Rex and no that should not be em tags :)
Comment #52
jhedstromOr E=MC2 is very different than E=MC2 :)
Comment #53
effulgentsia CreditAttribution: effulgentsia at Acquia commented#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.
Comment #54
jhedstromThanks @effulgentsia, I'd forgotten that was possible!
Comment #55
BrightBoldI'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.
Comment #56
mohit_aghera CreditAttribution: mohit_aghera as a volunteer and at Axelerant commentedUpdate:
I am working on Html title module's Drupal 8 port.
You can find related contrib port tracker issue here https://www.drupal.org/node/2616878
Comment #57
mohit_aghera CreditAttribution: mohit_aghera as a volunteer and at Axelerant commentedBasic functionality is done as per above comment.
Feel free to try from git repo https://github.com/mohit-rocks/html_title
Comment #64
DakwamineCan we get a status on this issue? Nothing happened in the last 3 years?
Comment #66
joseph.olstada 12 year old issue needing attention.
Our team is having to cook up a custom solution for this. Seems like something so elementary.
Unfortunately our clients know nothing about how to use unicode and they already have thousands of titles with superscript and subscript (superscript and subscript) tags.
<sup>superscript</sup> <sub>subscript<sub>
Why do we have to go through such lengths to solve something that should be included in core out of the box?
Comment #67
astringer CreditAttribution: astringer as a volunteer commentedWe are in the same boat as @joseph.oldstad and I couldn't agree more. Can we at least get a status update on this?
Comment #68
Anuradha Suryawanshi CreditAttribution: Anuradha Suryawanshi commentedWe can try to render html tag while page render. Please try below code:
function module_name_preprocess_page(&$variables) {
$variables['title'] = decode_entities(drupal_set_title());
}
Comment #69
swirtEchoing that this is badly needed and is actually a bit of a semantic and accessibility issue
A title like
<h1>BJS: Indigent Defense Systems</h1>
Should really be
<h1><abbr title="Bureau of Justice Statistics">BJS</abbr>: Indigent Defense Systems</h1>
Comment #70
gchalker@princeton.edu CreditAttribution: gchalker@princeton.edu commentedHTML MARKUP in DRUPAL TITLES would be awesome!
At least the ability to use a sub or super script, considering that there are so many scholarly publications on the internet.
g.g.
Comment #71
cgfx CreditAttribution: cgfx commentedI see this is a long-running concern. Me, I just want to figure out why this is happening:
http://orc.one/node/18
Either strip the HTML out of the title when it's on the front page or just render it, I don't care which.
Obviously, it doesn't do this when on the "Drupal Wall" itself, but this seems to be the only place which does it. Editing from the front page makes the body copy formatting vanish, but not the title html. Frustrating.
Comment #79
bburgRe-iterating that this is an accessibility issue, and would love to be able to add abbr, and aria-label attributes in markup on titles, breadcrumbs, and just in plain_text fields in general.
Comment #80
tgoeg CreditAttribution: tgoeg commentedI think this aspect has really been underestimated in the whole discussion leading to here.
This is not something that's a nice-to-have or needs additional downloads of html_title to justify to bring it into core.
Drupal very much focuses on a11y and that's what I love it for.
We had to code up a pretty extensive solution to make HTML in titles happen, as our national a11y certification agency would deny us a WCAG compatibility certificate without it.
As soon as there are foreign terms/phrases in a title, they have to be marked up in the correct language, otherwise SC 3.1.2, "Language of parts", https://www.w3.org/WAI/WCAG21/Understanding/language-of-parts gets violated.
I therefore add a tag "Accessibility", change the title accordingly and make this a major bug as per https://www.drupal.org/about/features/accessibility as this potentially affects every Drupal page out there and even more so non-English ones as most languages tend to borrow from English.
Bold emphases by me:
Comment #81
mgiffordAdding WCAG SC 3.1.2.
Comment #82
pameeela CreditAttribution: pameeela commentedJust came across this issue as it's the oldest open bug in core. One thing that jumps out to me is that 8 years ago in #82751-50: Allow some HTML tags in node titles @effulgentsia notes that about 4,000 people were using the contrib module HTML Title. That stat is currently ~4,571 so not much of a change in that time.
Anyway, at that point, the decision seemed to be to not address this in core, but does that need to be re-assessed? I think it would be good to get some input on that before any work is done.
Comment #84
Pere OrgaThis seems a valid feature request. I'm updating the title, as this is not only about accessibility.