I was working on something here, on June 3. Need to figure out again what...

I was working on something here, on June 3. Need to figure out again what these README changes apply to.

README.md

@@ -118,15 +118,23 @@ the parent custom element.
 ### Custom element displays
 
 The default processor that renders a whole entity, makes use of "Custom element
-displays". When the `custom_elements_ui` module is enabled, these can be
-configured next to the "Manage display" option for Drupal's regular displays
-for entity bundles / view modes. There are some subtleties in when/how these
-displays are applied, when an entity is being rendered:
+displays". When the `custom_elements_ui` module is enabled, a "Manage custom
+element" tab is available to the "Manage display" tab on any management screen
+for entity types/bundles. There are some subtleties in when/how these displays
+are applied, when an entity is being rendered:
 
-* If an entity is rendered by Drupal's standard pipeline (e.g. as part of a
-  list of node teasers), custom elements only becomes active if Drupal's
-  regular display for the specified (or default) view mode has the "Force
-  rendering as custom element" enabled.
+*
+If an entity is rendered by Drupal's standard pipeline (e.g. as part of a list
+of node teasers), custom elements only becomes active if Drupal's regular
+display for the specified (or default) view mode has the "Force rendering as
+custom element" enabled.
+
+Many users of this module never need this option, because
+
+TODO move the above part to above (it can be separated out)
+
+TODO merge the below part into the above section that @fago wrote later? It
+     feels duplicate now. Also, re-check it.
 
 * When not using layout builder, custom elements renders a certain entity using
   a display specific to the entity type/bundle, similarly to Drupal's standard
@@ -144,6 +152,8 @@ displays are applied, when an entity is being rendered:
   * When no custom element entity-display config is available, a config with
     reasonable defaults is auto-generated and applied.
 
+### Caveat
+
 ## Upgrade from 2.x
 
 ### Preparation
@@ -158,6 +168,15 @@ because of their very small install base.)
   configuration: in each applicable
   core.entity_view_display.TYPE.BUNDLE.VIEWMODE configuration entity, set
   third_party_settings.custom_elements.enabled = true.)
+* custom_elements_thunder:
+  It's been decided to ship v3 without any of the processors that were present
+  in this submodule. All these processors applied to a content type or
+  paragraph type; it should be possible to replace these with Custom
+  Elements Displays that are now shipped with the module. The output is not
+  always 100% the same, but it should be close enough that it should be easy
+  to update your frontend (if even needed) to accommodate some renamed
+  properties. If you really need to keep the processors, check
+  https://www.drupal.org/i/3443424.
 
 * custom_elements_thunder:
   It's been decided to ship 3.x without any of the processors that were present
@@ -174,6 +193,20 @@ desired, regular displays can be still used by enabling "forceAutoProcessing"
 in the respective entity-ce-display. That way, the automatic-rendering via
 processors is applied again as it was default in 2.x.
 
+### Caveat / edge case: disabled view modes
+
+It is technically possible to 'build' (using processors in 2.x) content using
+a view mode that does not exist - or at least, one that is not enabled. If you
+are doing this _and_ your default view mode is set up to use Layout Builder,
+then v3 will render content in not-enabled view modes using Custom Elements +
+Layout Builder, instead of just Custom Elements (i.e. take the processor with
+the highest priority for the entity) like 2.x did.
+
+The only way around this is to create/enable (core's view) Display Modes for
+the applicable bundles + view modes, which have Layout Builder disabled. Then
+also create a Custom Element display (and configure it, or set it to fall back
+to 2.x behavior).
+
 ## Credits
 
   - [drunomics GmbH](https://www.drupal.org/drunomics): Concept, Development, Maintenance

src/CustomElementsFieldFormatterBase.php

@@ -67,7 +67,11 @@ abstract class CustomElementsFieldFormatterBase extends PluginBase implements Cu
   }
 
   /**
-   * {@inheritdoc}
+   * Sets the configuration for this plugin instance.
+   *
+   * @param array $configuration
+   *   An associative array containing the plugin's configuration, that must
+   *   contain at least 'name', 'view_mode' and 'field_definition'.
    */
   public function setConfiguration(array $configuration) {
     $this->configuration = $configuration + $this->defaultConfiguration();

src/Plugin/CustomElementsFieldFormatter/LinkCeFieldFormatter.php

@@ -31,7 +31,7 @@ class LinkCeFieldFormatter extends RawCeFieldFormatter {
     foreach ($items as $field_item) {
       // This should always be true; see field_types.
       if ($field_item instanceof LinkItemInterface) {
-        // Build URL, instead of sending only its components. It very likely
+        // Build URL, instead of sending only its components. It's very likely
         // that these components are 'uri' and 'options', and the client
         // doesn't want to receive those too. (It would just create confusion.)
         $field_item_value = $this->getFieldItemProperties($field_item, ['uri', 'options']);

src/Processor/DefaultContentEntityProcessor.php

@@ -10,7 +10,13 @@ use Drupal\custom_elements\CustomElementsBlockRenderHelperTrait;
 use Drupal\custom_elements\CustomElementsProcessorFieldUtilsTrait;
 
 /**
- * Default processor for content entities.
+ * Default processor for content entities using Core's entity display.
+ *
+ * Since v3, this is not the default behavior for generating a custom element
+ * from a content entity; it's the default fallback when "automatic processing"
+ * is enabled in a Custom Elements Display configuration.
+ *
+ * @see \Drupal\custom_elements\CustomElementGenerator::generate()
  */
 class DefaultContentEntityProcessor implements CustomElementProcessorWithKeyInterface {