Views does not use the text format type for formatted text

+++ b/core/modules/views/config/schema/views.data_types.schema.yml
@@ -176,6 +176,11 @@ views_display:
         - type: views.relationship.[plugin_id]
+    header:
+      type: sequence
+      label: 'Header'
+      sequence:
+        - type: views.area.[plugin_id]
 

There are other elements like footer, etc here possibly no?

1. +++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Text.php
   @@ -35,9 +39,9 @@ public function buildOptionsForm(&$form, &$form_state) {
   +      '#default_value' => $this->options['content']['value'],
   

   isn't it [content][contains][value]?

2. +++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Text.php
   @@ -35,9 +39,9 @@ public function buildOptionsForm(&$form, &$form_state) {
   +      '#format' => isset($this->options['content']['format']) ? $this->options['content']['format'] : filter_default_format(),
   

   isn't it [content][contains][format]?

The patch is right. contains is just used to set the default values, nowhere else.

steps to test.

oops dont need the test module

+++ b/core/modules/views/config/schema/views.data_types.schema.yml
@@ -176,6 +176,11 @@ views_display:
+    header:
+      type: sequence
+      label: 'Header'
+      sequence:
+        - type: views.area.[plugin_id]

why are we adding this, specifically for the header?

I tried editing a view, and header is not text format by default, have to add global: text.

that can also be added to footer, and a field.

updated steps to test.

should saving work?
Translating the header text results in that new text in the default config/language for me.

After patches:
Here is what the translate view looks like which uses the text format widget thing.

Before patches:
... header does not show up in the translate at all.
no screenshot.

So, maybe there is another issue here, just getting the header (footer, other) text to show up in the config translation at all. Probably just needs to be added to the schema.
Then, also to use the new text format type.

This issue is fixing both issues in one.

Needs work (but leaving it postponed):
- translation overwrites untranslated config
- need to add schema for footer
- need to add schema for fields (which might be global text area). This might be covered as part of another issue general views field schema, or general views translation ui.

note the views edit of header does not use the fancy widget. So.. maybe config translate should not either?

note the views edit of header does not use the fancy widget. So.. maybe config translate should not either?

Just in case someone wonders why we don't use a FULL wysiwyg editor in the views header:
These have caused troubles when they were loading in dialogs previously, WARNING! #1065344: No text area for header/footer/empty text when creating view !WARNING

Removing from sprint since this was postponed for so long....

I just tried enabling editor support in View UI, but it still does not work in D8. If you try to insert an image. The image dialog replaces the Views UI overlay-dialog, and then pressing save in the image dialog does not work.

Opened #2272369: What to do with nested dialogs? for that problem. I think we should proceed here without #2144413: Config translation does not support text elements with a format in the meantime. I.e. we should adapt the config structure to have a 'value' and 'format' key as is it were using 'type: text_format' in the schema, but simply use two 'type: string's for now. Then once the referenced issue is in, we can switch to 'type: text_format' without breaking anything, i.e. past beta.

@tstoeckler: it is already two distinct items, not sure what is to do here outside of adapting to #2144413: Config translation does not support text elements with a format. Besides, I think the goal for beta is to have a stable data model. If we know we want to make that change later, then beta is not that stable... So it would be important for us to complete this before, although not vital. We started on it in Prague. How can I help to make #2144413: Config translation does not support text elements with a format happen?

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Text.php
@@ -21,8 +21,12 @@ class Text extends TokenizeAreaPluginBase {
-    $options['content'] = array('default' => '', 'translatable' => TRUE, 'format_key' => 'format');
-    $options['format'] = array('default' => NULL);
+    $options['content'] = array(
+      'contains' => array(
+        'value' => array('default' => '', 'translatable' => TRUE),
+        'format' => array('default' => NULL),
+      ),
+    );

@@ -35,9 +39,9 @@ public function buildOptionsForm(&$form, &$form_state) {
-      '#default_value' => $this->options['content'],
+      '#default_value' => $this->options['content']['value'],
...
-      '#format' => isset($this->options['format']) ? $this->options['format'] : filter_default_format(),
+      '#format' => isset($this->options['content']['format']) ? $this->options['content']['format'] : filter_default_format(),

Well, I meant changes like this actually. We can actually make those without using the 'text_format' schema type for now.

Is that using a structure and keys that #2144413: Config translation does not support text elements with a format would work with? Are we sure we agreed on #2144413: Config translation does not support text elements with a format enough to make these changes now?

Well @Jose Reyero recently voiced some concerns over there, but I didn't see anything related to the config structure. (Only where the translatable: true sits). All patches so far have used the same config structure and so far no one has complained. So I'd tentatively, say "Yes?!".

Let's move forward here then.

#2144413: Config translation does not support text elements with a format landed. Moving this to the sprint.

Initial patch...

found few regressions and filed them at #2381067: Regression: Config translation's text_format doesn't display the text in view area

@vijaycs85: The issue you opened seems to be a bug with how you introduced text format in your patch, not in head. Look at the original patch above by @webflo and #2144413: Config translation does not support text elements with a format. Basically text formatting is supported on a nested mapping level (format and value are on the same level but nothing else). It is not enough to just use a different format in these views places, their structure needs to change, which is what @webflo has provisions for above. Your patch just changes the types, but that is what leads to the bugs you reported at #2381067: Regression: Config translation's text_format doesn't display the text in view area in the first place.

The text format type definition is:

# Text with a text format.
text_format:
  type: mapping
  label: 'Text with text format'
  # We declare the entire mapping of text and text format as translatable. This
  # causes the entire mapping to be saved to the language overrides of the
  # configuration. Storing only the (to be formatted) text could result in
  # security problems in case the text format of the source text is changed.
  translatable: true
  mapping:
    value:
      type: text
      label: 'Text'
      # Mark the actual text as translatable (in addition to the entire mapping
      # being marked as translatable) so that shipped configuration with
      # formatted text can participate in the string translation system.
      translatable: true
    format:
      type: string
      label: 'Text format'
      # The text format should not be translated as part of the string
      # translation system, so this is not marked as translatable.

Just changing a text type to text_format will not suffice. It makes a string into a mapping :D

Yes, the patch in #1 was the right approach. Reviving that as it didn't apply anymore. (Couldn't be bothered to re-roll properly, just re-created from scratch, thus no interdiff.)

I checked and the format_key stuff is obsolete already (i.e. used nowhere in core) and it is a leftover of the locale integration of Views in D7.

Thanks, spotted one issue:

+++ b/core/modules/views/src/Plugin/views/area/Text.php
@@ -23,7 +23,12 @@ class Text extends TokenizeAreaPluginBase {
-    $options['content'] = array('default' => '', 'format_key' => 'format');
+    $options['content'] = array(
+      'contains' => array(
+        'value' => array('default' => ''),
+        'format' => array('default' => NULL),
+      ),
+    );
     $options['format'] = array('default' => NULL);

Should not have the standalone format key (at the bottom of this snippet) anymore, right?

Also @vijaycs85 applied the format to other elements as well, not just the text type.

Just changing a text type to text_format will not suffice.

- oops, sorry for the wrong alarm.

Re #27:

Oops, yes, forgot to delete that.

I saw that in #23 but I don't think it's correct. There's a couple area handlers, but one is just plain, non-formatted text (text_custom) and one shows the number of results, etc. Only the text one actually uses '#type' => 'processed_text' (i.e. check_markup()), though, so I think #26 is correct. Please do go and check that I'm not on crack, though! :-)

Btw. I grepped all config schemas for "format" and in the process I found #2381147: Text and text with summary field default value config does not use the text_format schema type
That issue is a little bit more tricky (because of the text_with_summary thing...) but that should cover it. I don't think we have anything using formatted text that does not use the 'format' string.

Working on this.

This should be green.

The changes all make sense. So I think what this should do in practice is config translation module should display "No front page content has been created yet." in a WYSIWYG widget on the translation UI right? I cannot reproduce that unfortunately. What am I missing?

Uhm, that is "area_text_custom" type, not to expect to have WYSIWYG on it. Duh.

So I added a text field, and it works flawlessly, so this does not only look good in code, it works well in practice also. :)

BTW the views UI itself does not even embed the WYSIWYG for the same setting (it only has the good old text format selection dropdown) so the config translation UI is easier to use for this field :O

Changes view formatted text field structure, so tagging accordingly.

:-) Yeah, Views UI explicitly disables the text editor as loading a text editor in a popup is not safe ATM because the editor itself can open dialogs (i.e. for inserting an image) and loading a dialog inside of a dialog currently goes massively wrong.

See also #2272369: What to do with nested dialogs? for that...

Sorry, #fail. That was already in the related issues....

This looks certainly good so far!

+++ b/core/modules/views/src/Plugin/views/area/Text.php
@@ -23,7 +23,12 @@ class Text extends TokenizeAreaPluginBase {
+    $options['content'] = array(
+      'contains' => array(
+        'value' => array('default' => ''),
+        'format' => array('default' => NULL),
+      ),
+    );
     $options['format'] = array('default' => NULL);

Can't we drop the options 'format' then?

Oh right. Had totally forgotten about that, sorry. Thanks for noticing!

Leaving at RTBC.

@dawehner: haha, I had the same question in #27, don't know how I missed that it was not fixed. Thanks @tstoeckler for fixing, I agree keeping RTBC.

Updated issue summary.

This issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per https://www.drupal.org/core/beta-changes. Committed 48813a2 and pushed to 8.0.x. Thanks!

Yay thanks, now onto #2381147: Text and text with summary field default value config does not use the text_format schema type :)