Make it possible to configure the output of a boolean field on the formatter level

Would it be a problem to add these options to the standard boolean field formatter, or to define additional Formatter classes for Boolean fields with these options available?

OK... I looked at what Views gives me now (without any patches) to configure the "Published" field in a node view, and as you say there is also the option "custom", which is basically to provide a value to display for true and a value to display for false. Is there a reason we can't add this option too? It doesn't seem all that complicated, and would require just two more settings strings for the labels.

Ups, I simply mixed up true and false :)

:D

1. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/BooleanFormatter.php
   @@ -26,11 +27,98 @@ class BooleanFormatter extends FormatterBase {
   +    // Fallback to field settings by default.
   

   s/Fallback/Fall back/

2. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/BooleanFormatter.php
   @@ -26,11 +27,98 @@ class BooleanFormatter extends FormatterBase {
   +   *   A list of output formats. Each entry is keyed by the machine name of the
   +   *   format. The value is an array, of which the first item is the result for
   +   *   boolean TRUE, the second is for boolean FALSE.
   ...
   +      'custom' => [$this->t('Custom')],
   

   The array structure is not followed by this last one. I understand why; but wouldn't it be better to list an empty array in this case, and explicitly document it; referring to the associated settings?

3. +++ b/core/modules/field/src/Tests/Boolean/BooleanFormatterTest.php
   @@ -0,0 +1,144 @@
   +namespace Drupal\field\Tests\Boolean;
   +use Drupal\Component\Utility\Unicode;
   

   I think we usually have a blank line between these?

4. +++ b/core/modules/field/src/Tests/Boolean/BooleanFormatterTest.php
   @@ -0,0 +1,144 @@
   +    // Configure the theme system.
   +    $this->installConfig(['field']);
   +    $this->installEntitySchema('entity_test');
   

   Comment doesn't match what happens.

5. +++ b/core/modules/field/src/Tests/Boolean/BooleanFormatterTest.php
   @@ -0,0 +1,144 @@
   \ No newline at end of file
   

   .

Probably also needs the beta evaluation in the IS.

Ah, yes, now I understand; I didn't realize you were exploiting the behavior of implode(' /', $array) with $array a single-valued array.

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/BooleanFormatter.php
@@ -41,10 +41,11 @@ public static function defaultSettings() {
-   * @return array
+   * @return array|string
    *   A list of output formats. Each entry is keyed by the machine name of the
    *   format. The value is an array, of which the first item is the result for
-   *   boolean TRUE, the second is for boolean FALSE.
+   *   boolean TRUE, the second is for boolean FALSE. The value can be also an
+   *   array, but this is just the case for the custom format.
    */
   protected function getOutputFormats() {
     $formats = [
@@ -55,7 +56,7 @@ protected function getOutputFormats() {

@@ -55,7 +56,7 @@ protected function getOutputFormats() {
       'enabled-disabled' => [$this->t('Enabled'), $this->t('Disabled')],
       'boolean' => [1, 0],
       'unicode-yes-no' => ['✔', '✖'],
-      'custom' => [$this->t('Custom')],
+      'custom' => $this->t('Custom'),

I wonder if this is really better.

Since this is protected anyway; why not only list "actual" formats here, and just append the 'custom' one in ::settingsForm(). Then all data returned by ::getOutputFormats() would be of the same form!

Other than that, this looks ready to me :)

Ok; that detail is not important enough to debate further. Let's do it.

The beta evaluation lacks details about exactly what regression this is fixing.

Um. The issue summary is making two references that should be to other issues but are pointing back to this issue... not sure which issue should be pointed to or I'd fix it (I keep getting confused about which issue is doing what lately on the Views stuff).

Updated issue summary with correct links, more details. This issue is currently rolled into the core critical #2342045: Standard views base fields need to use same rendering as Field UI fields, for formatting, access checking, and translation consistency, so marking it a blocker as well.

This is part of making views use field formatters and not regress. Thanks for adding the beta evaluation to the issue summary.

Committed d2ff08e and pushed to 8.0.x. Thanks!

Follow-up if anyone wants to take a look at this:
#2428087: Boolean field formatter - default choice appears in list twice