Problem/Motivation

The <front> route name is not been used to match on route name for current route name
when a selected node had been set as the front page for the site

Steps to reproduce

Given that we have a custom tour for the home page
And we used the <front> as the route to show the tour up
When we select a node as the front page like "/node/1" for the homepage
Then the tour icon in the toolbar will not show up
as the entity.node.canonical is been returned by

  // Load all of the items and match on route name.
  $route_match = \Drupal::routeMatch();
  $route_name = $route_match->getRouteName();

Proposed resolution

Check if the current matching path is the front page
and change the route name been passed to the tour Drupal entity query
To mach by route name not the entity.node.canonical by a node which been selected as the front page settings.

We could add

  // Check if the current matching path is the front page.
  if (\Drupal::service('path.matcher')->isFrontPage()) {
    $route_name = '<front>';
   }

As the route is more important than any other route name when the page is the front page.

Remaining tasks

User interface changes

When we configure a tour for the <front> page route
It will show up the icon for the Tour on the front page
even if we had other type of entities or selected entity as the front page.

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

On #2664830: Add search capability to help topics, andypost/ambermatz discovered that if you go to admin/search/pages and disable the Help Search page, then any page (such as admin/help) that is displaying the Help Search block will have a WSOD.

The reason is that the Search Block Form doesn't verify that the page it is supposed to submit to exists and is active. It should.

Proposed resolution

Alternative 1:
A patch was proposed by jhodgdon on #2664830-203: Add search capability to help topics -- here's the interdiff:
https://www.drupal.org/files/issues/2019-10-08/interdiff_13.txt

It needs a test. Also the part for the doc block in the interface is on another issue. Only the SearchBlockForm needs the patch.

Alternative 2:
Another way to resolve this would be to remove the ability to disable search pages. It is not clear why you would want to disable them anyway.

Remaining tasks

1. Decide which way to go -- the consensus is that we should remove the ability to disable search pages.

2. Make a patch.

User interface changes

The ability to disable search pages will not exist any more. You will only be able to add and delete pages, not disable them.

API changes

Functions related to disabling search pages and checking status will be removed/deprecated.

Data model changes

The status component of search page plugin configuration will be removed.

Release notes snippet

TBD

Problem/Motivation

When adding new media through the Media Library, it's possible to add more than the allowed number of media items.

Steps to reproduce:
1) In the Media Library, if you can select two items, select two.
2) Now upload a third item.

Expected: You should not be able to select more than the allowed number, or should receive a warning if you do.
Actual: no warning appears, and if you then insert the media you get nothing is attached. It fails without warning.

Proposed resolution

1. When the number of selected items exceeds the maximum allowed after adding one or more items in the media library, display a warning.
2. If the user then persists on inserting the media items with an overage, do not allow it, but display an error message.

Video:
https://www.drupal.org/files/issues/2019-12-21/3082690-71-walkthrough_0.mov

Remaining tasks

• Discuss solution
• Write patch
• UX Review
• A11Y Review
• Code review
• Frontend framework manager review
• Commit

User interface changes

Added error / warning messages to the media library.

Video of #21: https://www.drupal.org/files/issues/2019-07-17/media-library-exceeds-lim...

The warning after adding and exceeding the limit:
https://www.drupal.org/files/issues/2019-07-17/media-library-add-warning...

The warning after clicking 'Save and select':
https://www.drupal.org/files/issues/2019-07-17/media-library-save-and-se...

The error after clicking 'Save and insert' or 'Insert selected':
https://www.drupal.org/files/issues/2019-07-17/media-library-save-and-in...

API changes

Data model changes

None

Release notes snippet

To me this is unexpected behaviour and will be even more pronounced if #26552: Allow users with access to unpublished nodes to create unpublished books gets in.

The buttons don't look consistent. I propose we apply either text-align: left or text-align: center for both buttons.

When a D7 site has a long text field that uses the "text_plain" format, migration errors occur.

The "text_plain" plugin does not exist

The same problem was fixed for normal textfields in #3042223: Map text_plain field formatter to string.

Proposal: implement the same fix for long text fields.

Problem/Motivation

#3066512: Add checks for syntax and display of help topic Twig template files added a syntax checker which uses regular expressions to remove front matter and certain Twig syntax from the help topics files. Twig, however, has a much more flexible syntax -- for example {% set is just as good and {% set foo="}%" %} will also break the regular expression.

Proposed resolution

Fight fire with fire: use the Twig to render these things into HTML the way we need it.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Follow-up from #1986074: Buttons style update.

When restyling the buttons in the Seven theme we added a 'danger' variant that actually looks more like a link:

This required us to override all the default button styling and undo it:

.button--danger {
  display: inline;
  cursor: pointer;
  padding: 0;
  border: 0;
  border-radius: 0;
  box-shadow: none;
  background: none;
  -webkit-appearance: none;
     -moz-appearance: none;
  color: #c72100;
  font-weight: 400;
  text-decoration: underline;
}

The ideal markup here would be to to remove the button classes completely and simply style it as a link, without having to undo the base styling.

Problem/Motivation

Drupal login requires user browser cookie support. However, in the case that a user does not have cookies enabled and attempts to log in, no error message is given. Instead, the user is returned to the /user/{uid} page with 403 error code. As well as being a bug, the lack of cookie notification constitutes a key usability barrier in that users who hit the bug have no cue as to what is needed in order to log in.

Related issue at install time: #791004: Installer does not warn the user that cookies must be enabled with the correct cookie domain (and fails when they aren't).

Other PHP applications by way of comparison:

Wordpress:
Code is in http://core.svn.wordpress.org/trunk/wp-login.php. Prior to login, a test cookie is set:

//Set a cookie now to see if they are supported by the browser.
setcookie(TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN);
if ( SITECOOKIEPATH != COOKIEPATH )
	setcookie(TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN);

A hidden element is added to the login form:

<input type="hidden" name="testcookie" value="1" />

On login attempt, if the testcookie flag is set but the test cookie is not present, an error is raised:

	// If cookies are disabled we can't log in even with a valid user+pass
	if ( isset($_POST['testcookie']) && empty($_COOKIE[TEST_COOKIE]) )
		$errors->add('test_cookie', __("<strong>ERROR</strong>: Cookies are blocked or not supported by your browser. You must <a href='http://www.google.com/cookies.html'>enable cookies</a> to use WordPress."));

Joomla: Reportedly doesn't provide user feedback on cookie failure; see this forum post.
Symfony: Cookie handling doesn't appear to include a test for browser cookie support.

Proposed resolution

The proposed patch takes the following approach:

• Add a querystring parameter "state=check_logged_in" upon login form submission.
• On Kernel Request, if the parameter exists and the user is not actually logged in, then we know they don't have cookies enabled so we set a form error.

Remaining tasks

• Additional test coverage, and/or remove "Needs tests" tag
• Drupal\Core\EventSubscriber\MaintenanceModeSubscriber::checkUserCookies should be moved to a better appropriate ServiceSubscriber such as: Drupal\Core\EventSubscriber\AnonymousUserResponseSubscriber. For now, the checkUserCookies has nothing in relation with the MaintenanceMode
• Discuss about the comment of #217 of user_login_form_submit hook. What was the purpose should we keep it?
• The current patch was an initial draft. Several other possibilities have been suggested since, with no clear consensus as yet. #145 includes a reasonably current summary of options. Latest comment from D8 maintainer catch: "I don't like either the double redirect option, or the runtime check on every page here, but neither do I have any better ideas - would be good to get some feedback from others."
• #138 reports the following issue with the patch: "if the user logs off and uses the browser's history or back button to return to the page containing the "state=loggedin" query, then the cookie warning message is displayed when it shouldn't be. It would be possible to reword the message to allow for this possibility, absent a better solution."
• #123: "some of the information in this issue needs to be added to user_init() in a comment if we go for this option."
• The current patch generates two errors. From #160: "Those two failures look like they're specific to the solution here (probably code that expects a specific URL after logging in and therefore gets confused by the new ?state=loggedin). So not worth fixing unless this is the actual solution we're going with."
• Given that this is a common need that's been addressed in many other PHP applications but not in Drupal, we'd do well to look around. Some information is above in the issue summary. More research welcome.

User interface changes

Users attempting to log in will receive an error message if they don't have cookies enabled.

API changes

Modifies the user login process by adding a query string "state=loggedin" and testing for it during KernelEvents::REQUEST.

Original report by anders

since drupal relies on cookies for logging in, not warning the user if the cookie is not allowed is plain old stupidity.

We need a warning to regular user (on an already installed Drupal site) that they need to enable cookies to be able to log in on the site.

Right now nothing is displayed if cookies and not enabled and the user have not clues as to why.

We did have a patch (but it need a reroll), and a test.

Problem/Motivation

If you disable the SearchPage entity used for the default search, then this happens:

At that point, you can only access pages where no search block is placed. That means only pages using a different theme than the front end one. Which also means you cannot log in to your site anymore.

Steps to reproduce

Proposed resolution

Harden the code so this happens instead:

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Hm. Perhaps I'm doing sth. wrong, but after upgrading a few sites to Drupal 8.8 I found that I cannot save newly translated nodes anymore. The error message is "Either the path '/node/[nid]' is invalid or you do not have access to it." where [nid] is of course the corresponding NID.

Steps to reproduce:

* Use sth. other than the administrator account. You should have the usual editor permissions to create nodes and create/update translations and translate any entity, of course. You should not have any url alias permissions.
* Create a new node in the original language (in my case: German)
* Save the node
* Edit the node again
* Click on translation, add translation (English)
* Try to save
=> Error.

I found that this error comes from "ValidPathConstraintValidator::validate". If I insert a return statement in the first line of that method, everything works as expected.

I don't have pathauto installed or sth. I *would* like to set/assign an automatic alias in a custom hook_node_presave, but the validation error seems to be trigged before this hook is even called. I checked pathauto and they are also using that hook to do their auto-path magic.

I don't understand the error message to be honest. Yes "/node/123" is of course not a valid alias, because it's reserved for the nodes. But I didn't assign anything. I don't even have permissions to assign any manual alias.

It used to work with 8.7 but not with 8.8.

Problem/Motivation

On Drupal sites where users are uploading files clean filenames are hard to achieve because Drupal accepts most filenames as valid input. However lots of Drupal installs override this functionality, for example Thunder has been shipping a similar solution for a very long time. As @dww writes in #132

Content creators name their files all kinds of weird and unfortunate things. Even if everything is in English, it's still great to convert spaces to dashes, remove weird punctuation, special characters, etc. Plus, many users find themselves in a mix of case-sensitive and case-insensitive filesystems, so it's great to have Drupal automatically convert everything to lowercase. I constantly build custom functionality into my sites to cleanup filenames on upload so as to prevent the editors from making a mess of things. It'd be much better if core did that for me automatically.

Follow-up to #1842718: Use new Transliteration functionality in core for machine names and #567832: Transliteration in core.

@catch mentioned in #1314214: MySQL driver does not support full UTF-8 (emojis, asian symbols, mathematical symbols) we may want to transliterate filenames in core, so that we can have a database-level unique constraint on the URI field in the database. (However, this would presumably mean that transliteration of the field could not be optional).

Proposed resolution

Add a fieldset to the File system form (/admin/config/media/file-system) to opt-in for various kinds of filename sanitization:

• Transliterate the filename. Disabled by default, because it's not useful for some languages like Japanese.
• Replace whitespace with dash (-) or underscore (_).
• Replace any characters other than 0-9A-Za-z or - or _ or . with dash (-) or underscore (_). Requires that the 'Transliterate' option is enabled.
• Remove duplicate separator characters ie -- or .. or __ with be replaced with - or . or _.
• Convert to lowercase (to prevent issues on case-insensitive file systems).

On all files uploaded through the API and UI (i.e. not aggregated JS/CSS files, etc), the filename will be sanitized in whatever ways the site is configured to enforce.

We listen to the \Drupal\file\Event\FileUploadSanitizeNameEvent and change the filename according the the configuration.

Note: These sanitization settings only impact new file uploads, all files already uploaded to a site are not affected.

Remaining tasks

1. Decide if all whitespace or only spaces are converted. Update code and UI text to match. All whitespace as of #159.
2. Design and dispatch the appropriate event(s) where core's sanitization is done. Complete via #187.
3. Decide if the FileUploadEvent should also let listeners munge the destination. If so, update the Event accordingly. No (via @alexpott in #192.2).
4. Decide if we give the user enough feedback about renaming their file upon upload. No (via @alexpott in #203). If not, implement the appropriate feedback (Complete via #214).
5. Finish cleaning up the UI text, settings names, etc: Done via #219.
   • What's the right label for the 'strip' or 'remove' option for replace_non_alphanumeric? For now: "- Strip -". Previous: "- Remove (do not replace) -". Other? Option D: remove it entirely, via #219.
   • Should the options for the two selects (replace_*) be capitalized? Sure. ;) Via #194
   • Any other concerns/edits/fixes?
6. Finish writing Kernel test cases for (all?) the combinations of settings. Done via #213 and #219.
7. Upload screenshot(s) of final settings UI and update the summary. Done via #219.
8. Final code cleanup and fixes. No more @todo via #219.
9. Update/fix the change record. Done via #221
10. Add tests for REST integration
11. Decide if we're allowing transliteration as an option(!). See #272.
12. Decide if we should let people pick a transliteration language. See #270 and #272.
13. Usability review:
    • Decide if we want a UI at all, or if sites should simply configure this via settings.php (like they do for the public + private files dir paths). See #272.
    • If yes to a UI:
      • Decide whether we want to be able to have different replacement characters for whitespace, non-alphanumeric characters, and transliteration unknown characters. See #180, #246, #258, #261, and others...
      • If we have it as a separate / shared setting, decide if the "replacement character" setting should be "near" the checkboxes that provide replacement or at the end of the fieldset (see #263 for comparisons)
      • Decide if "replace non-alphanumeric" should be "near" transliterate option. See #241 and #242.
      • ...
14. Final string/UI review + signoff
15. Final reviews + RTBC.
16. Commit.

User interface changes

New "Filename sanitization" fieldset of options on FileSystemForm (/admin/config/media/file-system).

Pre-#245

Screenshot of the new settings UI :

The "Replace non-alphanumeric characters..." setting depends on "Transliterate" being enabled:

Available options under either "Replace ..." setting:

#245

Alternate UI from #245:

Options under "Replacement character" setting:

API changes

None

Data model changes

New configuration mapping file.settings:filename_sanitization, with options for:

• transliterate: Transliterate
• replace_whitespace: Replace whitespace
• replace_non_alphanumeric: Replace non-alphanumeric characters
• dedupe_separators: Remove duplicate dots (..), underscores (__) or dashes (--)
• lowercase: Convert to lowercase

Release notes snippet

@todo

testing...

Problem/Motivation

If you add a feed (or various) and you go to aggregator/sources/ you will see a pagination but it doesn't works. You can see the problem at: http://sb1.adricida.training.forcontu.com/aggregator/sources/

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

The patch definitely worked for me.
Tested on Drupal 8.7.x and 8.8.x.

RTBC! Thanks!

Layout builder incorrectly assumes it can get global contexts and values with getAvailableContexts. This means context providers that correctly adhere to \Drupal\Core\Plugin\Context\ContextProviderInterface currently do not resolve values with layout builder.

When rendering layouts, \Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay::getContextsForEntity should call contextRepository->getRuntimeContexts on the result of contextRepository->getAvailableContexts since by design the value are not intended to be added in getAvailableContexts.

It so happens the CurrentLanguageContext and CurrentUserContext incorrectly populate values in getAvailableContexts, which likely lead to this unnoticed issue. The way these context providers are allowing empty arrays to be passed to getRuntimeContexts is cheating. Even the contract for \Drupal\Core\Plugin\Context\ContextProviderInterface::getRuntimeContexts specifies only those provided must be returned. The attach patch basically does the empty-array cheat on contexts, but using the API as specified.

Contexts like NodeRouteContext correctly implement the interface, and could be made to work with LB. Currently this context also doesnt work properly because it doesnt set a default context value on layout builder build pages (See \Drupal\layout_builder\Context\LayoutBuilderContextTrait::getAvailableContexts). Note, solving NodeRouteContext is not within scope of this bug.

See the documentation for \Drupal\Core\Plugin\Context\ContextProviderInterface::getAvailableContexts, and the interface in general, for more information.

Problem/Motivation

When working with the claro theme, I noticed that using a combination of paragraphs, field_group and the claro theme results in not being able to select paragraphs in de dropbutton on the new node and edit node pages.

Steps to reproduce

Install:
paragraphs
field_group
claro (theme)

1. Create a couple of paragraphs (about 3-4)
2. Create a content type with a paragraph reference field. Make it so all paragraphs are selectable.
3. Add a field_group tabs (vertical) and tab.
4. Put the paragraph field created in step 2 under this tab
5. Try to add a page with paragraph 4

Expected to be able to select any item in the dropbutton but some items are hidden in overflow (note that this issue is only at certain widths because of the media rule (@media screen and (min-width: 85em)))

Proposed resolution

I do not know how to fix this. I fixed this locally by removing:

diff --git a/themes/claro/css/components/vertical-tabs.css b/themes/claro/css/components/vertical-tabs.css
old mode 100644
new mode 100755
index 8998a15483..09e8ed83df
--- a/themes/claro/css/components/vertical-tabs.css
+++ b/themes/claro/css/components/vertical-tabs.css
@@ -344,7 +344,6 @@
 
 @media screen and (min-width: 85em) {
   .js .vertical-tabs__item {
-    overflow: hidden;
     margin: 0;
     border: 0;
   }

Remaining tasks

Test the above patch or create a solution

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

With big pipe enabled on profile pages the toolbar overlaps the content.

After loading the page initial the toolbar overlaps the heading.

After clicking on admin in the menu to close the sub menu the same margin as before is used.

After opening the sub menu again the height is correctly set and all the content moves downwards.

With BigPipe enabled this happens as the toolbar links are fetched later by Drupal\user\ToolbarLinkBuilder::renderToolbarLinks

On load the toolbar gets initializied and sets the padding-top of 40px. After that big pipe adds the toolbar, but doesn't invoke ToolbarVisualView.updateToolbarHeight

Proposed resolution

TBD

Maybe an option would be that big pipe introduces a new event when it's finished loading a block so ToolbarVisualView then can update the toolbar height.

Remaining tasks

Fix and test

User interface changes

none

API changes

none

Data model changes

none

Release notes snippet

Problem/Motivation

CKEditor (body) field goes behind the tabs to the right when you resize browser or open up browser Inspection on the side.
Also tested it on simplytest.me site and it acts the same.

Steps to reproduce

First, you need to create a node with CKEditor. There is no issue with empty CKEditor because then CKEditor div width value is set to Auto.
Now when you go back to the node edit page and make your browser width smaller you will see that CKEditor going behind the right side tabs.

Temporary fix

As a temporary fix I created JS script to set CKEditor width value to Auto on browser resize.

/**
 * @file
 * ckeditor_width_fix.js
 */

(function ($) {
    // Function to set ckeditor width value pack to auto.
    function ckeditor_width() {
        if ( jQuery('div.cke_browser_webkit').length )
        {
            jQuery('div.cke_browser_webkit').attr('style', 'width:auto;');
        }
    }
    // On browser resize need to set CKEditor width to auto.
    $(window).resize(function() {
        clearTimeout(window.resizedFinished);
        window.resizedFinished = setTimeout(function(){
            ckeditor_width();
        }, 250);
    });

})(jQuery);

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.