Problem/Motivation

RelationshipUserFileDataTest makes no HTTP requests but is a functional test

Proposed resolution

Convert RelationshipUserFileDataTest into a Kernel test

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Problem/Motivation

Scoped to simpletest module because we still don't have a generalized testing component.

In #3038901: Speed up the tests on DrupalCI by not running slow tests last we formalized adding @group #slow to tests which take a long time to run. This way we can prioritize them to run early.

In that issue we discussed how to determine which tests should be marked as #slow.

We can collect data about test speed, as per #3033037: DrupalCI should track and display job run times and #2943340: Process PHPUnit junit reports separately, but these do not provide feedback at patch-evaluation time as to whether a given test needs to be marked as #slow.

A suggested solution is to add a test listener which times tests, and if a threshhold is exceeded and the test is not already annotated with @group #slow, fail the test with an explanation.

Proposed resolution

Add a listener? Other solution?

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

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 same login page. [To be confirmed: is this still the case?] 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=loggedin" 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

Drupal core themes make use of uppercase text in some parts of the design. Seven uses uppercase for table headers, details/summary headers, view UI configuration sections, and a few other places like the status report.

Uppercase can be more difficult to read than lowercase text. Users with dyslexia may be especially impacted by this, but it affects everyone to a degree. (Just think of what the message list looks like in your email spam folder....)

Proposed resolution

Stop using uppercase text in our core themes. The places were it is used typically have some other visual affordance to stress them, e.g.

• Config section headings in Views UI are large and bold, so they would still be prominent without uppercase.
• Table headers are identified by position, borders, and a slightly darker background
• Collapsible details/summary have borders, and a disclosure triangle icon.
• The summary tiles at the start of the status report page have big text, and icons.
• The long list on the status report page is divided into left-right regions; headers are on the left, details on the right. At small screen sizes, these are collapsible details.

Remaining tasks

Assess extent of all-caps text in UI.
Remove text-transform: uppercase from various stylesheets.
Patch

User interface changes

Minor design changes, intended to make some UI text easier to understand, especially for users with dyslexia.

API changes

None.

Data model changes

None.

Commit credits needed

This issue started as a discussion in the #accessibility Slack channel. Participants' Slack names:
ttamniwdoog, jhodgdon, donnabungard, cehfisher, mgifford, rachelolivero

Problem/Motivation

New browser features enable better website integration to users' systems. While working on the progressive web app module I came across a W3C draft for a manifest file. This file is used on mobile devices to allow website authors some control over the way the shortcut and initialization screen looks like.

Proposed resolution

• Add new form fields and reorganize the site information form.
• Add a <link rel="manifest" href="…/manifest.json"> tag in the head and a way to generate that file.
• Generation of a manifest.json file containing at least:
  

  {
    "lang": "en",
    "dir": "ltr",
    "name": "Very good Drupal Website™",
    "short_name": "Drupal Website™",
    "icons": [{
          "src": "my/default/theme/logo.png",
          "sizes": "144x144"
        }],
    "start_url": "/",
    "display": "browser",
    "orientation": "portrait",
    "theme_color": "#ffffff",
    "background_color": "#ffffff"
  }
  

• We need to add a <meta name="theme-color"> tag for branding color to compliment the values set inside manifest.json

User interface changes

Site information form changes. New fields:

• short_name (textfield)
• start_url (textfield) Could be different from the site homepage.
• display (select list/radio)
• orientation (select list/radio)
• theme_color (probably expose that to themes)
• background_color (probably expose that to themes)

API changes

Probably some ways for theme to declare/alter informations in the manifest file.

More details: Web app manifests usher new wave of progressive apps to your homescreen.

Follow-up to #2848161: [meta] Replace calls to deprecated db_*() wrappers

Problem/Motivation

#1894396: Mark db_*() wrappers in database.inc as @deprecated for 9.x deprecated the db_* family of functions. Update documentation recommending them.

Proposed resolution

This can help find them git grep -E "^\s*(\/\/|\*).*db_\w+"

Remaining tasks

I don't really know if this is a core issue or block cache alter issue... even I don't know if it there is any solution...
I have a website with both "User login" block and "Search" block, cached with "Globally cached" option. But when using cache on that blocks, I get duplicated ID's (i.e., #edit-submit and #edit-actions). I think it's because admins don't see "User login" block, so "Search" block HTML gets cached with #edit-submit ID. Then, when first anonymous visitor comes to the site, "Search" block HTML gets loaded from cache, and "User login" block it's dinamically generated with #edit-submit ID (because it wasn't generated dinamically before). So, the HTML generated can't be validated by automatic tools.
This also can generate bugs in javascript, and stylesheet problems (luckily for me, it's not my case).
Is there any way to avoid this? Storing somewhere IDs cached used when caching or something...
As I said, I don't know if this is a core issue or not.

We are clearing caches programmatically after every user login.

Reason for that is, that we are using a custom menu manipulator class extending from DefaultMenuLinkTreeManipulators, in order to show/hide menu items according to specific users/roles etc. For this to take effect, one needs to clear caches.

The clear cache in hook_user_login, seems to break the forgot password workflow.
In specific, usually but not always the 1 time login link redirects to the homepage without login in.

core version seems irrelevant, as the same issue is on both 8.6.x and 8.7.x

Remove or deprecate the class, remove its conditional usage in \Drupal\Core\Cache\ApcuBackendFactory::__construct().

Followup #2999721: [META] Deprecate the legacy include files

Problem/Motivation

Convert drupal_rebuild function into Cache static method.

Proposed resolution

Remaining tasks

1. Add new method
2. Replace body of the function with new method call
   Replace old function calls with the new method
3. Create CR
4. Add @deprecated annotation with message for deprecated drupal_rebuild function
5. Call @trigger_error function in deprecated drupal_rebuild function
6. Add legacy test

User interface changes

none

API changes

New method Drupal\Core\Cache\Cache::rebuild
drupal_rebuild function become deprecated.

Data model changes

none

Problem/Motivation

Add a new FieldFormatter plugin to output text fields as a <details> / <summary> group.

Initial use case for Standard profile: in #3002770: Provide authors with tools to manage transcripts and captions/subtitles for local video and audio there is a plan to add a transcript field to some media bundles. A details element is a compact, unintrusive way to present the transcript close to the video.

Aside from that, it's a general purpose formatter to help authors make good use of a standard HTML element. A few other potential uses:

• Events - a "venue address" field.
• Commerce products - a "size info" field.
• User profiles - a "contact details" field.
• A long-text-with-summary could populate the <summary> using token replacement from the sub-field.
• Paragraphs - a question-and-answer paragragh type, with two fields for the question and answer. The answer field would use the details/summary formatter, configured to show the question as the <summary> via token replacement. (See comment #10 for a demo.)
• Long accessible descriptions for complex images. A flowchart accompanied by a rich text alternative in a collapsed details element. Comment #5 elaborates.

Proposed resolution

The FieldFormatter plugin will have some relevant settings:

1. A checkbox setting controls whether it is should be open or closed initially, i.e. the <details open> attribute.
2. What to use as the text of the <summary> element. Possible options are:
   • The field label.
   • Custom text specified by the site-builder. As a bonus, this could support token replacements.
   • Others? Maybe leave that possibility open for contrib.

Remaining tasks

• Implement the formatter.
• Tests.

User interface changes

Settings form for the new formatter - just a few inputs/strings.
The rendered field re-uses the existing details.html.twig template, and is already styled in Bartik/Seven.

API changes

None.

Data model changes

Just the necessary addition to config schema for the new formatter settings.

Drupal 8 integration with composer has been excellent for managing 3rd party PHP libraries with Drupal, as the libraries can be called using PSR-4 namespaces to load the libraries, regardless of the location of the vendor folder. Being able to call these files regardless of the location of the vendor folder is important, as the vendor library folder location is dynamic. Many installations have the vendor folder installed in the webroot, however it is a best practice to place the vendor folder outside the webroot, a practice followed by the Drupal Composer template,

The problem comes with CSS and JS libraries. These can be included using composer, but when the vendor file is outside the webroot, any CSS and JS are unusable, as they are not web-accessible and therefore cannot be included in *.libraries.yml files.

For contributed module developers, this has led to two separate methods of managing 3rd party libraries with Drupal 8. PHP libraries can and are managed with Composer, and module developers can use composer.json files to manage their dependencies. However, modules that use 3rd party CSS/JS libraries have to either use D7 methods of creating a libraries folder, and have users manage the dependencies on their own to place the library in a web-accessible location, or use Composer to manage the dependency, then have users copy the CSS and JS files to a web accessible location. An example of this is the jQuery Colorpicker module, which as of the time of writing of this post requires users to manage the library on their own, downloading it to a /libraries folder, linking to the CSS and JS files using:

library:
  version: 1.0.1
  css:
    theme:
      /libraries/jquery_colorpicker/css/colorpicker.css: {}
  js:
    /libraries/jquery_colorpicker/js/colorpicker.js: {}
  dependencies:
    - core/jquery

As you can see, the CSS and JS files are linked to from the /libraries folder. In order to ensure system integrity, hook_requirements() has been implemented, informing users of the requirement of downloading the library and providing instructions on how to do so. This is not ideal. The ideal would be to Include a dependency on the library through Composer, managing the 3rd party library in the same manner as PHP libraries are managed.

The solution to the issue of managing 3rd party CSS and JS libraries with Composer is to use the Vendor Stream Wrapper module. This module is essentially a clone of the private stream wrapper functionality of core, but working with the vendor directory rather than the private files directory. It sets up a vendor:// stream wrapper, and adds parsing to *.libraries.yml files, so that the above jquery_colorpicker.libraries.yml file could be converted to this:

library:
  version: 1.0.1
  css:
    theme:
      vendor://jaypan/jquery_colorpicker/css/colorpicker.css: {}
  js:
    vendor://jaypan/jquery_colorpicker/js/colorpicker.js: {}
  dependencies:
    - core/jquery

The module looks for the vendor folder first in the webroot, then one folder above the webroot. If the vendor folder is in any other location, the location can be set in settings.php.

I think this module should be included into core, to allow for Drupal modules to manage CSS and JS libraries using Composer, unifying 3rd party library management into a single API, rather than having to use D8 methodology for PHP libraries, and D7 methodology for managing CSS and JS libraries. Currently it is a bug that CSS and JS files in a vendor folder that exists outside the webroot are unable to be linked to, and it becomes a security risk if one of the files that is part of the 3rd party library is found to have a security vulnerability. This security vulnerability would not exist for users who have placed their library in a vendor folder that is outside the webroot.

Follow-up to #2811065: Fix docs around --printer option in phpunit.xml.dist

Problem/Motivation

From #2811065-12: Fix docs around --printer option in phpunit.xml.dist

AFAICT, the printerClass definition works, and does not break PHPStorm any more. 2016.3 EAP, October 19, 2016.

Proposed resolution

https://youtrack.jetbrains.com/issue/WI-24808 is resolved so add the printerClass to phpunit.xml.dist

Remaining tasks

• Verify it.
• RTBC if fixed.
• Report a jetbrains bug if not fixed.

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

Output of composer outdated -D on PHP 7.0

doctrine/annotations         v1.2.7  v1.4.0   Docblock Annotations Parser
doctrine/common              v2.6.2  v2.7.3   Common Library for Doctrine projects
egulias/email-validator      2.1.7   2.1.8    A library for validating emails against several RFCs
masterminds/html5            2.3.0   2.6.0    An HTML5 parser and serializer.
paragonie/random_compat      v2.0.18 v9.99.99 PHP 5.x polyfill for random_bytes() and random_int() from PHP 7
pear/archive_tar             1.4.6   1.4.7    Tar file management class with compression support (gzip, bzip2, lzma2)
symfony-cmf/routing          1.4.1   2.0.3    Extends the Symfony2 routing component for dynamic routes and chaining several routers
symfony/class-loader         v3.4.26 v3.4.28  Symfony ClassLoader Component
symfony/console              v3.4.26 v3.4.28  Symfony Console Component
symfony/dependency-injection v3.4.26 v3.4.28  Symfony DependencyInjection Component
symfony/event-dispatcher     v3.4.26 v3.4.28  Symfony EventDispatcher Component
symfony/http-foundation      v3.4.27 v3.4.28  Symfony HttpFoundation Component
symfony/http-kernel          v3.4.26 v3.4.28  Symfony HttpKernel Component
symfony/process              v3.4.26 v3.4.28  Symfony Process Component
symfony/routing              v3.4.26 v3.4.28  Symfony Routing Component
symfony/serializer           v3.4.26 v3.4.28  Symfony Serializer Component
symfony/translation          v3.4.26 v3.4.28  Symfony Translation Component
symfony/validator            v3.4.26 v3.4.28  Symfony Validator Component
symfony/yaml                 v3.4.26 v3.4.28  Symfony Yaml Component
twig/twig                    v1.38.4 v2.11.3  Twig, the flexible, fast, and secure template language for PHP
typo3/phar-stream-wrapper    v2.1.2  v3.1.2   Interceptors for PHP's native phar:// stream handling
zendframework/zend-diactoros 1.4.1   1.8.6    PSR HTTP Message implementations
zendframework/zend-feed      2.7.0   2.12.0   provides functionality for consuming RSS and Atom feeds

Proposed resolution

Updated these packages.

Remaining tasks

Create a patch.
Review.
Commit.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Our PHP dependencies have been updated. This includes
- Removing symfony/polyfill-iconv (v1.11.0)
- Updating doctrine/lexer (v1.0.1 => 1.0.2)
- Updating doctrine/inflector (v1.1.0 => v1.2.0)
- Updating doctrine/collections (v1.3.0 => v1.4.0)
- Updating doctrine/annotations (v1.2.7 => v1.4.0)
- Updating doctrine/common (v2.6.2 => v2.7.3)
- Updating egulias/email-validator (2.1.7 => 2.1.8)
- Updating pear/archive_tar (1.4.6 => 1.4.7)
- Updating symfony/class-loader (v3.4.26 => v3.4.28)
- Updating symfony/debug (v3.4.26 => v3.4.28)
- Updating symfony/console (v3.4.26 => v3.4.28)
- Updating symfony/dependency-injection (v3.4.26 => v3.4.28)
- Updating symfony/http-foundation (v3.4.27 => v3.4.28)
- Updating symfony/event-dispatcher (v3.4.26 => v3.4.28)
- Updating symfony/http-kernel (v3.4.26 => v3.4.28)
- Updating symfony/process (v3.4.26 => v3.4.28)
- Updating symfony/routing (v3.4.26 => v3.4.28)
- Updating symfony/serializer (v3.4.26 => v3.4.28)
- Updating symfony/translation (v3.4.26 => v3.4.28)
- Updating symfony/validator (v3.4.26 => v3.4.28)
- Updating symfony/yaml (v3.4.26 => v3.4.28)
- Updating twig/twig (v1.38.4 => v1.42.2)
- Updating zendframework/zend-diactoros (1.4.1 => 1.7.2)
- Updating zendframework/zend-stdlib (3.0.1 => 3.2.1)
- Updating zendframework/zend-escaper (2.5.2 => 2.6.0)
- Updating zendframework/zend-feed (2.7.0 => 2.12.0)
- Updating symfony/dom-crawler (v3.4.26 => v3.4.28)
- Updating symfony/browser-kit (v3.4.26 => v3.4.28)
- Updating symfony/css-selector (v3.4.26 => v3.4.28)
- Updating symfony/phpunit-bridge (v3.4.26 => v3.4.28)

Problem/Motivation

Often on a website we want editors to have the options to add new nodes into the menu. Particularly for the main navigation, this can create problems if they unknowingly add their item to the top of the menu, creating a new "section" in the site's menu, especially if the site has horizontal menu bar, that has been carefully adjusted for specific breakpoints.

Proposed resolution

Create an option on menus to restrict access to the top-level item for the menu, which usually shows up as in the dropdown to select a parent for the new menu item. If selected, a new permission would be created. This should probably apply to edit access for menu items that are direct children of the element too, since dramatically change the length of a menu section could have design and other consequences.

Remaining tasks

- add the option in the menu settings, along with the code to add/delete the permission, based on the setting
- modify the Menu UI forms to respect the new permission, and restrict access to the top of the menu accordingly

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

During the Managing Drupal sites with Composer BoF at DrupalCon Baltimore 2017, the topic of contributed module front-end library management came up.

Here's the current problem:

• Webform (and other similar contrib projects) requires a 3rd party front-end library.
• Modules can't rely upon libraries being available inside [drupal-docroot]/vendor/[library/here], because the project vendor directory isn't guaranteed to be in the docroot.
• Current practices seem to indicate that a libraries folder in the docroot is the best place for 3rd party front-end libraries.
• It's hard to get contributed module dependencies to be installed to [drupal-docroot]/libraries/[library/here] instead of the vendor directory. Especially if the library doesn't care about Drupal and doesn't have a custom type of drupal-library

There are ways to hack around this:

• Add a custom and project-specific repository for every 3rd party library in your composer.json file.
• Use the composer-installers-extender library to allow the specification of the install path per-library.
• Ditch Composer and just download and commit all the 3rd party libraries into the [drupal-docroot]/libraries folder.

Proposed resolution

It would be really helpful if Drupal core could enable contributed modules to do things like specify a specific path into which a 3rd party dependency will be placed.

One solution we discussed would be adding code that responded to a Composer hook and moved a downloaded dependency into a specified path (which could be indicated via the project's composer.json file).

So a contributed module maintainer (e.g. Webform, Font Awesome Iconpicker, etc.) would add something like (pseudocode):

"extra": {
        "drupal-install-library-path": "libraries"
    }

And then when you composer require that contributed module, something in Drupal core's composer configuration would pick up that path and place the libraries for the 3rd party module into the specified path.

This is totally open to change (in terms of implementation), but the general idea is: everyone is solving this problem in a different way, and it would be nice if core could provide an official mechanism for doing this 'the Composer way'.

Or, at a minimum, we should document a recommended solution.

Remaining tasks

• Choose an approach (custom Composer hook? Add another library to help? Use/recommend Robo?)
• Implement the approach (this part's easy, right?)
• Document / announce the change so Contrib modules and themes can use this new approach

User interface changes

N/A

API changes

There may be some additional API functionality, but probably not.

Data model changes

N/A

Currently you can't add an element with dashes into the custom 'Styles' option for CKEditor, this is not a restriction of the editor itself and if using Entity Embed, you would have elements such as "drupal-entity".

I recreated this issue by going to the CK Editor config page in my local instance of v8.5.x-dev:
.../admin/config/content/formats

I edited the Full HTML editor configuration:
.../admin/config/content/formats/manage/full_html?destination=/admin/config/content/formats

I added the styles button to the toolbar configuration (arrow 1 in screencap), then added a new class to the styles text area (arrow 2 in screencap).

I attempted to add a series of options: 'test-class|test-class', 'test class|test class', 'testclass|testclass', but the first two caused errors. Only the final was accepted (arrow 3 in screencap above).

Add a select element to permission page to allow a more granular presentation of each group of permissions. Make permission loading scale better when many modules are active and for those modules that dynamically create permissions more editable.

• generates path base. ie :
  • by module: admin/people/permission/block
  • by role: admin/people/permissions/role/anonymous/block
• Configurable default. sets 'all ' as default (traditional full permisison list)
• completes missing local tasks
• notice given it Administrator Role is set to role for Per Role selections (as all checkboxes are then disabled)

When using install.php with cookies disabled, you get mysql errors which seem to halt the database population. The installer should not rely on cookies, and if it has to, it should warn the user that cookies must be enabled.

This is a followup to

https://www.drupal.org/project/drupal/issues/2974911#comment-12680705

One minor issue I noticed: I was seeing code coverage results for the src/Tests directory

What this highlights is that this issue was not 100% successful

#2478115: 8% of the files having zero test coverage are incorrectly listed.

The long and the short of this issue is that is a more comprehensive exclusion pattern is needed.

In addition to a case sensitivity issue, classes of this pattern are also incorrectly showing up in the test results.

./modules/simpletest/src/WebTestBase.php

<!-- Exclude all test modules, tests etc -->
      <exclude-pattern>*/tests/*</exclude-pattern>
      <exclude-pattern>*/Tests/*</exclude-pattern>

Plus patterns for any obvious test classes and traits.