Problem/Motivation

It is too often too difficult to find out which array key has the error in a source plugin test. The expected arrays are very similar (for example, lots of keys with a value of 0 or 1), and the error messages, do not indicate in which array the error is occurring. Sure using the debugger or commenting out arrays will work but it would be a lot simpler if the test reported the array index.

Proposed resolution

Add a informative message to two assertions where this is most needed when looping through all the plugin rows.

Lately I have been using this and it had proven helpful.
sprintf("Value at 'array[%s][%s]' is not correct.", $i - 1, $key);

Remaining tasks

The usual.
Decide on the wording of the error message.

I was working on #2890690: MigrateLookup plugin has inconsistent return values. and discovered a usage of the deprecated plugin 'migration'. So looked for more:

$ grep -rw "plugin: migration" core/modules/*/migrations
core/modules/content_translation/migrations/d6_taxonomy_term_localized_translation.yml:    plugin: migration
core/modules/content_translation/migrations/d6_taxonomy_term_translation.yml:    plugin: migration
core/modules/content_translation/migrations/d6_taxonomy_term_translation.yml:      plugin: migration

They look familiar. And yes I worked on those issues and didn't update the migration, it must have been copy pasted a long time ago.
#2784371: Migrate D6 i18n taxonomy term language (but not yet translations)
#2886609: Migrate translations for D6 i18n taxonomy 'localized' terms

Attached is an untested fix

Currently, there is no migration path from https://www.drupal.org/project/picture to core's Responsive Image module.

Some jQuery UI widgets are missing dependencies and loaded more dependencies than its required.

#2906737: jQuery UI checkboxradio and selectmenu errors following 8.4 update to jQuery 1.12
#2925997: position-min.js issue since 8.4 upgrade

It's a critical bug IMO but I started with Major first. And let someone with higher power to make a good decision :p

** I coded a dirty script for this but then I realize it's not the CORE way to handle jQuery UI. So I open this issue and seek some feedback first. Take a look if you need it for the further patching:
https://gist.github.com/KayLeung/b6455829db44d51f31aff27f6408b891

Problem/Motivation

The date type element has #date_date_callback option which can be used to alter it.
But it doesn't work properly because of function_exists() function inside processDatetime method of Datetime element. It always returns FALSE for all callbacks added in the #date_date_callback option.

Proposed resolution

Repace function_exists() by call_user_func_array() to be able execute callback with context

Problem/Motivation

If you code a datetime element like

$form['datetime'] = [
  '#type' => 'datetime',
  '#title' => t('Downtime DateTime'),
];

You'll get a PHP warning.

Proposed resolution

Fix code so that #default_value is not expected to be set.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

This issue is a subtask to implement the new design of the media library #3019150: Update/improve mockups and designs for the media library.

Media types are related to media source plugins, and each media source contains a source field of a specific type. The source field input is used to uniquely identify the media item. The types of source input could be different for media sources. In core we currently have file based sources to allow adding new media via file uploads, but also the oembed source where users can add media via a URL.

There are a couple of issues we need to solve when users are trying to add new media:

• Since sources are plugins, contrib modules could get creative and add all kinds of source input field types (for example using an address field). How do we show all the source input fields?
• How do we help the user pick the right source field to add new media?
• Once the right input is given, it could resolve to multiple media types. How does the user pick the right media type?

Proposed resolution

While thinking about this problem, we assumed users know in advance what they are trying to add. They want to add a specific Youtube video, or upload some images from an event. If users pick a media type first, we automatically know which source field matches that media type.

1. The first step to help users add new media in an easy way is creating separate vertical tabs for each media type so they can easily pick the type of media they want to interact with.
2. If there is only 1 media type configured for a field, we hide the verticle tabs.
3. We allow the media types to be sorted per field (widget). For each field the user can specify in which order the tabs should be shown. The first tab opens automatically so users can directly add media of that specific type.
4. While selecting media in different tabs, the selection on other tabs should be remembered so the users can insert media from different tabs directly.

Current progress

There is a patch for the following changes:

1. Menu links as vertical tabs in the media library modal. The menu links are not shown when there is only 1 type configured for the field.
2. Type argument for the media library view so each vertical tab only shows media of the selected type.
3. Only show the 'Select media' button when there is actually something selected.
4. Show the number of selected items in the button pane.
5. Make sure the selection persists between tabs.
6. Make sure the selection is cleared when items are selected or the modal is closed.
7. Make sure media items are disabled for each tab when the maximum number of items for the field is selected.
8. Allow the media types to be sorted per widget, so the most important media type for the field is automatically selected when opening the media library.

Screenshots of the changes:

Before: Empty widget

After: Empty widget

Before: Modal without anything selected

After: Modal without anything selected

Before: Modal with items selected

After: Modal with items selected

Before: Modal with max. item selected

After: Modal with max. item selected

After: Selection persists in other tabs (new feature)

Before: Widget with selected items

After: Widget with selected items

After: Widget settings to sort vertical tabs style menu in modal (new feature)

Problem/Motivation

Cancelling changes in the Layout Builder UI immediately removes them with no confirmation.
This could be dangerous, especially since the link is directly next to the link to save changes.

Proposed resolution

Use a confirmation form

Remaining tasks

User interface changes

Yes

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Note on issue credits

At the end of this summary is a list of people who helped make this patch. They have not all commented on this issue, because the module was developed in a sandbox project. Please credit them. Thanks!

Problem/Motivation

In the Ideas queue, on #2592487: [meta] Help system overhaul, we proposed adding the currently-sandbox Help Topics module to Core as an Experimental module. Since that Ideas queue issue, our plan has evolved here on this issue. Our current patch adds the following functionality:

- Ability for modules, themes, and distributions to distribute arbitrary numbers of help topics (instead of just one and just for modules). This allows topics to be task-based and user-centered rather than organized by module.
- Topics are distributed as plugins. Each topic goes in its own YAML file, which contains the title of the topic and a few settings. The body goes in a corresponding Twig file.
- When topics are displayed, there is a list of "related topics" at the end. These links are generated from two sources. When displaying topic X, topic X's YAML can specify zero or more topics to include in the list. Also, topic Y can say in its YAML file that it wants to be listed in topic X's Related Topics section.
- Topics can be marked as "top-level" or not. The admin/help page lists top-level topics only (for less clutter); others are reached through links in text and the Related Topics section.

Complementary help systems

There are two existing help systems in Core that complement this proposed system, and will remain in place:

• hook_help() -- this allows modules to (a) add help to the Help block for particular routes/pages on the site and (b) create one Module Overview topic, which appears in the existing "Module Overviews" section of the admin/help page.
• Tour module -- this allows additional contextual help to be added to any page on the site, in the form of a tour, which can have multiple steps, each one describing part of a page (such as different form elements in an administrative form). Contrib modules like Tour UI allow non-programmers to create tours, and they are stored in configuration like the Help Topics of this proposal. Defined tours are also listed in the "Available Tours" section of the admin/help page.

Proposed resolution

a) Add the Help Topics module to Core, initially as a separate Experimental alpha module (this issue). [Alternatively, it may be added as part of the existing core Help module to start. The product managers need to decide this.]

b) Once this is in Core as an alpha experimental module, we'll open a Meta issue to get this to Beta quality (which will be necessary to keep it as a live Experimental module in a full Drupal release). Sub-issues that we currently have for that phase (which are currently filed against the Sandbox module, but will be moved to Core once we have the module in there and an issue component):
- #2664830: Add search capability
- Better test coverage: more unit tests, tests for the cache stuff, tests for translatability
- Enforcement of provider.string format for plugin IDs (in patch)
- Addition of ability to scan core for plugins (besides themes and modules) (in patch)
- Make sure that the topic title/label gets into localize.drupal.org as a translatable string.
- Make sure topic Twig files are being scanned by POTX so the topic text gets onto localize.drupal.org

c) To get this module to full release, we will additionally (probably?) need to do these tasks:
- Make it part of the existing core Help module instead of its own module. This will mean (besides moving the files around):
-- merging the hook_help() here into the existing hook_help()
-- adding to the drupal.org docs page for the existing Help module
-- changing namespaces of classes
-- changing function names of hook implementations
-- moving topics to their rightful places (provider directories instead of all inside the help module)
-- [TBD]
- #2687107: Write some core help topics
- #2994748: Make a way for Help Page Sections to be ordered
- The standard things done in Core to finalize a module, such as adding templates to the Stable/Classy themes, updating the module category in the .info.yml file, removing @internal tags, adding @api tags, etc., (Is there a standard procedure for this?)
- Figure out POTX (getting the translatable strings into localize.drupal.org). See:
https://cgit.drupalcode.org/potx/tree/yaml_translation_patterns.yml
It looks like we would need to add to that file so that within help topic YAML files, we would define which keys are translatable.

e) And there are a couple of issues that we may or may not eventually need to resolve:
- #2960220: Facilitate hierarchy and ordering of help topics

f) As a note, the Sandbox module where development was started for this project will probably be promoted to a contrib module, with some additional functionality around letting people define help topics for their site and storing them in config entities, and providing a UI that site builders can use to author this type of configurable help. But that is out of scope for this issue.

Remaining tasks (and how to help)

On this issue, the task is to get the patch approved for this to be an experimental module (see Proposed Resolution for list of issues to be resolved).

Testing notes: After applying this patch and installing the Help Topics (help_topics) module, you can go to
admin/help
and see the current (fairly small) list of top-level help topics (there's an issue about writing more: #2687107: Write some core help topics). Click on one, and you'll see related topics. Also, you can try out links within the text of some topics that will take you to related administrative pages, or to other help topics.

User interface changes

A new Experimental module providing plugin-based help topics is added, along with a few new help topics.

The only change to existing UIs is that this module adds a section to the admin/help page that lists the top-level topics.

API changes

No changes to existing APIs.

Defines a new plugin type (for the help topic).

Data model changes

No changes to existing data models. There is an implicit YAML schema for the plugins.

People to credit on this patch

This patch was made by the following people, who contributed patches/tests/reviews on either
#2351991: Add a config entity for a configurable, topic-based help system
or on various Sandbox module issues at https://www.drupal.org/project/issues/2369943, or at Usability group meetings, or here on this issue:
alexpott
amateescu
Amber Himes Matz
andypost
benjifisher
Berdir
catch
ckrina
dawehner
Fabianx
Gábor Hojtsy
Greg Boggs
gnuget
jhedstrom
jhodgdon
jibran
larowlan
MariaDenysyuk
miro_dietiker
Mixologic
sandboxpl
SenthilMohith
tim.plunkett
tstoeckler
vijaycs85
webchick
webflo
yo30
yoroy

Problem/Motivation

The current page count in views is incorrect when requesting a page that is past the page limit based on the number of items.

For example in a view the current page is handled as follows:
?page=0: current_page == 0 rendered as 'Page 1'
?page=1: current_page == 1 rendered as 'Page 2'
?page=2: current_page == 1 rendered as 'Page 2'
?page=3: current_page == 2 rendered as 'Page 3'

The behavior I would expect is that the current page increments sequentially from 0 in code and from 1 in the rendered output.

This is verified with the attached test SqlPagerBaseTest.php which currently fails.

Proposed Resolution

The problem appears to be here:

Drupal\views\Plugin\views\pager\SqlBase::updatePageInfo()

      // See if the requested page was within range:
      if ($this->current_page >= $pager_total[$this->options['id']]) {
        // Pages are numbered from 0 so if there are 10 pages, the last page is 9.
        $this->setCurrentPage($pager_total[$this->options['id']] - 1);
      }

Where the code is decrementing the current_page by one when out of range. However, the user-facing page count starting at 1 instead of 0 is already handled by the pager rendering. As far as I can tell this condition is not necessary and removing it causes this test case to succeed.

Perhaps there is some purpose for this that I'm not aware of but it does seem to be the culprit here.

Problem/Motivation

All implementations of TempStore provide a getMetadata() method which returns either NULL or a \stdClass with two properties: owner and updated.
It is tricky for consumers of this API to know what the properties are and what they represent.

Most commonly, the owner value is used to load a user and the updated property is used to format a date representing the time that has elapsed.

Proposed resolution

Provide a dedicated class to represent this information, with two helper methods that encompass the most common use cases.

Remaining tasks

User interface changes

N/A

API changes

BC layer provided. Deprecation errors will fire for code accessing the properties.

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

I applied the patch in #2952967: When allowing content items to have customized layouts, clicking 'Layout' on full view of a node takes you to the configuration for the 'default' view mode to my 8.5.0 project. Even with the patch applied, I was not able to view customized layouts on a per node basis.

Steps to reproduce:
- Enable the "full content" view mode for basic page
- Check "Allow each content item to have its layout customized."
- Create a new basic page
- Click "Layout" and add a block to the layout (I used the powered by Drupal block)
- Save the layout and view the node

I expected to see the customized layout with the new block added, but only the default layout appeared.

It appears that the allow_custom setting applies on a per-view mode basis. The third party settings config object for the view mode's layout_builder does not include that flag for any view mode configuration other than the default. LayoutBuilderEntityViewDisplay checks this value before it decides whether to return the section configuration from the view mode config or the customized layout stored with the node.

Proposed resolution

I updated the form method in LayoutBuilderEntityViewDisplayForm to include the layout options form elements for both "default" and "full" view modes and updated my view mode configuration. The customized layout was then used when viewing the node.

I am not sure this is the best solution as it appears that the layout stored with the node is not associated with a particular view mode so the updates would show for any view mode which can be customized. I think this can cause unexpected behavior as it is.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

This happens if you try to delete to delete the only pending revision of an entity that was created *before* enabling workflows, so the previous default revision didn't have a content_moderation entity.

Steps to reproduce:

1. Create an article.
2. Enable content_moderation, enable it for article
3. Create a draft
4. Delete that draft.
5. Boom.

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Core\Entity\EntityStorageException</em>: Default revision can not be deleted in <em class="placeholder">Drupal\Core\Entity\ContentEntityStorageBase-&gt;deleteRevision()</em> (line <em class="placeholder">677</em> of <em class="placeholder">core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php</em>). <pre class="backtrace">Drupal\content_moderation\EntityOperations-&gt;entityRevisionDelete(Object) (Line: 118)
content_moderation_entity_revision_delete(Object)
call_user_func_array(&#039;content_moderation_entity_revision_delete&#039;, Array) (Line: 403)
Drupal\Core\Extension\ModuleHandler-&gt;invokeAll(&#039;entity_revision_delete&#039;, Array) (Line: 206)
Drupal\Core\Entity\EntityStorageBase-&gt;invokeHook(&#039;revision_delete&#039;, Object) (Line: 756)
Drupal\Core\Entity\ContentEntityStorageBase-&gt;invokeHook(&#039;revision_delete&#039;, Object) (Line: 681)
Drupal\Core\Entity\ContentEntityStorageBase-&gt;deleteRevision(&#039;2&#039;) (Line: 117)
Drupal\node\Form\NodeRevisionDeleteForm-&gt;submitForm(Array, Object)

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Attempting to save a page in English (default language).

When I click to save it I get the following error:
The website encountered an unexpected error. Please try again later.Drupal\Core\Entity\EntityStorageException: A translation already exists for the specified language (en). in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 783 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Drupal\Core\Entity\Plugin\DataType\EntityAdapter->onChange('langcode') (Line: 77)
Drupal\Core\TypedData\Plugin\DataType\ItemList->setValue(Array, 1) (Line: 107)
Drupal\Core\Field\FieldItemList->setValue(Array) (Line: 1089)
Drupal\Core\Entity\ContentEntityBase->__set('langcode', 'en') (Line: 188)
Drupal\content_moderation\EntityOperations->updateOrCreateFromEntity(Object) (Line: 149)
Drupal\content_moderation\EntityOperations->entityUpdate(Object) (Line: 100)
content_moderation_entity_update(Object)
call_user_func_array('content_moderation_entity_update', Array) (Line: 403)
Drupal\Core\Extension\ModuleHandler->invokeAll('entity_update', Array) (Line: 206)
Drupal\Core\Entity\EntityStorageBase->invokeHook('update', Object) (Line: 756)
Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('update', Object) (Line: 507)
Drupal\Core\Entity\EntityStorageBase->doPostSave(Object, 1) (Line: 641)
Drupal\Core\Entity\ContentEntityStorageBase->doPostSave(Object, 1) (Line: 432)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 774)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 390)
Drupal\Core\Entity\Entity->save() (Line: 281)
Drupal\node\NodeForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 589)
Drupal\Core\Form\FormBuilder->processForm('node_landing_page_edit_form', Array, Object) (Line: 318)
Drupal\Core\Form\FormBuilder->buildForm('node_landing_page_edit_form', Object) (Line: 93)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 38)
Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 669)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I expect it to save the node.

The code in taxonomy_term_save does not check to see if the parent variable is not null before it tries to insert data into taxonomy_term_hierarchy. We should check that the parent tid is not null first.

This bug is difficult to reproduce. It occurs SOMETIMES when saving a taxonomy term using the taxonomy_manager module. I chose a taxonomy term on the root level and clicked save. The following error appears. After closing the pop up, the term no longer appears in the taxonomy manager because its taxonomy_term_hierarchy record was deleted.

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /system/ajax
StatusText: Service unavailable (with message)
ResponseText: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'parent' cannot be null: INSERT INTO {taxonomy_term_hierarchy} (tid, parent) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1); Array
(
[:db_insert_placeholder_0] => 15152
[:db_insert_placeholder_1] =>
)
in taxonomy_term_save() (line 679 of .../modules/taxonomy/taxonomy.module)

Steps to reproduce:

1. Make a content type translatable, select "Hide non translatable fields on translation forms" and make the image file in a translatable field non-translatable:
2. Translate a node and try remove the image, and upload a new one.
3. Result: You get a form validation error "Non-translatable field elements can only be changed when updating the original language. "

But if the image can't be changed in the form, why is there a "Remove" button at the image field at all?

Suggested solution:
When "Hide non translatable fields on translation forms" is selected, make it not possible to remove/upload new non-translatable images in the translation form.

I translated two nodes, when I change the state to draft the revision is being created correctly, but when I tried to edit the other translation of the same node, I saw that the translation has the same moderation state even if I haven't edited this translation.

Steps to reproduce it:

1. Create two or more nodes
2. Install content_moderation and workflows
3. Install config_translation, content_translation and locale
4. Add either a custom or default language, in my case I added en-mx and es-mx.
5. Go to language content settings page and check all the content types
6. Go to workflow settings page and apply the default workflow to all the content types
7. Go to content and translate one of the nodes
8. Edit one of the translations, in my case I change the state to draft in the es-mx node.
9. Go to en-mx and you will see the draft state even if this translation was not edited.

In order to solve my issue I added a condition to find the correct revision by language, it's working on my end but I would like to know if someone is having the same issue.

any thoughts?

There are basically two problems with the 8.5.8 and 8.6.2 security changes to Content Moderation:

1. They introduce a new method to an existing interface. There is at least 1 contributed module that I know of that has an implementation of this interface -- Workflow Participants -- and another one that has an issue to include it -- Group. Any site that attempts to take the security update while one of these is enabled will encounter immediate, site-wide fatal errors due to the missing method implementation.
2. They don't provide sufficient information for existing use cases. Both of those contributed modules require the context of the actual content entity in order to determine if a transition is valid, but the new method that was introduced doesn't offer that information. As a result, neither of these modules can even implement the new method properly.

Possible solutions

1. Remove the new method from the interface. There is already a getValidTransitions() method on the interface. The constraint validator can simply get all the valid transitions and then check if the new state is among them. Slightly less efficient, but no API change and no compatibility issues.
2. Adjust the method arguments from "Workflow/Current state/New state/User" to just "Entity/New state/User". (Both the workflow and the current state can be derived from the entity.) Adjust the implementation of Content Moderation's implementation accordingly.
3. Introduce the content entity as an optional 5th argument to the method, making note that it will end up being required in a future version of Drupal.

Based on discussion, option #3 is the route that best complies with Drupal policies around API changes, so that is what has been chosen.

Problem/Motivation

While trying to invent a new and better way to have extra fields on our entities, I ended up defining configurable fields with the custom_storage flag on. The thing is that I can easily edit these fields but when I try to delete them, I get a SqlContentEntityStorageException because the ContentEntityStorageBase does not check for this flag before trying to purge content.

Drupal\Core\Entity\Sql\SqlContentEntityStorageException: Column information not available for the 'field_qsdfsqdf' field. in Drupal\Core\Entity\Sql\DefaultTableMapping->getFieldColumnName() (line 215 of core/lib/Drupal/Core/Entity/Sql/DefaultTableMapping.php).

Drupal\Core\Entity\Sql\SqlContentEntityStorage->readFieldItemsToPurge(Object, 10) (Line: 175)
Drupal\Core\Entity\ContentEntityStorageBase->purgeFieldData(Object, 10) (Line: 96)
field_purge_batch(10) (Line: 113)
Drupal\field_ui\Form\FieldConfigDeleteForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 583)
Drupal\Core\Form\FormBuilder->processForm('field_config_delete_form', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 139)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 62)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 649)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Proposed resolution

Check if the field has the custom_storage flag set before trying to purge data from it.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

Currently we add a base field to entity types and then hide the moderation_state widget if the specific entity we are editing isn't being moderated. Some bundles may have moderation switched off. The way we do this is with a check in our widget, but this doesn't protect other widgets and can cause a fatal with the following steps:

1. drush si standard && drush en content_moderation
2. Edit the Article form display, change the widget to "Textfield".
3. Save any article, see a fatal.

Proposed resolution

Use field access for controlling if the field should appear or not.

Remaining tasks

User interface changes

API changes

Data model changes