I created a view to display upcoming events [custom cck] for 1 week from today [default argument]. The view works fine and outputs the correct nodes. I created a page that will display the output using quicktabs style. I created a custom date format that only displays the Day name and the date number (example: Thu 26). I then tell the quicktab style to use that custom date format as the tab label and the grouping field.
The tabs are created correctly but I get the div tags in the actual tab label. This happens with any date format I throw at it, but the tabs are rendered correctly if I change the grouping to some other field in the node [example: Location:City].


How were you able to get the quicktabs style in views, I don't see it...

For now, the solution to the problem is to click the field that you are outputting in Views and check the 'Strip HTML tags' checkbox, then reformat with css.

@BeaPower - are you using 6.x.2.x-dev? I'm not sure if the stable release has the Views Style in it. Try using the dev version, run updates, flush all caches and then see if it shows up in the list of views styles in the Views edit area fro any view you may have.

Title:Views Quicktabs style outputting div tags in Tab labels when using Date Formats as labelsTab titles shows escaped HTML tags/double escaped special characters
new817 bytes

Hey Guys,

The source of the issue is theme_quicktabs_tabs function (file quicktabs.module line 341).

.= '<li'. $attributes_li .'>'. l($tab['title'], $_GET['q'], $options) .'</li>';

All tab title text content goes through check_plain function = all html tags are being encoded in a plain-text string for display as HTML.

To fix we need make 2 changes: add flag into quicktab array and check it on rendering. Views module filters out fields content by itself. So we can do this (file includes/quicktabs.views.inc line 46):

= array(
'qtid' => $qtid,
'ajax' => '0', // TODO: Support AJAX, set this to $view->use_ajax.
'hide_empty_tabs' => '0',
'default_tab' => '0',
'style' => $view->style_options['tab_style'],
'tabs' => $tabs,
'sanitized' => TRUE

Next we should tell l function not to filter text (file quicktabs.module insert on line 380):

if($quicktabs['sanitized']) {
$link_options['html'] = TRUE;

Problem is solved.

- Roman

Status:Active» Needs review

Tested patch in #4 and works fine for me thanks Roman. Hoping someone else can review this too.

Status:Needs review» Reviewed & tested by the community

Patch in #4 works and allows the use of images as tab titles.

In the future, please follow Drupal coding standards when naming patches (http://drupal.org/patch/submit). Specifically, adding the issue # and comment # makes it much easier to determine if a patch is still necessary.



Title:Tab titles shows escaped HTML tags/double escaped special charactersResolved ut one more problem with clicking

By given patch issue resolved for me but one more problem arise with it that tabs are not proper. as i click on one tab it shows another tabs value while when i click last tab it doesn't shows any value.. when i click on blank space b4 first tab it shows value of first tab...

plz plz help me fast

Title:Resolved ut one more problem with clickingTab titles shows escaped HTML tags/double escaped special characters

Any progress on committing this?

I get an apostrophe escaped as &#039; in a quicktabs view.

Patch worked perfect. Thank you

Confirming that #4 works, as well.

new37.67 KB

I'm having some problem with the patch guys: I followed all the steps to configure git, but everytime I type

git apply -v quicktabs_tab_titles.patch

I got this error (see the attachment)... patch corrupted at line 19
I'm using the 6.x-3.x-dev version.



I saw the patch was made for 2.x dev version... I tested on 2-x but I got the same error :(
Is someone experiencing the same problem?

#4 Patch Works fine for me too..

Subscribe. Working on a D7 port.

I'm sure it's a hack, but I did get this working in D7

  $renderer = $form_state['values']['renderer'];
  $qt = new stdClass();
  $qt->title = $form_state['values']['title'];
  $qt->ajax = $form_state['values']['ajax'];
  $qt->default_tab = isset($form_state['values']['default_tab']) ? $form_state['values']['default_tab'] : 0;
  $qt->hide_empty_tabs = $form_state['values']['hide_empty_tabs'];
  $qt->renderer = $renderer;
  $qt->style = $form_state['values']['style'];
  $qt->tabs = $formvalues_tabs;
  $qt->options = isset($form_state['values']['options'][$renderer]) ? $form_state['values']['options'][$renderer] : array();
  $qt->sanitized = TRUE;

  $qt_name = $this->quickset->getName();
  $id = 'quicktabs-tab-' . implode('-', array($qt_name, $tabkey));
  // Need to construct the correct querystring for the tab links.
  $query = drupal_get_query_parameters(NULL, array("qt-$qt_name", 'q', 'page'));
  $query["qt-{$qt_name}"] = $tabkey;
  $link_options = array(
    'attributes' => array(
      'id' => $id,
    'query' => $query,
    'fragment' => 'qt-' . $qt_name,
  //if($quicktabs['sanitized']) {
    $link_options['html'] = TRUE;

It's essentially a very small adjustment of #4. I took out the conditional if statement as there because the settings $quicktabs variable is not within scope here. I'm sure there is some other way to check, but I'm on a deadline. cheers.

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

Hi, this problem still exist in version 7.x-3.0. Is there any patch available?


For D7, Quicktabs 3.4, I applied a crude hack that seemed to have fixed the problem:

In file quicktabs.module, starting at line 211:

$contents = array_merge($custom_tabs, $contents);
  $weight = array();
  foreach ($contents as $key => $item) {
  if(!empty($item['title'])) {
  $contents[$key]['title'] = html_entity_decode(strip_tags($item['title']));
  // Load the plugin responsible for rendering this item, if it is not a
        // prerendered tab.
        if ($item['type'] != 'prerendered') {
         ctools_plugin_load_class('quicktabs', 'contents', $item['type'], 'handler');

Version:7.x-3.0» 7.x-3.x-dev

I am using 3.4 and the ui_tabs renderer. Good way to do this probably would have been to write my own renderer.

Bad way to do this: go to "/modules/quicktabs/plugins" open "QuickUITabs.inc", Line 67 remove the check_plain() so the line reads

  '#markup' => '<a href="'. $href .'">'. $this->quickset->translateString($tab->getTitle(), 'tab', $i) .'</a>',

This introduces potential security risks, so be sure you know what you do. For the other renderers there probably is an analogical way. But: Write your own! :) There is information on that in the Readme.

#18 works! +1 for including it in the base module functionality.

Status:Reviewed & tested by the community» Needs review
new1.29 KB

Here is #16 in patch format.

Version:7.x-3.x-dev» 7.x-3.4

BTW, patch #21 is for the 7.x-3.4. Previous patches/suggestions applied to earlier versions.

Patch from #21 worked for me for QuickTabs 7.x-3.4. Thanks.

Status:Needs review» Reviewed & tested by the community

does this work for views with 'quicktabs' formatter?

Patch of #19 worked on my image quicktab. Hopefully the project doesnt allow to put new content if it's not the user-1 who put the new content, so i dont have to wonder too much about security

Status:Reviewed & tested by the community» Needs review
new1.55 KB

#21 contains commented out conditional logic and sets a value in _quicktabs_convert_form_to_quicktabs() irrespective of what the user enters, and which will never be saved. However, I don't see a need to enable this ability through the UI.

This patch changes the Quicktabs property to 'html' to match the parameter used in $link_options, and reads the property using the this->quickset->getSettings() method.

It also contains some whitespace fixes that my editor does by default.

Title:Tab titles shows escaped HTML tags/double escaped special charactersAllow HTML in tab titles
Status:Needs review» Fixed

With an RTBC from katbailey in IRC, #27 is committed.



Quick confirmation on this - it only applies to quicktabs created by views, right? I'm using Quicktabs to create a block, and there's no functionality added by this patch whatsoever that I can see. I'm guessing the best way forward is to create a view and display it as a block?

Actually, scratch my suggested solution. I'm using Quicktabs to switch between a newsletter signup block, a view with latest tweets, and a custom HTML block showing a Facebook like box. I strongly suspect it's impossible to create a view that returns these three items to Quicktabs, which presumably means this patch won't work for me.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Active

Is this patch commited in 7.x-3.x-dev ?
Does it include images as tab title for 7.x-3.x-dev ?

Or is there configuration to achieve HTML in tab titles?... what did I missed ?


new439 bytes

@jantoine: Yes, it's commited: http://drupalcode.org/project/quicktabs.git/commit/21d66fb9d88234440fa9a...

I just tested the 7.x-3.x version and it still doesn't work as intended. (I have exactly same problem as in original post http://drupal.org/files/issues/quicktabs%20SS.jpg)

@ezra-g mentions

I don't see a need to enable this ability through the UI.

and I think there is an error in patch #27. Imho this isset($settings['html']) ? $settings['html'] : FALSE is just leftover and shouldn't be there. - Please correrect me if my assumption is wrong.

Since this was already commited, my patch against 7.x-3.x just edits it to TRUE.

PS: If you don't need HTML in quick tabs (like on sceenshot with just some spans around dates) and you're using views to generate tabs, you can actualy edit the field with date and under "rewrite results" check "Strip HTML tags". ;-)

EDIT: Don't use attached patch, it's not secure, see #34.

What's proposed in #33 would introduce a security vulnerability, albiet not particularly severe.

@radimklaska, believe that assumption you're making is not correct. The patch in #27 appears to have aimed to make the HTML attribute toggleable. However, near as I can tell, there's no way to do this.

@ezra-g Any clarifications on "I don't see a need to enable this ability through the UI"? Or how did you intend this setting to be changed (through the GUi or code)?

@iamEAP: Thanks for clarification. I edited my post and added warning...

Version:7.x-3.4» 6.x-3.1

Is there a 6.x-3.1 version of the patch for apostrophes getting output as &#039 somewhere?

If so, I couldn't find it.

@ezra-g Any clarifications on "I don't see a need to enable this ability through the UI"? Or how did you intend this setting to be changed (through the GUi or code)?

I'm proposing that it's more appropriate as an API level attribute rather than something that's configurable through the UI.

Hi guys!

Worked for me #27 and then I applied the #33 patch.

This is a issue? To add the HTML option in module settings? It would be helpful to be added.

Applied patch #27 then #33 and it is working. It would be better if we add html settings. I guess we should go for a global setting, rather than individual settings for every quicktabs.

#18 it works for me perfectly

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

Returning to this... I see that this can now technically be overridden (as of 7.x-3.6):

= array(
// ...
'html' => isset($settings['html']) ? $settings['html'] : FALSE,

However, the only way to set anything in the settings property of the QuickSet class is when it's initially instantiated. I'm not sure we, outside of QuickTabs, have any way of affecting that, at least I am unable to do so in a Features export, for example. I especially have no control over this in a Quick Tabs style Views display.

Issue summary:View changes
Status:Active» Fixed

Most of these solutions seem to require hacking or patching the module. I don't see why that is necessary. The module provides theme functions to override the tab titles. I was able to override this theme function: theme_qt_quicktabs_tabset() and enable HTML for the tab links.

I posted my example of this on this duplicate issue: #1533410: Html Entities in Programmatically Created Quicktabs #11. If using the JqueryUI tab style, you'd use this function: theme_qt_ui_tabs_tabset().

Marking this as fixed because it seems like some patches have been committed, and the solution I just suggested should suffice otherwise.

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.