Add an area handler for unfiltered text

I didn't tested the patch but from the code-side this looks fine.

The original patch in #1652724-9: Add empty table and text when there are no results had support for Views' tokens - any particular reason for why that has been dropped?

+++ b/handlers/views_handler_area_text_admin.inc
@@ -0,0 +1,48 @@
+ * Definition of views_handler_area_text_admin.

+++ b/modules/views.views.inc
@@ -57,6 +57,14 @@ function views_views_data() {
+  $data['views']['area_admin'] = array(

Shouldn't the internal handler name also be 'area_text_admin'?

+++ b/modules/views.views.inc
@@ -57,6 +57,14 @@ function views_views_data() {
+    'title' => t('Administration text area'),

I wonder whether "Administrative text" wouldn't make more sense?

(I've to admit I always struggled with the exposure of the internal "area" concept in the UI for the text "area" handler, which at least for me is steadily confused with a "textarea" form element.)

+++ b/modules/views.views.inc
@@ -57,6 +57,14 @@ function views_views_data() {
+    'help' => t('Add custom administration text or markup into an area. This is filtered through filter_xss_admin().'),

I also wonder whether this is a good, user-friendly help text/description...

I'm not sure, and I could be mistaken, and really, I'd be glad if I am, but I somewhat doubt that users understand what that filter_xss_admin() function means? ;-D

I'm don't know whether such a concept exists in Views API, but technically, this handler ideally should only be editable in the Views UI by users who have the "administer site configuration" permission. Though I guess such a concept does not exist yet.

drop the part in the description about filter_xss_admin(), and just stick with the first sentence then?

I guess it would make sense to make the effect of filter_xss_admin() clear.

From an end-user perspective, the relationship with "administrative" and anything "admin" is actually irrelevant and non-existent. Intead, I think that the important difference to the other text area is:

- (quasi) unrestricted
- "unsecure"
- unfiltered (no text format and no filters)

The best way to clarify this is probably to combine a concise description with a concise label; e.g.:

• Unfiltered text

  Add unrestricted, custom text or markup. Warning: This may have security implications depending on the text being configured.

(Warning text taken from Filter module's text format permission descriptions.)

+++ b/handlers/views_handler_area_text_admin.incundefined
@@ -0,0 +1,48 @@
+class views_handler_area_text_admin extends views_handler_area {

Ups i think there was a clear misunderstanding ... i thought we extend from views_handler_area_text to get the token support for free

I'll have to defer to @dawehner regarding tokens, but personally I'd love to have support for them.

I'm not sure whether this kind of inheritance is really appropriate (the widget as well as the output is different after all), and I wonder whether other code might get confused by the additional/alternative but actually completely different inherited object.

It would make more sense for me to either move the token handling code into a shared base class for both, or just simply copy/duplicate it.

However, ultimately that's for @dawehner to decide. ;)

Awesome, sorry for all the review noise. Committed to 7.x-3.x and 8.x-3.x

+++ b/handlers/views_handler_area_text_admin.inc
@@ -0,0 +1,56 @@
+class views_handler_area_text_admin extends views_handler_area_text {

+++ b/handlers/views_handler_area_text_custom.inc
@@ -0,0 +1,56 @@
+class views_handler_area_text_custom extends views_handler_area_text {

+++ b/modules/views.views.inc
@@ -57,6 +57,14 @@ function views_views_data() {
+  $data['views']['area_text_custom'] = array(
...
+      'handler' => 'views_handler_area_text_custom',

+++ b/views.info
@@ -12,6 +12,7 @@ dependencies[] = ctools
 files[] = handlers/views_handler_area_text.inc
+files[] = handlers/views_handler_area_text_custom.inc

Was the _admin handler still supposed to be contained...?

Sorry, I forgot to mention this. This file was ignored in the commit.