No text area for header/footer/empty text when creating view

Please search also on closed issues. This was reported already too many times.

So what's the solution, Daniel ?!? What's the reference issue ?

okay, the solution is (in my case and probably many others) to deactivate WYSIWYG.module.

ARRRRGHH. Damn. That's no solution at all. A real solution would be:

for drupal developers to
1) code a workaround to disable wysiwyg for the field, e.g. via form_alter with $form[ELEMENT]['#wysiwyg'] = FALSE;

for views (co)maintainers to
2) give a one-word hint like "wysiwyg.moule" even if their eyes are sore with duplicate issues.
3) integrate a warning ("this could be broken because of wysiwyg.module - just in case you are among the 50% of users who dare to use views _and_ wysiwyg api")

for site builders to
4) spend the weekend crying

I'll give solution 1) a shot.
Daniel (dereine), perhaps you try 3) to lessen the sore in your issue-queue-manager-eyes in the future ?

(set to "active" so maintainer can see this ;)

In an ideal world, wysiwyg would fix the problem so Views would quit getting blamed for it.

http://drupal.org/project/issues/views?text=header&status=All&priorities...

Here is a patch for solution 2)

Should such issues always have one open issue as placeholder?

wow, dereine is fast.
yes, wysiwyg is to "blame", but views could do something about it (and lessen then support load for views maintainers).
imho, one always-open-issue for this topic should do help people to find the cause of the problem quicker.

unfortunately, dereine's patch doesn't seem to work, perhaps the #wysiwyg property seems to be outdated: http://drupal.org/node/285200#comment-3892916

attached is a patch with a (manually) added warning that proposes three ways towyrds a solution right in the interface (if wysiwyg module is present).

another quick fix could be for views to default to the plain text format (if it's available). what do you think? This is unobstrusive for the rest of the site (rather than suggesting to the site builder to change to text format order for the whole site).

attached is a edited patch that uses filter_fallback_format() to set the default format for the 'global text' (and still contains #wysiwyg and the warning). Not perfect, since even the fallback filter _could_ be configured to use wysiwyg api ... but better in any case. what do you think?

Changing the default value might cause a problem.

If you have a certain value defined in option_definition and you don't change it in the form, the value is not stored in the export.
Once you change the default value the new value is loaded and boom you get a different output. This might be an edge-case.
I guess many people use the default format as format.

This is an example output. Some text was entered, but the format is not stored, additional.

/* Header: Global: Text area */
$handler->display->display_options['header']['area']['id'] = 'area';
$handler->display->display_options['header']['area']['table'] = 'views';
$handler->display->display_options['header']['area']['field'] = 'area';
$handler->display->display_options['header']['area']['empty'] = FALSE;
$handler->display->display_options['header']['area']['content'] = '<p>some text</p>';

Mh in general the value in option_definition should be plain text, but another #default_value should be set in the form itself, because
the filter_default_format() might change from installation to installation but your header should be the same in both.
So we should perhaps force to store the format always.

ouuh, didn't think of that edge-case, but it's an important one. Forced storage might be a good solution (also because then chaning your default format won't override all your views in all your features, but that's another topic!).

Anyway, here's a quick fix solution anyone with a custom module can implement, that forces the fallback format (if not "php_code" is already used). Not perfect, since very forceful and bully-ish, but works in many cases (at least mine ;)

/**
 * Implements hook_form_alter() for the views_ui_config_item_form.
 * to set the default text format to the fallback format
 * to prevent wysiwyg module from breaking views ui text areas.
 */
function YOURMODULE_form_views_ui_config_item_form_alter(&$form, &$form_state) {
  if ($form['options']['content']['#format'] != 'php_code') {
    $form['options']['content']['#format'] = filter_fallback_format();
  }
}

Thanks! Works great for me.

After some thoughts about it. This is not only an edge case.

We have to support previous values.
So what about this patch?

I've got this error too and am not using wysiwyg. I am using CKEditor but disabled the module to no effect.

Definitely a Wysiwyg problem. When you use Firebug or Webkit inspector (Chrome/Safari), select the textarea tag, choose to dynamically delete "visibility:hidden" and Views textarea will work fine again. Deactivate Wysiwyg and the problem is gone.

Tried the patch in #13, no success :(

#11 works wonderfully

Thanks #17!

The current patch doesn't really solve the problem, it just fixes some edge cases.

No idea how we should use filter_fallback_format without breaking existing views headers.

To be enoughst this still needs work.
There is no patch to solve the real problem without causing major problems with existing views.

Commited a #wysiwyg => FALSE part.

So in general this could be marked as fixed from my perspective.

Not sure if my problem is related or not, but I too am missing a text area in Views. In my case, however, it's the text area of the Global Custom Text field.

Right after creating a new View, it's easy to add a Global Custom Text field, and put in it some static text, and also place in it a token from the Content Title field.

After adding new Fields to the View, however, and upon returning to Global Custom Text to add more tokens, the text area is no longer there, so the "assembly" can no longer be modified. All other options (Style Settings, No Results Behavior, etc) are still available and editable. But no text area.

Strangeness, ja?

Running D7. As of April 2011, also installed are the latest versions of CTools, Token, Views, Backup and Migrate, Advanced Help, Administration Menu, Taxonomy CSV, JobScheduler, Feeds, References, Field Group, Webform, Features, Context, Quicktabs, Panels, PathAuto.

No WYSIWYG editor of any flavor installed.

As always, any insights appreciated.

See #1131424: Global: Custom Text cannot be configured for an issue about global custom field.

@dereine Thanks much for pointing me in the right direction. Will subscribe to that issue, then.

wyswiyg false is implemented and the format is now defaulted to NULL.

Let's mark this issue as fixed

woot

please, tell me, is wysywig editor must work in views header ?

please, tell me, is wysywig editor must work in views header ?

You ask whether the wysiwyg editor should be shown in views?