Only the content of the textarea is exported, not the format, which causes undesired behaviors for exported/code-based views.

Seems like it would be an easy fix, just need the following exported:

$handler->display->display_options['region']['area']['format'] = 'filter_format';
CommentFileSizeAuthor
#11 1034532-format-export.patch2.88 KBdamien tournoud
#10 1034532-format-export.patch1.31 KBdamien tournoud
#7 1034532-format-export.patch1.2 KBdawehner
#5 1034532-format-export.patch4.45 KBdawehner

Comments

slashrsm’s picture

slashrsm commented

Where did you use this field? I used it on footer and found out, that it includes format to export if Full HTML or Plain text are used. If I use Filtered HTML it exports no info about text format.

I am not sure, but this could be "by desing" behaviour.

Can you try to change text format and export again to see if you have same behavour as I have?

merlinofchaos’s picture

merlinofchaos commented

Yes, items that have default values are not exported.

Perhaps you should expand upon this: "which causes undesired behaviors for exported/code-based views." What are undesired behaviors?

duellj’s picture

duellj commented

Sorry, I should have investigated this a bit more. The undesired behavior I was seeing is that if the format isn't set for the view, for anonymous users it would show the Textarea as plain text. This is because on my site anonymous users only have access to the plain text format. So when there isn't a format option, views_handler_area_text defaults to filter_default_format(), which only load the formats the current user (which is anonymous when viewing the view) has access to. So even though the default input format is Filtered HTML for admin users (who created, exported the view), the Textarea is being displayed as Plain Text (default input format for anonymous users).

So the solution is to:

  1. Export the input format, even if it's the default filter format for the current user
  2. or get filter_default_format() for the user who edited the view

It seems like 1 would be a lot easier.

merlinofchaos’s picture

merlinofchaos commented

1) is, believe it or not, a lot harder.

It means that the default value for filters in Drupal 7 is too smart for its own good, and is therefore broken. Here's the thing: This should be true even if the view is not exported because the value used will be the same (which is the default filter format).

Oh Drupal.

dawehner’s picture

dawehner
Primary language German
commented
StatusFileSize
new 1034532-format-export.patch4.45 KB

What about something like this?

duellj’s picture

duellj commented
Status: Active » Needs work

dereine,

That works for newly created views, but for old views that were using the default input filter for textareas (and therefore don't have an input filter defined in the view) show nothing for the textarea. Looks like it's because of in views_handler_area_text::render_textarea():

    if (!isset($formats[$format])) {
      return;
    }

and you can't go directly to check_markup, because it defaults to the Plain Text format. So in order to not break old views you still need to provide a default filter format when the textarea is rendered (unless you're not caring about backwards compatibility).

Indeed, merlinofchaos, this does seem a lot harder then it first seemed :).

dawehner’s picture

dawehner
Primary language German
commented
Status: Needs work » Needs review
StatusFileSize
new 1034532-format-export.patch1.2 KB

Updated version based on last feedback.

dawehner’s picture

dawehner
Primary language German
commented

See #1065344: No text area for header/footer/empty text when creating view for a patch with the same kind of problems.

muriqui’s picture

muriqui commented

subscribe

damien tournoud’s picture

damien tournoud commented
StatusFileSize
new 1034532-format-export.patch1.31 KB

Free reroll. This makes a lot of sense.

Any exported view containing a text area handler will currently trigger ugly notices.

damien tournoud’s picture

damien tournoud commented
StatusFileSize
new 1034532-format-export.patch2.88 KB

views_plugin_exposed_form_input_required also had the same issue.

Also, I removed the unnecessary (and probably dangerous) fallback to the default. This is handled by core in a proper way in Drupal 7.

bojanz’s picture

bojanz commented
Status: Needs review » Reviewed & tested by the community

This completely makes sense.

dawehner’s picture

dawehner
Primary language German
commented
Status: Reviewed & tested by the community » Fixed 

-    static $formats = array();
-
-    if (!array_key_exists($format, $formats)) {
-      if ($filter = filter_format_load($format)) {
-        $formats[$format] = $filter->name;
-      }
-    }
-
-    if (!isset($formats[$format])) {
-      return;
-    }
-

Afaik this was included because filter_format_load(d6, or equal named function) didn't had static caching.

Thanks for rerolling/improve the patch and review it. Commited to 7.x

Status: Fixed » Closed (fixed)

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

BeaPower’s picture

BeaPower commented

Will this patch allow me to use text formats in views global area field?