Problem/Motivation

PHP 5.5 will be quite soon out of security support, see https://secure.php.net/supported-versions.php

Proposed resolution

Warn users of php 5.5, so we can remove support for it in a later release.

Remaining tasks

User interface changes

API changes

Data model changes

As discussed previously in #2775587: Mark BigPipe as beta-level stability (instead of alpha), once #2657684: Refactor BigPipe internals to allow a contrib module to extend BigPipe with the ability to stream anonymous responses and prime Page Cache for subsequent visits lands, Fabianx and I want to mark BigPipe stable/non-experimental

The docblock for ArgumentPluginBase::preRenderMoveArgumentOptions() has a spelling mistake:

"shown bellow" should read "shown below"

InvalidArgumentException: $string ("Migration @id is busy with another operation: @status") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct()

This is happening when display($message, $type = 'status') in MigrateMessage.php (core/modules/migrate/src/MigrateMessage.php) receives a non-rendered TranslatableMarkup instance (rather than a string) as the $message from import() in MigrateExecutable.php (core/modules/migrate/src/MigrateExecutable.php, line 168). There are many instances in MigrateExecutable that call display() with a non-rendered TranslatableMarkup instance, resulting in the error above being thrown by the \Drupal::logger(), which expects a string (MigrateExecutable.php lines 127, 168, 184, 207, 284, 303, 475, 491, and 505). In some cases (such as line 284 of MigrateExecutable.php) the InvalidArgumentException prevents the migration from being set back to STATUS_IDLE (line 287), resulting in a stuck migration at STATUS_IMPORTING.

Has anyone else seen these errors?

Problem/Motivation

Follow-up to #2503755: Switch from user login block to login menu link and search block in standard profile

login link has no destination=[current.path], so dumps you on the profile

Proposed resolution

Add destination.

User interface changes

None.

API changes

None. API addition: links can set the data-current-path-destination attribute to automatically get the destination query argument

Data model changes

None.

Why this is an RC target

This is severe UX regression introduced by #2503755: Switch from user login block to login menu link and search block in standard profile

Problem

Currently when a view with a page display customizes its cacheability metadata this is not output by the page controller and the page is not correctly cached.

Only cacheability metadata which is related to query access checks and displaying of contextual links is output. Any other metadata is ignored.

An example: I have a view of which the results are rendered differently if a user is an administrator in Organic Groups. So my view varies by the role my user has in Organic Groups. I alter the view with hook_views_pre_view() and add the 'og_role' cache context to its displays.

When I load the page with cleared caches a correct render cache entry is made in the database, marked with the correct cache context keys. However this cache entry is now never used, since ViewPageController outputs a render array which has a hardcoded set of cacheability metadata which lacks my 'og_role' cache context.

ViewPageController::handle() retrieves a basic array of metadata from Page::buildBasicRenderable() and enriches it by calling views_add_contextual_links(). The actual cache contexts that are present on the View entity are not included.

Proposed solution

We can solve it by storing the cacheability metadata on the router object using custom property like _view_display_cache_contexts. The router object is populated in PathPluginBase::getRoute(). The full entity is loaded at that point so we can retrieve the cacheability metadata and provide it to the router. We can then use these custom properties to output the full cacheability metadata in ViewPageController::handle().

Problem/Motivation

Follow for @todo since #2589967: Rebuild routes immediately when modules are installed landed

    # @todo Remove the '_no_big_pipe' route option when https://www.drupal.org/node/2589967 lands.
    _no_big_pipe: TRUE

and

            // @todo: Switch to Url::fromRoute() once https://www.drupal.org/node/2589967 is resolved.'content' => '0; URL=' . Url::fromUri('internal:/big_pipe/no-js', ['query' => \Drupal::service('redirect.destination')->getAsArray()])->toString(),

Proposed resolution

Remove and see what happens since #2589967: Rebuild routes immediately when modules are installed landed.

I know this is a really specific issue, but it's a mystery that annoys me.

The contextual links menu that allows me to edit articles is only showing up the first time I view it. By this, I mean, if I refresh the page, they will no longer work. If I click the edit tab, save the node and let it return me to the node's view page, they work again. But, then I refresh, and they are broken again.

I've noticed that the `focus` class is appended to the article (on hover) on the page when it works, but not when it doesn't work after being refreshed. I've also noticed by debugging that in StateModel.js and VisualView.js, that toggleOpen happens twice (on the broken version -- after refresh), opening and then closing the contextual links menu. But, I can't figure out why.

The content div, which contains the html for the article & contextual links, is 99% identical in bother versions with the only difference being a changed form-build-id for the comments.

The css/js files loaded on the page when it works/doesn't are nearly identical in both versions, with the only differences being a css file that does 2 unrelated things.

This is on both Firefox and Chrome.

If anyone has any ideas, it would really help me sleep at night.

Updated: Comment #96

Problem/Motivation

I
With Drupal 7's vastly-improved install profile functionality, and the recently-improved drupal.org distribution packaging infrastructure, many new install profiles have been created, and they are awesome.

However, install profiles are not inheritable, so if you want to, say, take Drupal Commons, and base your site off of it, but add one or two extra modules in your own customized install profile, you have to clone the entire install profile and change it to your needs. Allowing install profiles to declare base profiles (just like themes can declare base themes) would allow more code reuse, and make install profiles even more useful.

Proposed resolution

Modify the module load system to take into account base install profiles.

Remaining tasks

• Create plan

User interface changes

None.

API changes

Install profiles can define base profiles using the syntax base: BASE_PROFILE inside their .info.yml files.

Related Issues

• For D7 patch tracking: #2067229: Allow install profiles to declare base profiles for Drupal 7
• For D8 info inheritance patch tracking: #2692403: Make info and configuration inheritable in profiles

Problem/Motivation

Templates can include logic that requires cacheable metadata. Currently this can be done in preprocess why this is only normal task.

Proposed resolution

-

Remaining tasks

-

User interface changes

-

API changes

-

Data model changes

-

By default, access checks will be performed on entity queries, like the one issued from UniqueFieldConstraintValidator. If you were to enable a module that implemented hook_query_TAG_alter() that targeted the access tag for that entity, the validator would only be verifying uniqueness across the field values that the current user can see, not across the whole entity type.

Admittedly, I'm not sure if this is more of a bug or a feature request because I'm not 100% clear on the desired functionality. The class comment says that it "Validates that a field is unique for the given entity type.", which suggests that it should be checking against all the values. But maybe there are cases where you wouldonly want to check against what the current user could view.

Problem/Motivation

A D8 install can easily generate extremely lengthy file/directory names when caching Twig templates.

On some scenarios, the maximum length for a path might be limited by the OS:

• Windows has a maximum path length of 260 characters. Can read more here.
• If you are in Linux and have the filesystem where you have the site mounted using eCryptfs and its configured to encrypt filenames as well as the file content you will experience this same issue. You can read a little about this limitation here.

To reproduce this issue on Windows, add the following to settings.php.

$settings['file_public_path'] = 'sites/default/files/0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-01'; // That's a 255-char dir name.

Proposed resolution

Update as of #144 going with option #3

Option #3: Trigger a requirement error on windows if the Drupal root is deeper than 100 characters. Use our existing base64 hash and hmac functions so the hashes are half as long to start. Truncate the human-readable template name portion and hash portion of the to a maximum length so the directory names can never be longer than 51 characters. The cache file name itself has already been shortened to 47 characters using the bas64 hmac in the split-off child issue #2830596: MTimeProtectedFastFileStorage::getFullPath() creates really long filenames unnecessarily

Update: as of #39, options #2 is the preferred solution.

Option #1: Use the Unicode path prefix (\\?\) on Windows to avoid the 260 character limit (pushes the limit to around 32k which is well above Linux's limit of 4k characters). Unfortunately, PHP's support of these pathnames is limited. (see #16) which would require a much more disruptive fix.

Option #2: Use shorter hashes while retaining the "uniqueness" of these directory and file names. However, the filename hash contains the filemtime() of the containing directory. If, for example, file uploads were compromised and malicious code added to a cached Twig template, the containing directory's filemtime would change and the hash would not match. Using shorter hashes could potentially increase the risk of a compromised file still passing the hash test. (Security review requested).

Also, option #2 does not solve the underlying problem, but hopefully gives us some breathing room. Currently, there are two 64-character hashes in each cached Twig template.

Remaining tasks

As of #12:

1. not needed since we're using option #2: FileStorage::unlink does not work with the Unicode prefix
2. Needs security review to ensure that shortened hashs still give enough "uniqueness" for MTimeProtectedFastFileStorage
3. Needs tests to assert that generated files do no exceed a (somewhat arbitrary) limit
4. Done: Add hook_requirements to warn users when installing Drupal on Windows with a long path name.

User interface changes

Adds a new warning when installing Drupal on Windows at a path > 100 characters.

API changes

With option #2, none.

Data model changes

None.

From a developer experience perspective:
- Checked out 8.1.x
- Made my DB
- Made my settings file
- Visited the site... 500 error in browser with no meaningful details
- Went to apache log, found:
PHP Fatal error: require(): Failed opening required '/var/www/drupal8/vendor/autoload.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/drupal8/autoload.php on line 14

Didn't really understand what I was supposed to do, thankfully I'm at the Midcamp sprint and was told I need to run composer install to get the external deps.

Problem/Motivation

The current status report is informative but not highlighting the crucial information really well. A lot of key information gets lost in the rows of green, blue and other color indicators. From a design point of view this page could also be a lot more appealing.

Proposed resolution

We are looking for designers to pick up this page and propose a view alternatives. Yoroy and Bojhan will be available to guide any designers.

Remaining tasks

• Add default styles for counters and general information #400 to system. Would be nice to get a designers perspective on this.
• CSS clean-up (BEM conversion / remove class nesting)

User interface changes

The information will be separated in 3 regions:

Error counter at top

3 items with error/warning/checked if there are errors. Link to each item list.
Re-count of items checked if no errors. Link to item list.

General system information table

The aim for this region is to show the basic
info about the development environment.

• Drupal version
• Last cron run
• Button to run cron
• Web server info
• PHP info
• Database info

List of reports

• Separated lists by Errors, Warnings and Checked.
• The title for each list should be an anchor for each
  counter in the top regiom.
• On mobile, thedescription is collapsed by default.

Designs

Status page (no errors)

Status page (with errors)

Status page (mobile)

Status page in Bartik

Proposal.

API changes

None

Data model changes

None

Problem/Motivation

Follow-up to #2114823: Update PHPUnit to 4.x

The update to PHPUnit 4 moved the phpunit executable to a different location:

/core/vendor/bin/phpunit

However, the update was performed on a Linux platform, so the phpunit executable installed by Composer is not the executable for Windows.

The above is just a *nix link to phpunit's main shell script:

/core/vendor/phpunit/phpunit/phpunit

...which also happens to work on Windows.

Proposed resolution

Use phpunit from the vendor folder instead of the one if Composer's bin directory, which does not work when extracted from a tarball and generally not on Windows.

Remaining tasks

RBTC

User interface changes

None.

API changes

None.

Data model changes

None.

Original report

Follow-up to #2114823: Update PHPUnit to 4.x

The update to PHPUnit 4 moved the phpunit executable to a different location:

/core/vendor/bin/phpunit

However, the update was performed on a Linux platform, so the phpunit executable installed by Composer is not the executable for Windows.

The above is just a *nix link to phpunit's main shell script:

/core/vendor/phpunit/phpunit/phpunit

...which also happens to work on Windows.

Attached patch

1. fixes the phpunit script command location
2. removes the error suppression for reading the JUnit XML result file, as it only hides an early error condition that blows up later on anyway.

Steps to reproduce

1. Add a date field to an entity and then go to to that form.
2. Fill in an appropriate date.
3. Fill in a time that has a single digit hour, like "8:15:00".
4. Submit the form and receive a validation message along the lines of The Start date is invalid. Please enter a date in the format 12:00:00.

The basic problem is that there's a disconnect between the time that you enter in the form and the time that you submit the form. The error message generates a sample based on the current time. This means that if you submit the form between 00:00:00 - 09:59:59, you will get an error message that pretty clearly shows that the hour format is HH. However, if you submit the form between 10:00:00 - 23:59:59, then the hour would be two digits regardless of whether the hour format is HH or H, so it's not as clear that the hour you entered is in the wrong format.

Possible solutions

1. Try to use the submitted time (formatted correctly) as the sample time. (i.e. strtotime())
2. Use a static time for the sample that is between 00:00:00 - 09:59:59.
3. Rather than a sample time, show the actual format string.
4. Something else I didn't think of. :)

ContentEntityStorageBase::setNewRevision and ContentEntityStorageBase::setDefaultLangcode don't return $this, making them un-chainable.

They should return $this

Hi,
When I install a new module, I end up on this error page :

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

However, the module installation works perfectly, so it's not a big problem, but I think this is a not a normal behavior...
Thx.

Problem/Motivation

#2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method unveiled #2808217: To be able to view Vocabulary config entities via REST, one should not have to grant the 'administer taxonomy' permission. That's for the Taxonomy module's Vocabulary (config) entity type. A similar problem exists for the Term (content) entity type.

Proposed resolution

Add per-bundle "create" permission. The "update" and "delete" cases are less clear. But creating new terms is a very common necessity. Updating/editing and deleting terms is far less common, and is usually an administrator-only task.

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

None.

This issue is intended as a tracking issue only to list all of the known intermittent test failures affecting Drupal core. Some issues are due to bugs in Drupal core; others may be due to issues with DrupalCI infrastructure.

Only open issues should be listed in the summary.

Drupal 8

• #2828559: More random fails in UpdatePathTestBase tests: "settings.cache failed with: missing schema"
• #2754217: Random Test Failure with "failed to open stream"
• #2823400: Random fail in CopyFileTest
• #2806697: Random fail for AlreadyInstalledException
• #2157927: Intermittent test fails in LocaleUpdateTest::testUpdateImportSourceRemote()
• #2828143: Stop NodeTypeTranslationTest from failing if l.d.o becomes unavailable
• #2796757: Failing test with stable version string
• #2565317: MigrateTermNodeRevisionTest test causing a segfault on Drupal-CI (not on local or pifr)
• #2652924: Investigate random php 5.6 failure in core branch tests.
• #2579543: Random segfault in MigrateUserProfileEntityDisplayTest
• #2825845: Unexpected test failure in FilterDateTimeTest
• #2829848: Random test failure in DateRangeFieldTest
• #2830485: \Drupal\Tests\outside_in\FunctionalJavascript\OutsideInBlockFormTest fails randomly
• #2831603: Random fail in testEntityReferenceAutocompleteWidget with Postgres
• May need issue: intermittent fails in JSTB tests

Drupal 7

• #2820962: Investigate random fail in d7 test
• #2762541: PHP 5.5 and 5.6 branch tests fail on Drupal 7 core, even though they pass when run on a patch

If your patch has an unexpected test failure

1. Always click on the test results link to see what tests actually failed.
2. Check the test results on https://www.drupal.org/node/3060/qa. If the same test appears to be failing on the "tested on commit" environments, HEAD may be broken.
3. Most test failures are actually caused by bugs in patches. Even if a failure appears to be random, consider that the patch may be introducing the bug.
4. If the test result says "CI error" or "CI aborted", that generally indicates an issue with the infrastructure and not with the patch. Wait a bit, then requeue the tests for the patch.
5. If the test failure appears to be one of the above known failures, there is no need to add additional reports of it (unless the issue specifically requests so). Usually, once a fail is identified, Drupal.org maintainers can locate other, similar fails in server logs if needed. However, you should document on your issue which specific known issue caused the failure.
6. If there is an unexpected test failure that is not covered by one of the above issues, file a new critical issue and add it to this issue's summary.