Problem/Motivation

NodeViewBuilder hardcodes the display of the langcode field ignoring any formatter configuration. This is a barrier if you want to create new formatter such as:

  • Display name with native names
  • Add flag icons for languages
  • Display source language

Proposed resolution

Remove the hardcode langcode element in NodeViewBuilder and keep the wrapper for BC.

Remaining tasks

Review

User interface changes

The display of the language field will change a little, because the 'field-language-display' wrapper will be gone.

API changes

The 'field-language-display' wrapper will be gone. However, this fixes a potential issue with having multiple same ID's on the same page, e.g. on a node list.

Data model changes

None

Release notes snippet

Through the removal of the hardcoded display of the langcode field, are <a href="https://www.drupal.org/node/3325438">developers be able to provide new formatters</a>, so that sitebuilder can configure a different output.

-- Original report --

Any options that are selected for language field formatter are ignored and the language field is always displayed as plain text language name.

Steps to reproduce:

  1. Enable translations.
  2. Create translatable content type.
  3. Select language field to be displayed.
  4. Check formatter option "Link to the Content".
  5. Create new node.
  6. View the node and you'll see plain text language name instead of a link.

I have noticed this when I was writing custom field formatter for the language field. It's easy to see the problem once you try to change the output for the core's language field. For example try this formatter:

namespace Drupal\custom_formatter\Plugin\Field\FieldFormatter;

use Drupal\Core\Field\FieldItemInterface;
use Drupal\Core\Field\Plugin\Field\FieldFormatter\LanguageFormatter as BaseFormatter;

/**
 * Plugin implementation of the 'custom_formatter' formatter.
 *
 * @FieldFormatter(
 *   id = "language_custom_fomatter",
 *   label = @Translation("Language with flag"),
 *   field_types = {
 *     "language"
 *   }
 * )
 */
class LanguageCustomFormatter extends BaseFormatter {

  /**
   * {@inheritdoc}
   */
  protected function viewValue(FieldItemInterface $item) {
    $view = parent::viewValue($item);

    $view['#plain_text'] .= ' Test';

    return $view;
  }
}

The formatter itself is registered correctly, you can enable it for the language field. The settings form works fine, but the actual output of the formatter is totally ignored. For example instead of seeing "English Test" I always get "English".

CommentFileSizeAuthor
#85 interdiff_83_85.txt2.58 KBjidrone
#85 2637808-85.patch29.4 KBjidrone
#84 interdiff_83_84.txt20.09 KBjidrone
#84 2637808-84.patch30.18 KBjidrone
#83 interdiff_82_83.txt841 bytesjidrone
#83 2637808-83.patch29.43 KBjidrone
#82 interdiff_72_82.txt24.49 KBjidrone
#82 2637808-82.patch29.42 KBjidrone
#81 interdiff_72_81.txt3.42 KBjidrone
#81 2637808-81.patch8.47 KBjidrone
#72 interdiff_68-72.txt3.02 KBjidrone
#72 2637808-72.patch4.23 KBjidrone
#71 interdiff_68-71.txt7.57 KBjidrone
#71 2637808-71.patch4.17 KBjidrone
#68 interdiff_66_68.txt1.29 KBameymudras
#68 2637808-68.patch4.35 KBameymudras
#66 interdiff-2637808-62_66.txt946 bytesAnchal_gupta
#66 2637808-66.patch4.1 KBAnchal_gupta
#62 test-only.patch1.67 KBjidrone
#62 2637808-62.patch4.11 KBjidrone
#60 2637808-60.patch4.11 KBjidrone
#56 2637808-56.patch2.41 KBjidrone
#55 2637808-55.patch2.38 KBjidrone
#52 interdiff-2637808-51.txt2.27 KBAnchal_gupta
#52 2637808-51.patch2.27 KBAnchal_gupta
#46 drupal-language_formatter_not_used_nodes-2637808-46.patch2.43 KBrp7
#45 drupal-language_formatter_not_used_nodes-2637808-45.patch2.43 KBrp7
#42 interdiff-2637808-40-42.txt602 bytesmrinalini9
#42 drupal-language_formatter_not_used_nodes-2637808-42.patch2.75 KBmrinalini9
#40 drupal-language_formatter_not_used_nodes-2637808-40.patch2.73 KBrp7
#34 2637808-34.patch2.73 KByogeshmpawar
#28 2637808-28.patch2.72 KBandrey.troeglazov
#26 2637808-26.patch2.72 KBandrey.troeglazov
#11 2637808-11.patch2.77 KBamateescu
#11 2637808-test-only.patch1.18 KBamateescu
#9 2637808-9.patch2.09 KBswentel
#4 2637808-4.patch756 bytesswentel

Issue fork drupal-2637808

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

SiliconMind created an issue. See original summary.

SiliconMind’s picture

Gábor Hojtsy’s picture

Issue tags: +D8MI, +language-base

Don't know why would this happen. I think we do have plenty tests around the language formatter. Hm. Maybe we only test it in views.

swentel’s picture

Status: Active » Needs review
FileSize
756 bytes

Wow, this is priceless, the NodeViewBuilder class still has a check on the 'langcode' component, overriding whatever is set in any formatter for this component ... :)

Gábor Hojtsy’s picture

Issue tags: +Needs tests

Hahaha. Definitely needs tests.

swentel’s picture

Title: LanguageFormatter is ignored when displaying language field » LanguageFormatter is not used for nodes because it's still hardcoded NodeViewBuilder
Issue summary: View changes

Changing the title

swentel’s picture

Title: LanguageFormatter is not used for nodes because it's still hardcoded NodeViewBuilder » LanguageFormatter is not used for nodes because it's still hard coded in NodeViewBuilder

Status: Needs review » Needs work

The last submitted patch, 4: 2637808-4.patch, failed testing.

swentel’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests
FileSize
2.09 KB

Funny, so there's a test that sets the field on the manage display screen. And it fails without the code in NodeViewBuilder because the asserts are checking on the 'field-language-display' ID.

Now, it's actually impossible to fix this without breaking markup. The original code has a wrapper which wraps the label and the value. A formatters returns the value, but can't set a prefix for the whole field. The label will have different wrappers too.

I honestly don't think a lot of sites display this element anyway, and if they want to alter it, it's kind of tedious to do. Also, additional formatters simply don't run or change the behavior of what's on the page. I think, IMHO, we can live with removing the field-language-display wrapper. But that's not my call of course :)

Patch attached fixes the tests.

swentel’s picture

Issue summary: View changes
amateescu’s picture

Version: 8.0.1 » 8.0.x-dev
FileSize
1.18 KB
2.77 KB

Here's an explicit test for the fact that the 'Link to content' settings doesn't work :)

The last submitted patch, 11: 2637808-test-only.patch, failed testing.

tstoeckler’s picture

Could we do something like this for BC (and remove in D9) in NodeViewBuilder?:

if (isset($build[$id]['langcode'])) {
  $build[$id]['langcode']['#prefix'] = '<div id="field-language-display">';
  $build[$id]['langcode']['#suffix'] = '</div>';
}

That would still retain the flexibility of choosing another formatter, etc.

Not sure if it would a dealbreaker to lose the wrapper either, just thinking out loud here.

swentel’s picture

Regarding #13, yeah, that would work indeed. We could even add this as a setting in the formatter and default to TRUE ?

Gábor Hojtsy’s picture

Issue tags: +sprint

@tstoeckler/@swentel: depending on the formatter used, are we sure the prefix/suffix would work like that? It sounds overkill to add that to the formatter settings, but maybe an "Add field-language-display class for backwards compatibility" or some other obscure settings just to be strictly backwards compatible could work. Would be good to get some committer feedback as to how strong they feel about the need to keep that.

swentel’s picture

Version: 8.0.x-dev » 8.1.x-dev

Talked to alex about it - tldr - we need an upgrade path to remove the 'link to content' in case someone saved it. And a way to keep the wrapper for BC. I think the formatter setting would work fine here.

<alexpott> swentel: 8.1 ... there's a question about upgrade path
<alexpott> swentel: given that it is not at all related to security I think we should ensure that all sites look the same before and after applying the patch
<alexpott> swentel: so I think we need a hook_update_N to ensure this
<swentel> alexpott, k, but, the update hook maybe isn't even necessary
<swentel> formatter settings defaults are merged, so should work out of the box
<alexpott> swentel: but what happens if someone has done the steps to reproduce?
<alexpott> swentel: won't applying the patch suddenly make the language field link to content?
<swentel> alexpott, no, because that one is FALSE by default
<swentel> alexpott, and it wouldn't work right now anyway
<alexpott> swentel: I mean if they've checked that now - don't we save that?
<alexpott> swentel: and then it doesn't work... but they leave it checked
<alexpott> swentel: then we fix it and suddenly the site has changed
<swentel> alexpott, fair point
<swentel> alexpott, although usage of the field will be pratically zero
<swentel> but oh well
<swentel> and who on earth made that setting, it's useless too :(
<alexpott> swentel: :)
<alexpott> swentel: existing sites are a pain-in-the-...
<swentel> alexpott, k, so, keep the wrapper as BC, and an update hook then to remove the link to content ?
<swentel> alexpott, in case they checked it
<alexpott> swentel: I think so - so fix the bug but don't change existing sites.
<swentel> alexpott, works for me, pasting this in the issue ok ?
<swentel> alexpott, oh, you say 8.1.x - do we only do update hooks in minor release, no patch ?
<alexpott> swentel: unless absolutely necessary yes
Gábor Hojtsy’s picture

Looking at LanguageFormatter::viewValue() it just inherits entity linking from StringFormatter, its parent. Maybe it was a bad idea to inherit from that... A more unique setting for language formatters is whether to display with native name.

johnv’s picture

For the languagefield formatter, I copied the setting from Core language, and indeed, subclassing String introduces a content link. Which is a 'feature' for my use case. However, is this also the case for core language? It will always point to itself.
Perhaps when building Views showing all translations....

Gábor Hojtsy’s picture

Right, if you are creating view with the languages as links to the translations, eg. a custom language selector block on an entity page with only the available translations listed.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Gábor Hojtsy’s picture

Issue tags: -sprint

Removing from sprint so it reflects what is currently being worked on.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

xjm’s picture

Component: field system » node system
Priority: Major » Normal

The core committers and entity system maintainers agreed this issue can be handled as normal priority. (Criteria for major bugs: https://www.drupal.org/core/issue-priority#major-bug). Thanks everyone!

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

matsbla’s picture

Issue summary: View changes

I also think it would be great to have a formatter that simply display the source language of the content!

What is left to do on this issue? I tried update issue summary.

andrey.troeglazov’s picture

Hi all,
I`ve rerolled the patch for 8.4 branch and fixed some coding standard issues.

tstoeckler’s picture

+++ b/core/modules/node/tests/src/Functional/NodeTypeInitialLanguageTest.php
@@ -117,10 +114,17 @@ public function testLanguageFieldVisibility() {
+    $this->DrupalPostForm(NULL, [], "langcode_settings_edit");
...
+    $this->DrupalPostForm(NULL, $edit, "langcode_plugin_settings_update");

This should be a lowercase "d" in "drupal".

andrey.troeglazov’s picture

Thank you @tstoeckler, my bad.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

matsbla’s picture

Priority: Normal » Major

The patch in #28 is working for me!

When I apply this patch finally this module is working;
https://www.drupal.org/project/flags
I also try make a another project for different language display formatters, but it is also not working without this patch;
https://www.drupal.org/sandbox/matsbla/2901140

Is there anyway to work around this bug?

To me it seems like there is no work-around on this issue so I put back to major according to "Priority levels of issues" (Block contributed projects with no workaround.)

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

voleger’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll
yogeshmpawar’s picture

Assigned: Unassigned » yogeshmpawar
yogeshmpawar’s picture

Assigned: yogeshmpawar » Unassigned
Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
2.73 KB

Re-rolled the #28 patch against 8.6.x branch.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

sealionking’s picture

how about a patch for 8.5?

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

rp7’s picture

Status: Needs review » Needs work
mrinalini9’s picture

Fixed test case failure issue in #40, please review.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

rp7’s picture

Made a small mistake in the previous patch. Another attempt.

Berdir’s picture

This does make sense, BC as always is tricky. Render array changes are allowed. But what about template placeholders/customizations?

We should create a change record at least to explain the structure change.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

jidrone’s picture

Priority: Major » Normal
Status: Needs review » Needs work
Issue tags: +Bug Smash Initiative

Steps to reproduce are clear so I performed to following manual test:

  • Tested patch #46 on 9.5.0-dev and it worked as expected.
  • Tested patch #46 on 10.1.0-dev and it didn't work.

I guess just removing the hardcoded part is not enough on Drupal 10 versions, I didn't have the time to troubleshoot.

Would be nice to have it resolved, but based in the infrequent participation on this issue I would say this not a blocker issue for most of Drupal users so I'm changing the priority to normal.

Anchal_gupta’s picture

Rerolled Patch against 10.1x.

Anchal_gupta’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 52: 2637808-51.patch, failed testing. View results

jidrone’s picture

Status: Needs work » Needs review
FileSize
2.38 KB

I fixed the test.

Previously, I was testing with drupalpod and for some reason it was not working for D10, but after doing a manual test with a local environment I can confirm this patch also works for that version.

jidrone’s picture

Sorry, last patch had some issues.

andypost’s picture

jidrone’s picture

Status: Needs review » Needs work

I would say in this case a possible upgrade path could be to set existing language form display components to show the label and language as plain text.

What do you think?

andypost’s picture

Yes, so existing node displays will continue to work and new ones will get the same defaults as before

jidrone’s picture

Status: Needs work » Needs review
FileSize
4.11 KB

Added hook update on language module.

It only iterates through content types because the only entity type affected by this patch is node.

tobiasb’s picture

The inline comments (get ..., iterate) are a little bit to verbose. The update hook comment is enough for this function.
Just my 2cents. ;-)

jidrone’s picture

Uploading test only patch.

Status: Needs review » Needs work

The last submitted patch, 62: test-only.patch, failed testing. View results

acbramley’s picture

Status: Needs work » Needs review

Red/green as expected, @jidrone just a tip for next time if you upload the test only patch first it won't push the issue back to NW like it did here.

acbramley’s picture

Status: Needs review » Needs work

Minor review changes:

  1. +++ b/core/modules/node/tests/src/Functional/NodeTypeInitialLanguageTest.php
    @@ -136,7 +136,17 @@ class NodeTypeInitialLanguageTest extends NodeTestBase {
    +    $this->submitForm([], t('Save'));
    

    We shouldn't wrap test strings in t()

  2. +++ b/core/modules/node/tests/src/Functional/NodeTypeInitialLanguageTest.php
    @@ -136,7 +136,17 @@ class NodeTypeInitialLanguageTest extends NodeTestBase {
    +    $this->assertSession()->linkExists('English', 0);
    

    We don't need the second parameter here.

Also not sure if we need an update test?

Anchal_gupta’s picture

I have uploaded the patch
Addressed #65 both points.

Anchal_gupta’s picture

Status: Needs work » Needs review
ameymudras’s picture

Fixing custom command failure and some comment typos

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

@Anchal_gupta you can test your patch before uploading using the core scripts.

Looks good to me and the points in #65 appear to be addressed.

larowlan’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs change record, +Needs release note
  1. +++ b/core/modules/language/language.install
    @@ -11,3 +11,38 @@
    +function language_update_10100() {
    +  $entity_display_repository = \Drupal::service('entity_display.repository');
    +  $entity_view_display = \Drupal::entityTypeManager()->getStorage('entity_view_display');
    +  $entity_type_id = 'node';
    +  // Get all content types.
    +  $content_types = \Drupal::entityTypeManager()
    +    ->getStorage('node_type')
    +    ->loadMultiple();
    +  // Iterate through content types.
    

    This needs to be a post update hook, we can't rely on the entity API to be available/error proof in an update hook.

  2. +++ b/core/modules/language/language.install
    @@ -11,3 +11,38 @@
    +    $view_modes = $entity_display_repository->getViewModeOptionsByBundle($entity_type_id, $content_type_id);
    +    foreach ($view_modes as $view_mode => $view_mode_info) {
    +      /** @var \Drupal\Core\Entity\Display\EntityViewDisplayInterface $view_display */
    +      $view_display = $entity_view_display->load("$entity_type_id.$content_type_id.$view_mode");
    +      if ($view_display) {
    +        if ($langcode = $view_display->getComponent('langcode')) {
    

    Let's use the config entity updater here

  3. +++ b/core/modules/language/language.install
    @@ -11,3 +11,38 @@
    +          $langcode['label'] = 'above';
    

    Note to other reviewers, this is correct, in HEAD even if you set it to hidden the title still displays

jidrone’s picture

Status: Needs work » Needs review
FileSize
4.17 KB
7.57 KB

Changed hook update to post update as suggested, and also using config entity updater.

Thanks @larowlan.

jidrone’s picture

FileSize
4.23 KB
3.02 KB

Sorry, last patch had some paths wrong.

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Tests are all green
Patch applies cleanly
Running tests without the fix fail as expected
Update runs without issue
Code looks clean to me.

But will still need a change record

larowlan’s picture

Status: Reviewed & tested by the community » Needs review

Can we get a change record/release note here? Fine to self RTBC after adding

smustgrave’s picture

Issue tags: -Needs change record

Took a shot at the change record. Mostly borrowed from the issue summary since the IS was so well done.

Not sure what's needed for a release note.

jidrone’s picture

I did some changes to the change record to make it more clear.

smustgrave’s picture

Thanks! So can this go back to RTBC

xjm’s picture

We still need a release note, though. (Ideally, the release note will link the change record.)

tobiasb’s picture

Issue summary: View changes
Issue tags: -Needs release note

Done.

andypost’s picture

+++ b/core/modules/language/language.post_update.php
@@ -13,3 +16,32 @@ function language_removed_post_updates() {
+function language_post_update_language_component_plain_text(&$sandbox = []) {
...
+    // Update language component if present.
+    if ($view_display->getComponent('langcode')) {
...
+      $langcode['label'] = 'above';
...
+      $langcode['settings'] = [
+        'link_to_entity' => FALSE,
+        'native_language' => FALSE,
+      ];
+      $view_display->setComponent('langcode', $langcode);

it needs upgrade path test

jidrone’s picture

Status: Needs work » Needs review
FileSize
8.47 KB
3.42 KB

Added test for the post_update.

jidrone’s picture

Git was recognizing one file as binary when it generates the patch, but I found a workaround.

jidrone’s picture

FileSize
29.43 KB
841 bytes

Fixed CS error.

jidrone’s picture

Those dump files for update tests produce a lot of weird errors, hopefully I fixed all.

jidrone’s picture

FileSize
29.4 KB
2.58 KB

Maybe disabling the Spell check on some config imports.

Interdiff agains 83 because 84 didn't improve the issue.

smustgrave’s picture

+1 for me but will let someone else see what they think.

rpayanm’s picture

Status: Needs review » Needs work

I tested manually the patch from #85.

Test #1
1. I used an empty Drupal 10.1.x
2. Applied the patch
3. Installed Drupal
4. Followed the patch from the IS

It worked as expected.

Test #2:
1. I used an empty Drupal 10.1.x
2. Installed Drupal
3. Followed the steps from IS
4. Applied the patch from the IS
5. Ran "drush updb".

It worked as expected, but I had to repeat the step 4: Check formatter option "Link to the Content", because it was unchecked after the update.

Let me know if I did something wrong.

jidrone’s picture

Status: Needs work » Needs review

Hi rpayanm,

That's the expected behavior after running the update, because it sets the formatter to match the hardcoded values to avoid unintended results on existing sites using that formatter.

rpayanm’s picture

Status: Needs review » Reviewed & tested by the community

Oh ok, thank you.

catch’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: -Needs upgrade path tests

#2226493: Apply formatters and widgets to Node base fields says it covered this, but looks like it didn't?

  1. +++ b/core/modules/language/language.post_update.php
    @@ -13,3 +16,32 @@ function language_removed_post_updates() {
    +
    +/**
    + * Set language form display component as plain text and with label above.
    + */
    +function language_post_update_language_component_plain_text(&$sandbox = []) {
    +  $config_entity_updater = \Drupal::classResolver(ConfigEntityUpdater::class);
    +
    +  $callback = function (EntityViewDisplayInterface $view_display) {
    +    // Only update node view modes.
    +    if ($view_display->getTargetEntityTypeId() !== 'node') {
    +      return FALSE;
    +    }
    +    // Update language component if present.
    +    if ($view_display->getComponent('langcode')) {
    +      // Set label above as it was.
    +      $langcode['label'] = 'above';
    +      // Set to show it as plain text.
    +      $langcode['settings'] = [
    +        'link_to_entity' => FALSE,
    +        'native_language' => FALSE,
    +      ];
    +      $view_display->setComponent('langcode', $langcode);
    +      return TRUE;
    +    }
    +    return FALSE;
    +  };
    +
    +  $config_entity_updater->update($sandbox, 'entity_view_display', $callback);
    

    The logic here also needs to run in config entity presave so that it's applied to configuration shipped with modules and install profiles. Quite a lot of examples of this in 9.5 and 10.1, especially but not exclusively in views.

  2. +++ b/core/modules/node/src/NodeViewBuilder.php
    @@ -41,16 +41,6 @@ public function buildComponents(array &$build, array $entities, array $displays,
     
    -      // Add Language field text element to node render array.
    -      if ($display->getComponent('langcode')) {
    -        $build[$id]['langcode'] = [
    -          '#type' => 'item',
    -          '#title' => t('Language'),
    -          '#markup' => $entity->language()->getName(),
    -          '#prefix' => '<div id="field-language-display">',
    -          '#suffix' => '</div>',
    -        ];
    -      }
         }
    

    Does the configured formatter end up in the same place in the render array?

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.