I am getting occasional “the website encountered a problem” messages when a user attempts to post a comment.

The following Watchdog messages are generated:

PHP error:

Drupal\Core\Entity\EntityStorageException: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT savepoint_1 does not exist: ROLLBACK TO SAVEPOINT savepoint_1; Array ( ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 846 of /home/public_html/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Comment error:

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT savepoint_1 does not exist: ROLLBACK TO SAVEPOINT savepoint_1; Array ( ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 844 of /home/public_html/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

I can't identify any pattern to this behaviour.

Typically it occurs 2-3 times per week on a website that gets in the region of 100-150 comments posted daily.

I have updated the Drupal core version 8.5.5 to 8.6.13.
I am trying to access config > System > Basic site settings (admin/config/system/site-information) it is getting the below error.

The website encountered an unexpected error. Please try again later.InvalidArgumentException: Source path has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 186 of core/lib/Drupal/Core/Path/AliasManager.php).

Drupal\system\Form\SiteInformationForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 518)
Drupal\Core\Form\FormBuilder->retrieveForm('system_site_information_settings', Object) (Line: 275)
Drupal\Core\Form\FormBuilder->buildForm('system_site_information_settings', 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: 119)
Drupal\cdn\StackMiddleware\DuplicateContentPreventionMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Steps to reproduce

1. Clean Drupal installation
2. Go to admin/structure/block, edit any (for example: Search) block that appears on the frontpage
3. Go to pages tab and set /user/* and click "Show for the listed pages"
4. Go to your.site/index.php.php
5. There is an exception: InvalidArgumentException: Source path .php has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 229 of core/lib/Drupal/Core/Path/AliasManager.php).

Problem/Motivation

The comment module comes with a CommentAccessControlHandler which is not really used on crucial places. Instead of using this handler, there are dozens of places, where the permissions provided by the comment module are checked directly (e.g. post comment permission checks instead of $entity->access('create') or access comments permission checks instead of $entity->access('view')).

For example, the $entity->access('create') access check is only used during comment link generation, but not for the comment form itself.

Due to this, it is currently impossible to create a custom access control handler for comment entities, as it would not be used where necessary. When reading through the code, you can also see there is a lot of access-related duplicate code (because the permission checks duplicate the access checks of the access control handler).

These changes will affect other issues as well, when those deal with comment access/permissions, but they are very important to get the comment entity access handling correct.

Proposed resolution

• Scan through the code and eliminate all permission checks with proper $entity->access() checks. Search for the following permissions:
  • access comments
  • post comments
  • edit own comments
• If possible, the commenting status of the parent ID should be taken into account in the access control handler checks. As this status flag affects the entity access for certain operations, its checks should also be centralized in the access control handler
• Comment-related tests should still work as before, because only the access checking behavior is changed, but not the access requirements themselves

Remaining tasks

• Create a patch

User interface changes

None.

API changes

None.

Data model changes

None.

Postponed on #3067523: Add Drupal JavaScript theme functions for password confirm widget

Problem/Motivation

In #3067523: Add Drupal JavaScript theme functions for password confirm widget, this out-of-scope CSS was in a proposed patch. Assuming this is a desired addition to Claro, this is an issue to give such an addition appropriate scope. This adds a nice transition to the un-hiding of the password confirm field.

+++ b/core/themes/claro/css/components/form--password-confirm.css
@@ -98,9 +100,11 @@
diff --git a/core/themes/claro/css/components/form--password-confirm.pcss.css b/core/themes/claro/css/components/form--password-confirm.pcss.css

diff --git a/core/themes/claro/css/components/form--password-confirm.pcss.css b/core/themes/claro/css/components/form--password-confirm.pcss.css
index cf2cac451b..d31e7ec415 100644

index cf2cac451b..d31e7ec415 100644
--- a/core/themes/claro/css/components/form--password-confirm.pcss.css

--- a/core/themes/claro/css/components/form--password-confirm.pcss.css
+++ b/core/themes/claro/css/components/form--password-confirm.pcss.css

+++ b/core/themes/claro/css/components/form--password-confirm.pcss.css
+++ b/core/themes/claro/css/components/form--password-confirm.pcss.css
@@ -32,7 +32,9 @@

@@ -32,7 +32,9 @@
 }
 
 .password-confirm__confirm {
-  margin-bottom: 0;
+  /* Progress spacing + form item description's top margin. */
+  margin-bottom: calc(var(--progress-bar-spacing-size) + (6rem / 16));
+  transition: none;
 }
 
 .js .password-confirm__confirm {
@@ -52,9 +54,11 @@

@@ -52,9 +54,11 @@
 }
 
 .js .is-initial.is-password-empty.is-confirm-empty:not(.form-item--error) .password-confirm__confirm {
-  display: none;
+  overflow: hidden;
   max-height: 0;
   margin-top: 0;
+  margin-bottom: 0;
+  transition: max-height 0s ease-in-out, margin 0s ease-in-out;
 }

Look at this

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

After installing content_moderation if Views was already installed the views.view.moderated_content view does not have a dependency on the workflows.workflow.editorial configuration, even though one of its filters, ModerationStateFilter, declares that dependency.

The reason is that when the view is being saved and its dependencies being calculated the moderation state handlers cannot be instantiated correctly, so instead they get replaced by broken handlers which do not have any dependencies.

Proposed resolution

?

Problem/Motivation

The user.js in Drupal core (it is attached to the password_confirm form element) uses specific markup for constructing the password strength message, password strength bar, the password match message and the password improvement tips.

Currently, markup of these elements is not overridable by themes, therefore Claro had to override the user.js file completely

We want to be able to remove Claro's user.js replacement, and only use Drupal.theme() functions (and overridden JS settings) for theming the password confirm widget.

Proposed resolution

Introduce new Drupal.theme callbacks for these components and refactor user.js to use the new Drupal.theme callbacks. Remove Claro user.js and leverage the newly added theme functions instead.

Remaining tasks

• Provide patch
• Create change record

User interface changes

Nothing.

API changes

Data model changes

Release notes snippet

The user module has added JavaScript theme functions have to allow customizing password confirm widget markup. Information on using these functions can be found in user.theme.es6.js.

Problem/Motivation

The {node} and {node_revision} parameters from node revisions routes are not upcasted. But a contrib module expects to receive fully upcast the entity in {node} and {node_revision} parameters.

Example: \Drupal\ctools\Plugin\Condition\EntityBundle::evaluate().

Proposed resolution

Upcast the {node} and {node_revision} parameters for these paths:

• /node/{node}/revisions/{node_revision}/view
• /node/{node}/revisions/{node_revision}/revert
• /node/{node}/revisions/{node_revision}/revert/{langcode}
• /node/{node}/revisions/{node_revision}/delete

In #119 @Berdir raise an issue about the fact that it will break modules and sites out there that currently hardcode node being an integer and do a Node::load(getParameter('node')).
In #123 @Berdir shared after chatting with @catch

catch: @berdir I don't have great ideas. The change is definitely allowable so it's down to how much we want to break/fix things.

Remaining tasks

1. Review the issue.
2. Commit the issue
3. Rejoice!

User interface changes

None.

API changes

• \Drupal::routeMatch()->getParameter('node') will return a Node object instead of an integer on the node-revision routes listed above.
• \Drupal::routeMatch()->getParameter('node_revision') will return a Node revision object instead of an integer on the node-revision routes listed above.

Data model changes

None.

Release notes snippet

The {node} and {node_revision} parameters from node revisions routes are now upcasted. See Node revision routes upcast the {node} and {node_revision} parameters for more information.

Problem/Motivation

When threading is enabled on comments, there is no mechanism to limit how far a comment will indent. This poses a problem for sites that wish to have a defined maximum threading level for threaded comments.

Proposed resolution

Add a configuration to allow the maximum threading depth to be defined. Tweak the comment builder to take into account the configured threading level, and limit it accordingly.

Remaining tasks

Needs review, needs tests.

User interface changes

Adds a number field on the comment field edit form, a field which only shows when the threading checkbox is ticked.

API changes

None.

Data model changes

thread_depth added to settings in the comment field configuration file.

For a view with a page display and an attachment display, exposed filters are not inherited in attachment display even if 'Inherit exposed filters' option is set to yes.

Problem/Motivation

We've had this feature request from multiple editors/site builders in the past years and it was also discussed briefly during the recent Claro sprint.

Basically it would be nice to have the ability to double click on a media entity while browsing with the media library to select it and close the modal (apply the selection). This behavior would only make sense for single image fields.

Proposed resolution

tbd

Remaining tasks

tbd

User interface changes

API changes

Data model changes

From #107824: Convert {watchdog}.referer and {accesslog}.url from VARCHAR to TEXT, I didn't get the patch that I wanted committed, so now I need to file a separate issue. We're currently using the incorrect spelling of "referrer" through our database columns and core code. I think we should be should fix the spelling error in Drupal since it is easy and will not continue to propogate a sad, mis-spelled word.

From the Wikipedia article on "referrer":

Referer is a common misspelling of the word referrer. It is so common, in fact, that it made it into the official specification of HTTP – the communication protocol of the World Wide Web – and has therefore become a widely used industry spelling when discussing HTTP referrers[citation needed]. The misspelling usage is not universal, the correct spelling of "referrer" is used in some web specifications such as the Document Object Model.

This issue will also rename the {accesslog}.url column to {accesslog}.referrer to match consistancy and description. "url" to me implies the current url, when in fact, that column's description from the schema says, 'Referrer URI.'

Problem/Motivation

The log-in pages for my Drupal sites are being indexed by google. I'm not sure if this is due to recent changes in how google handles the robots file, or spiders sites, but it seems I am not alone in this problem: https://www.drupal.org/forum/general/general-discussion/2012-06-27/is-it...

Steps to reproduce

1) Google the domian name of one of your live sites
2) see if Google recommends the Log In page in the list of pages beneath the search result for the home page

Proposed resolution

Remove trailing slashes from the robots.txt file (or, add alternatives that don't include the trailing slashes)

Remaining tasks

update the robots.txt file

User interface changes

none

API changes

none

Data model changes

none

Release notes snippet

TBD

Problem/Motivation

Recent interviews and research exposed pain points around Drupal's admin experience of looking and feeling dated. With Claro look&feel update the Installer to adapt Seven designs to the new Design System.
Current look:

Proposed resolution

Redesign the installer and its components according to the new design system and implement it.

Current state: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...

Remaining tasks

• Finalise Design
• Implement the new design

User interface changes

Redesign of the installer

API changes

Problem/Motivation

When migrating D7 sites (such as for example webchick.net), you get lots of errors like
Notice: Undefined index: text_processing in Drupal\text\Plugin\migrate\field\d7\TextField->getFieldType() (line 76 of core/modules/text/src/Plugin/migrate/field/d7/TextField.php).

Steps to reproduce

Perform a migration with a D7 source site which has text fields without the text_processing setting.

Proposed resolution

Harden the code.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the comment, node, path, taxonomy module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':   /code>
   And ends either at the end of the function, or where you find another <code>case 'something':

   line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

Once #2907413: Consider supporting Layout Builder Overrides for other view modes is addressed, sections will be stored per-view mode.

LayoutEntityHelperTrait::getEntitySections() assumes the view mode is default.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

N/A

Problem/Motivation

I upgraded from 8.8.8 to 8.9.0. When I try to access site in Apache, I see this error:

Drupal\Core\Asset\Exception\InvalidLibrariesOverrideSpecificationException: The specified library seven/classy.book-navigation does not exist. in Drupal\Core\Asset\LibraryDiscoveryCollector->getLibraryDefinitions() (line 105 of core/lib/Drupal/Core/Asset/LibraryDiscoveryCollector.php).

When I run the same thing on nginx, I cannot replicate the issue.

Problem/Motivation

Split from #2829919: Either avoid or explicitly test binary encoding in default configuration.

I found in #2829919: Either avoid or explicitly test binary encoding in default configuration that there's no policy on how to deprecated a config schema entry. This issue is a proposal for config schema deprecation policy.

Proposed resolution

• Deprecated config schemas will expose a new key deprecated. The value is the deprecation message.
• SchemaCheckTrait::checkValue() will check for this key and will trigger the deprecation error.
• Next policy entry to be added to https://www.drupal.org/core/deprecation:
  

  Configuration schema

  Add a deprecated property in the deprecated config schema entry. The value should be the deprecation message. For example:

  complex_structure:
    type: mapping
    label: Complex
    deprecated: "The 'complex_structure' config schema is deprecated in drupal:9.1.0 and is removed from drupal:10.0.0. Use the 'complex' config schema instead. See http://drupal.org/node/the-change-notice-nid."
    mapping:
      key:
        type: ...
      ...
  

Remaining tasks

Update https://www.drupal.org/core/deprecation document.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

In order to deprecate a configuration schema, add a deprecated key with the deprecation message as value.

When trying to access the working revision entity data with resourceVersion=rel:working-copy and using includes, the current revision of the referenced entities is being returned by the method "resolveIncludeTree" in IncludeResolver class. This method should return the data as per the revision being passed in the API query or the working revision.