Adding additional Block Formats (e.g. HTML5 elements) in CSS fieldset on text filter setting page does not make them available.

The Block Formats list sets the theme_advanced_blockformats setting, not the style_formats setting, which was added later.

We don't have a GUI widget to control TinyMCE's style_formats setting yet, but you can control it using a small custom module until we do by implementing hook_wysiwyg_editor_settings_alter().

sites/default/modules/custom/custom.info:

name = Custom
description = My custom module for various tweaks.
core = 7.x

sites/default/modules/custom/custom.module:

/**
 * Implements hook_wysiwyg_editor_settings_alter().
 */
function custom_wysiwyg_editor_settings_alter(&$settings, $context) {
  if ($context['profile']->editor == 'tinymce') {
    $settings['style_formats'] = array(
      array('title' => 'h1', 'block' => 'h1'),
      array('title' => 'h2', 'block' => 'h2'),
      array('title' => 'h3', 'block' => 'h3'),
      array('title' => 'h4', 'block' => 'h4'),
      array('title' => 'h5', 'block' => 'h5'),
      array('title' => 'h6', 'block' => 'h6'),
      array('title' => 'p', 'block' => 'p'),
      array('title' => 'div', 'block' => 'div'),
      array('title' => 'pre', 'block' => 'pre'),
      array('title' => 'section', 'block' => 'section', 'wrapper' => TRUE, 'merge_siblings' => FALSE),
      array('title' => 'article', 'block' => 'article', 'wrapper' => TRUE, 'merge_siblings' => FALSE),
      array('title' => 'blockquote', 'block' => 'blockquote', 'wrapper' => TRUE),
      array('title' => 'hgroup', 'block' => 'hgroup', 'wrapper' => TRUE),
      array('title' => 'aside', 'block' => 'aside', 'wrapper' => TRUE),
      array('title' => 'figure', 'block' => 'figure', 'wrapper' => TRUE),
    );
  }
}

Err. That style_formats looks fairly similar to the one of CKEditor?
http://www.tinymce.com/wiki.php/Configuration:style_formats
http://docs.cksource.com/CKEditor_3.x/Developers_Guide/Configuration/Styles

We just extended the API to allow to configure this specifically for CKEditor Styles:
#1650416: Allow editor specific changes to be made to the profile settings form
#746524: No Font Styles for CKeditor

Now, the syntax/settings of TinyMCE appear to be almost exactly the same... ;)

Right, let's summarise.

If you want a) HTML5 block elements or b) Wrapper elements (e.g. a div with lots of paragraphs in it) in TinyMCE in Drupal, you can force them in as Styles that appear in the dropdown usually controlled by the CSS Styles box in the WYSIWYG module form.

You can do this two ways:

1. The quick hard-coding approach. Download the module anandps provided above, modify to suit your case (e.g. it's set to only work in Full HTML mode, you might want Filtered HTML instead or as well), and hard-code in some styles. In its current form, it overrides anything entered into the CSS Styles form in the WYSIWYG module. To make something a wrapper, make sure it has wrapper => true, which is something specific to TinyMCE
2. The long-term UI approach. WYSIWYG module only recently gained the ability to process things like CSS styles differently for different editors, and currently it's only set up for CKEditor which adds a similar feature. You could look at the issue where this was added, look at the patch that added the feature, and adapt it to work with TinyMCE (then share the patch here...). This might be part of the WYSIWYG module one day.

If you want to hard-code in a wrapper element that also has a class, it could look like this (note the slightly counter-intuitive 'classes' / string combo):

$settings['style_formats'][] = array(
        'title' => 'Wrapper (div)',
        'block' => 'div',
        'wrapper' => TRUE,
        'classes' => 'someclass, anotherclass'
      );

(tip for non-HTML5 wrappers: non-wrapper divs within a wrapper div are applied to the whole div. Non-wrapper <p>s within a wrapper div apply only to that paragraph)

The stuff about Visual Blocks is a separate bonus TinyMCE feature, adding a button that toggles dotted-line outlining of block elements. It's an alternative to adding visual cues to using a custom TinyMCE stylesheet defined in the WYSIWYG module CSS Settings form. Using one or the other is a good idea so your users can see the scope of wrapper elements intuitively.

Correcting name of file I looked in to find clues as to what the problem is.

Hello,
Is something new happening on this issue? I gave the module wysiwyg_customisations a try and it worked - thanks a lot. But I was wondering why we are mixing up block formats and styles? Wouldn't it be better to have the new html5 elements in the block formats dropdown?
Just replacing style_formats with block_formats in wysiwyg_customisations.module didn't do the trick.

When using this module I am missing my custom styles. Can't I have both?

Greetings
suldan

Not much going on here, no. Not had time to dig into this.

If you're using TinyMCE 3, the block formats setting is called theme_advanced_blockformats, and it's also available for customization through hook_wysiwyg_editor_settings_alter(). Just note that since it's controllable via the editor profile GUI, it may already have a value (a string of comma-separated block tags).

If you're using Wysiwyg with the patch for TinyMCE 4, you can add the block_formats setting separately using the same hook.
Note that the block_formats setting takes a string, unlike the style_formats setting which takes an array.

The plugin from #3 has an issue which I have fixed now.

BTW, solved this issue with simple patch (attached) - after it block formats override works well for me in TinyMCE4.

Thanks for the patch @skylord, good catch!

I think I'm going to close this as "fixed" with this committed. The settings customization i mentioned in #7 still works and gives you total control of all editors which supports swapping out a block element's type like this.

The concerns mentioned in #6 about mixing "block formats" and "styles" I don't think I can really do much about without making things more confusing. As it currently is, the GUI widgets map to specific editor settings and tries to use their default values and functinality as established by the developers of each editor. If we go in and override these by say making an active choice to impose limitations on the profile GUI (say only allowing or defaulting to only using non-block element stuff in the styles area because that's already covered by another setting, etc), I think we'd end up having to make more and more tweaks until "everyone" is happy with the defaults, which is probably impossible. Sticking with what the editor does by default and not forcibly setting values on options that we haven't consciously touched in the GUI is a lot easier and would be much easier to stick with as the libraries evolve.