Problem/Motivation

Config translation has a schema type for text elements with format. However views area plugin "Text" does not use this schema type.

Proposed resolution

Use the new text_format type. Restructure the views data structure to use that nested data format.

Remaining tasks

Commit.

Steps to test

  1. apply patch
  2. if not committed yet, apply patch from #2144413: Config translation does not support text elements with a format
  3. install
  4. enable modules: config_translation (which will enable language)
  5. add a language, admin/config/regional/language
  6. go to a view, content list, or create a new testing view.
  7. Add to the Header, a global: text area. You might want to check off: display even if no results.
  8. Add to the Footer, a global: test area. You might want to check off: display even if no results.
  9. translate the view. Expand out lots of stuff till you find the header.
  10. Notice that the format text area widget is used. Nice.
  11. (not part of this issue?) change the text. save. view the view in both default language and added language, see if header text changes.

User interface changes

Use appropriate text format widget for editing translatable part of config. WYSIWYG will appear in config translation when translating this type of field. The source will appear in a disabled WYSIWYG also.

API changes

View structure changes to use the nested text + format.

Comments

webflo’s picture

Gábor Hojtsy’s picture

+++ 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?

vijaycs85’s picture

  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]?

webflo’s picture

I don´t think so. The 'contains' key is a special key that is used in PluginBase::setOptionDefaults to apply default values in nested option arrays.

dawehner’s picture

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

YesCT’s picture

Issue summary: View changes

steps to test.

YesCT’s picture

Issue summary: View changes

oops dont need the test module

YesCT’s picture

FileSize
234.05 KB
+++ 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.

YesCT’s picture

Issue summary: View changes
FileSize
182.67 KB

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.

YesCT’s picture

FileSize
231.08 KB

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

dawehner’s picture

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

Gábor Hojtsy’s picture

Issue tags: -sprint

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

tstoeckler’s picture

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.

tstoeckler’s picture

Status: Postponed » Needs 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’s picture

Gábor Hojtsy’s picture

@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?

tstoeckler’s picture

+++ 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.

Gábor Hojtsy’s picture

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?

tstoeckler’s picture

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?!".

Gábor Hojtsy’s picture

Let's move forward here then.

Gábor Hojtsy’s picture

Gábor Hojtsy’s picture

vijaycs85’s picture

Status: Needs work » Needs review
FileSize
875 bytes
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 81,667 pass(es), 32 fail(s), and 28 exception(s). View
Gábor Hojtsy’s picture

Status: Needs review » Needs work

@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

The last submitted patch, 23: 2144505-text_format-views-area-23.patch, failed testing.

tstoeckler’s picture

Status: Needs work » Needs review
FileSize
3.05 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 81,719 pass(es), 14 fail(s), and 32 exception(s). View

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.

Gábor Hojtsy’s picture

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.

Status: Needs review » Needs work

The last submitted patch, 26: 2144505-26-views-area-text-schema-text-format.patch, failed testing.

vijaycs85’s picture

Just changing a text type to text_format will not suffice.

- oops, sorry for the wrong alarm.

tstoeckler’s picture

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.

tstoeckler’s picture

Assigned: Unassigned » tstoeckler

Working on this.

tstoeckler’s picture

Assigned: tstoeckler » Unassigned
Status: Needs work » Needs review
FileSize
2.52 KB
5.74 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 81,775 pass(es). View

This should be green.

Gábor Hojtsy’s picture

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?

Gábor Hojtsy’s picture

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

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
141.99 KB

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. :)

Gábor Hojtsy’s picture

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

Gábor Hojtsy’s picture

Issue tags: +D8 upgrade path

Changes view formatted text field structure, so tagging accordingly.

tstoeckler’s picture

:-) 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.

tstoeckler’s picture

Related issues:
tstoeckler’s picture

Related issues:

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

dawehner’s picture

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?

tstoeckler’s picture

FileSize
458 bytes
5.74 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 81,936 pass(es). View

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

Leaving at RTBC.

Gábor Hojtsy’s picture

@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.

Gábor Hojtsy’s picture

Title: Use text_format type in views config translation schema » Views does not use the text format type for formatted text
Category: Task » Bug report
Issue summary: View changes

Updated issue summary.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

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!

Gábor Hojtsy’s picture

  • alexpott committed 48813a2 on 8.0.x
    Issue #2144505 by tstoeckler, YesCT, Gábor Hojtsy, vijaycs85, webflo:...

Status: Fixed » Closed (fixed)

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