Problem/Motivation

When responding to a GET request for a comment entity with a parent comment Drupal detects leaked cache metadata. Causing the following error:

The controller result claims to be providing relevant cache metadata, but leaked metadata was detected. Please ensure you are not rendering content too early. Returned object class: Drupal\\jsonapi\\ResourceResponse.

This is caused by the rdf module in core/modules/rdf/rdf.module:L244-246:

if ($comment->hasParentComment()) {
  $comment->rdf_data['pid_uri'] = $comment->getParentComment()->toUrl()->toString();
}

The lines above it have already been corrected in #2631774: Impossible to update Comment entity with REST (HTTP PATCH): bundle field not allowed to be updated, but EntityNormalizer::denormalize() requires it to:

// The current function is a storage level hook, so avoid to bubble
// bubbleable metadata, because it can be outside of a render context.
$comment->rdf_data['entity_uri'] = $entity->toUrl()->toString(TRUE)->getGeneratedUrl();

Presumably, this was simply overlooked and the same error is also present in the REST module.

Proposed resolution

Use the same fix as #2631774 did for the remaining lines in rdf_comment_storage_load.

Remaining tasks

Regression test
Patch
Review
Commit

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

75/75 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

------ ------------------------------------------------
Line config.module
------ ------------------------------------------------
66 Call to deprecated function file_uri_scheme().
------ ------------------------------------------------

------ ----------------------------------------------
Line tests/config_test/src/ConfigTestForm.php
------ ----------------------------------------------
141 Call to deprecated function format_string().
144 Call to deprecated function format_string().
------ ----------------------------------------------

------ ------------------------------------------------------------
Line tests/src/Functional/ConfigEntityListMultilingualTest.php
------ ------------------------------------------------------------
28 Call to deprecated method entityManager() of class Drupal.
------ ------------------------------------------------------------

------ ------------------------------------------------------------
Line tests/src/Functional/ConfigEntityListTest.php
------ ------------------------------------------------------------
33 Call to deprecated method entityManager() of class Drupal.
41 Call to deprecated method entityManager() of class Drupal.
255 Call to deprecated method entityManager() of class Drupal.
------ ------------------------------------------------------------

------ ----------------------------------------------
Line tests/src/Functional/ConfigEntityTest.php
------ ----------------------------------------------
241 Call to deprecated function format_string().
242 Call to deprecated function format_string().
243 Call to deprecated function format_string().
314 Call to deprecated function format_string().
------ ----------------------------------------------

------ ----------------------------------------------
Line tests/src/Functional/ConfigImportUITest.php
------ ----------------------------------------------
295 Call to deprecated function format_string().
456 Call to deprecated function format_string().
457 Call to deprecated function format_string().
458 Call to deprecated function format_string().
459 Call to deprecated function format_string().
460 Call to deprecated function format_string().
468 Call to deprecated function format_string().
469 Call to deprecated function format_string().
470 Call to deprecated function format_string().
471 Call to deprecated function format_string().
472 Call to deprecated function format_string().
479 Call to deprecated function format_string().
480 Call to deprecated function format_string().
481 Call to deprecated function format_string().
482 Call to deprecated function format_string().
483 Call to deprecated function format_string().
------ ----------------------------------------------

------ ------------------------------------------------------------
Line tests/src/Functional/ConfigInstallProfileOverrideTest.php
------ ------------------------------------------------------------
97 Call to deprecated method entityManager() of class Drupal.
118 Call to deprecated method entityManager() of class Drupal.
------ ------------------------------------------------------------

------ ------------------------------------------------------------
Line tests/src/Functional/ConfigSingleImportExportTest.php
------ ------------------------------------------------------------
39 Call to deprecated method entityManager() of class Drupal.
257 Call to deprecated method entityManager() of class Drupal.
------ ------------------------------------------------------------

[ERROR] Found 31 errors

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.

i got a warning in my Drupal 8.3.2 installation:

Warning: call_user_func() expects parameter 1 to be a valid callback, class 'Drupal df\CommonDataConverter' not found in rdf_rdfa_attributes() (line 189 of core/modules/rdf/rdf.module).

rdf_rdfa_attributes(Array, Array) (Line: 219)
rdf_entity_prepare_view('node', Array, Array, 'full')
call_user_func_array('rdf_entity_prepare_view', Array) (Line: 402)
Drupal\Core\Extension\ModuleHandler->invokeAll('entity_prepare_view', Array) (Line: 316)
Drupal\Core\Entity\EntityViewBuilder->buildComponents(Array, Array, Array, 'full') (Line: 24)
Drupal\node\NodeViewBuilder->buildComponents(Array, Array, Array, 'full') (Line: 263)
Drupal\Core\Entity\EntityViewBuilder->buildMultiple(Array) (Line: 220)
Drupal\Core\Entity\EntityViewBuilder->build(Array)
call_user_func(Array, Array) (Line: 376)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 149)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
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: 207)
Drupal\page_cache\StackMiddleware\PageCache->fetch(Object, 1, 1) (Line: 121)
Drupal\page_cache\StackMiddleware\PageCache->lookup(Object, 1, 1) (Line: 75)
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: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Does anyone know what causes this?

Thank you.

https://ibb.co/kLa2Av

Problem/Motivation

This is a sister issue of #2517030: Add a URL formatter for the image field and #2825487: Fix normalization of File entities: file entities should expose the file URL as a computed property on the 'uri' base field. The former issue solved it for image entities exposed via Views REST export displays. This issue must solve it at the serialization/normalization level, so that all REST resources (as well as JSON API) benefit.

The latter issue already is doing it for FileItem (and hence ImageItem because it extends FileItem), but only for the "canonical" file URL. In the case of ImageItem, we also want image style URLs.

Proposed resolution

Add ImageItemNormalizer.

Remaining tasks

None.

User interface changes

None.

API changes

Adds an API to allow explicit bubbling of cacheability metadata: pass in a 'cacheability' => instanceof CacheableMetadata key-value pair in the serialization context.

(The ImageItem normalizer that we add here uses this to its advantage: this new capability allows that normalizer to be properly unit-testable. No more global state manipulation! See #67's interdiff.)

Data model changes

None.

Problem/Motivation

Right now users can use route:<nolink> in order to create no-link links (see #2693725: Add <nolink> to allow for non-link links )

Proposed resolution

This issue tries to improve the UX allowing the user to enter into LinkWidget (URI) either <nolink><none> to create no-link links.

As <front> is special cased, so should be these.

Remaining tasks

1. Work on a patch
2. Adding test coverage
3. Cover <current> case as well (see #29 (split into #3015319: [PP-1] Add support for <current> to the LinkWidget UI
4. Update "User interface changes" IS section when point task above is done, if needed. (not needed)

User interface changes

The LinkWidget description for "generic" and "internal" now mentions the possibility of using <nolink> to create no-linklinks.

API changes

None.

Data model changes

None

I have a main menu with 2 levels. If menu item on the first level doesn't have "Show as expanded" checkbox checked submenu items shouldn't be shown. This works fine only when this menu item parent is not active.
Let say that I have a menu structure like this:
- menu1
-- submenu1
-menu2
-- submenu2

If menu1 has "Show as expanded" unchecked and we are on the menu2 page, then submenu1 menu item will not be shown. But if we open the menu1 menu item, the submenu1 menu item is also shown, but it shouldn't be.

Notice: Undefined index: name in system_requirements() (line 43 of core/modules/system/system.install).

system_requirements('runtime')
call_user_func_array('system_requirements', Array) (Line: 393)
Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array) (Line: 116)
Drupal\system\SystemManager->listRequirements() (Line: 100)
Drupal\system\SystemManager->checkRequirements() (Line: 119)
Drupal\system\Controller\SystemController->overview('system.admin_config')
call_user_func_array(Array, Array) (Line: 128)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 577)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 129)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 102)
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: 62)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 103)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 55)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 55)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 637)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Problem/Motivation

Content Moderation disallows edit access to entities based on whether a user can use any transitions for the entities current state. It would be nice to be able to replicate that in views, so that a view can display only those entities that a user can edit.

Proposed resolution

1: Set a setting in the settings form.
2: If that setting is true, then filter the states before the query condition is created.

Menu link 'view' permission is set to 'Administer Menu' which does not allow for exposing menu links via the jsonapi module (e.g. /jsonapi/menu_link_content/menu_link_content). Should permission instead be granted to access those links based on ability to access the linked resources?

Problem/Motivation

Anonymous users cannot start Tours. Currently Tours can only be started by clicking a button in the toolbar, and typically anonymous users have no permission to access the toolbar.

Proposed resolution

Provide a block with a button to start a Tour. This block can then be freely placed anywhere in the website.

How to test

1. Grant permission to access tours and the views UI (lol) to the authenticated and/or anonymous user role.
2. Place the block in the sidebar.
3. Log in as a test user and visit admin/structure/views.
4. Click on a view to access it.
5. Click the tour button in the sidebar.
6. Or visit ie http://drupal.d8/admin/structure/views/view/frontpage?tour=1 (as both authenticated or anonymous

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Original report by clemens.tolboom

As the tour icon is only available on the Toolbar anonymous users must get access to the Tour icon.

Without the 'Use the administration toolbar' the tour code is not loaded on the page so even an auto start like http://drupal.d8/?tour=1 fails.

Having the toolbar enabled the user get an access denied for the 'Menu' button.

Currently, the Path module only add the "URL alias" field to nodes, taxonomy terms and medias:

/**
 * Implements hook_entity_base_field_info().
 */
function path_entity_base_field_info(EntityTypeInterface $entity_type) {
  if (in_array($entity_type->id(), ['taxonomy_term', 'node', 'media'], TRUE)) {
    $fields['path'] = BaseFieldDefinition::create('path')
      ->setLabel(t('URL alias'))
      ->setTranslatable(TRUE)
      ->setDisplayOptions('form', [
        'type' => 'path',
        'weight' => 30,
      ])
      ->setDisplayConfigurable('form', TRUE)
      ->setComputed(TRUE);

    return $fields;
  }
}

User entities can't benefit from it, although it is a very common use case to have URL aliases for user profiles pages, and every other custom entities don't benefit from it either. Granted this can be set from the "Configuration > URL aliases" form but from an UX point of view, this is not convenient and inconsistent with nodes, terms and medias. Plus, it is very debatable why those three entity types benefit from a special treatment - why these three ones?

I propose to enable that field on any entity that is declared as needing it.

I see two ways to implement that:

* Either by adding a key to EntityType annotation analoguous to what "field_ui_base_route" does, that would be checked by the path module to know if it needs to add the field or not;
* Either by adding a configuration form to the path module that allows to explicitely select the entities that will have that field added to their edit form.

More generally, the more I use custom entities and the more I feel sad that they are considered as second class citizens compared to core provided entities.

Problem/Motivation

From #2983179-16: [META] Implement stricter access checking for the media library:

Secondly, as @marcoscano points out, a permission might be too blunt of an instrument for controlling access to the media library, simply because it can potentially be used in a bunch of different places and in different ways. With a permission, a site builder would need to grant at least two permissions to authors in order to allow them to use the media library at all -- they'd need the "view media" permission, and permission to access the media reference field at all. That's a big fat DrupalWTF that we should do our best to avoid. Instead, we will implement some sort of system, probably based on the event system, to ask the opener (i.e., the field or the WYSIWYG editor in question) to allow or deny access to the media library, based on the parameters in the state object. Since the state object is central to computing access this way, we'll need the tamper-proofing in place first.

Proposed resolution

Implement some sort of system, probably based on the event system, to ask the opener (i.e., the field or the WYSIWYG editor in question) to allow or deny access to the media library, based on the parameters in the state object.

Remaining tasks

Write patch
Review
Commit

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Updated: Comment #74

Problem/Motivation

New users registering accounts on a Drupal site can lose the welcome email to their spam filtering software.

New users can be created/imported into a Drupal system in bulk, and then it would be useful to be able to send a welcome email manually afterwards - #8.

Proposed resolution

Add the ability for users with the requisite permissions to re-send the welcome email to a user by visiting user/edit/XXX.

Only users who can register accounts can re-send the welcome email - #71

Remaining tasks

RTBC working patch.

User interface changes

A new button "Re-send welcome message" appears on the user edit page for users with the correct permissions to use it.

Screenshots available at #44 and #73

API changes

None.

Original report by @Chris Johnson

It would be nice if the admin could force a resend of the welcome message from the user edit page.

One case where this would be useful:
Many people are using spam-filtering software these days which make use of white lists, and the Drupal website sending address is not yet known to the user requesting an account.

Hi,

I would to know how to open linkfield in blank with D8 ?
Because I found solutions for filefield that add the attribute " target="_blank", but not about linkfield.

In addition, I don't find the checkbox option for the field like it was able for D6.

Thanks

Not all fields of an entity have a label, but I still would like to see their id when they appear in the change list.

Similar to this: https://www.drupal.org/node/2090585
^ though, this is Drupal 7

I'm writing a custom file widget, which extends the core FileWidget, that splits files into chunks so that I don't need to increase upload_max_filesize or post_max_size in my php.ini. It works, and the file is successfully uploaded and saved as a file entity with a file ID, but when trying to save that file ID into the field, it refuses to do it. The field settings allow files up to 500 MB, but because the file module is checking for the server's max upload size, it rejects the file, even though it already exists and is referenced in the database.

If there is a way to do this without changing core, I haven't been able to figure it out. I have already tried removing the validators in my widget's formElement() function, as well as using the hook mentioned in the linked post to unset the file_validate_size validator via hook_field_widget_form_alter.

It seems like even if I remove the validator for file size, getUploadValidators() still gets called from the file constraint validate() function. I wonder, what was the point of the file_validate_size validator if the constraint checked for this anyway?

public function validate($value, Constraint $constraint) {
  // Get the file to execute validators.
  $file = $value->get('entity')->getTarget()->getValue();
  // Get the validators.
  $validators = $value->getUploadValidators();
  // Checks that a file meets the criteria specified by the validators.
  if ($errors = file_validate($file, $validators)) {
    foreach ($errors as $error) {
      $this->context->addViolation($error);
    }
  }
}

Above is the function in FileValidationConstraintValidator.php that performs the getUploadValidators() that makes this impossible. The function getUploadValidators() is called from FileWidget.php (but not FileItem.php) and ImageItem.php (but not ImageWidget.php).

I hope that someone out there is as confused as I am why things are this way, or that a core change can make this possible. Or, maybe I'm missing something?

I think there is a performance problem when views are displayed on every site page and when there is a lot of content (node, term, etc) modification.

The problem appears on the following circumstances :

1. There is (for example) 3 nodes updated every minute
2. There is a view which list nodes on the homepage
3. There is a views which list nodes on a sidebar on every page
4. The page_cache module is enabled

Views will add a "node_list" tag on every views (cf https://git.drupalcode.org/project/drupal/blob/8.7.x/core/modules/views/...).

Pages with view (so every page here) will have the "node_list" tag because tags are bubbled on the entire page.
So every minute all page cache will be invalidated 3 times and it will be like there is no cache at all.

This problem occurs even if the nodes updated are not displayed in these views because the tag "[entity_type]_list" is too generic

I think we can't accept this behavior as Views and the anonymous cache are a base to build website and we can't just say that there is a choice to make between cache, views and very often node updates.

This can be fixed by removing the "[entity_type]_list" default tag added in CachePluginBase.
And then if we want to have this tag we can add it manually by using the module https://www.drupal.org/project/views_custom_cache_tag for example.

Problem/Motivation

We need to have all configuration that a user can define, which has translatable information on it, to be translatable in the Configuration Translation module's user interface.

There are several pieces of information from the Entity/Field system, which may include translatable strings, but which are not translatable using the Config Translation UI:

a) Field settings. For instance, on a Number field, there are translatable settings for the Prefix and Suffix in the settings config. But if you go to the Translate page for the field, all you can translate is the Label and Help for the field, not the prefix/suffix.

===> This is because the schema is wrong. See #2546356: Numeric field prefix/suffix settings should be translatable. Fields are translatable along with their settings, supposedly anyway.

b) Entity view displays - field formatter settings. For instance, on #2449597: Number formatters: Make it possible to configure format_plural on the formatter level we are adding the ability to numbers to have formatPlural() type formatting, but there is no way to translate the "1 item/@count items" strings. These are stored on the entity view display config items.

c) Entity form displays - widget settings. For instance, many text fields have widget options to enter Placeholder text, and obviously this would need to be translated. These are stored on the entity form display config items.

d) Base field overrides, which seem to include labels.
==> will do this on a separate issue

The technical reason is, at least for the entity view/form display formatter/widget settings, that there is not an edit form for these things -- the config schema indicates they should be translatable, but there's no way to edit them so config translation module doesn't put up a UI for translating them either. They are settings that appear as part of the Manage Form or Manage Display pages in Field UI, but the individual fields do not have their own settings forms.

Comment #5 also looked at other config items to see if they were translatable and #8 discussed them; more issues will be open.

Proposed resolution

Make sure that these items have a translation UI.

Remaining tasks

Figure out how to make them translatable. Maybe add tests too?

User interface changes

You'll be able to translate your site. Can't now.

API changes

Probably not, but we'll have to see what the patch entails.

Data model changes

I wouldn't think so.

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.

Steps To Reproduce

See issue comment #19