$ drush

Fatal error: Uncaught Error: Class 'Drush\Config\Environment' not found in D:\wamp64\www\workbench8\vendor\drush\drush\drush.php:62
Stack trace:
#0 D:\wamp64\www\workbench8\vendor\drush\drush\drush(4): require()
#1 {main}
thrown in D:\wamp64\www\workbench8\vendor\drush\drush\drush.php on line 62

----------------

$ composer require drush/drush

Using version ^10.1 for drush/drush
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 28 installs, 0 updates, 0 removals
- Installing webmozart/assert (1.6.0): Loading from cache
- Installing webmozart/path-util (2.3.0): Loading from cache
- Installing webflo/drupal-finder (1.2.0): Loading from cache
- Installing symfony/polyfill-php72 (v1.13.1): Downloading (100%)
- Installing symfony/var-dumper (v4.4.1): Downloading (100%)
Skipped installation of bin Resources/bin/var-dump-server for package symfony/var-dumper: name conflicts with an existing file
- Installing symfony/finder (v4.4.1): Downloading (100%)
Cleaning: symfony/finder
- Installing jakub-onderka/php-console-color (v0.2): Loading from cache
- Installing jakub-onderka/php-console-highlighter (v0.4): Loading from cache
- Installing nikic/php-parser (v4.3.0): Loading from cache
Skipped installation of bin bin/php-parse for package nikic/php-parser: name conflicts with an existing file
- Installing dnoegel/php-xdg-base-dir (v0.1.1): Loading from cache
- Installing psy/psysh (v0.9.12): Loading from cache
Skipped installation of bin bin/psysh for package psy/psysh: name conflicts with an existing file
- Installing container-interop/container-interop (1.2.0): Loading from cache

Installation failed, reverting ./composer.json to its original content.

[ErrorException]
proc_open(): CreateProcess failed, error code - 5

require [--dev] [--prefer-source] [--prefer-dist] [--no-progress] [--no-suggest] [--no-update] [--no-scripts] [--update-no-dev] [--update-with-dependencies] [--update-with-all-dependencies] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [--sort-packages] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--] [
]...

Problem/Motivation

This issue is also being discussed in the Redirect issue queue #3016776: [PP-1] 301 redirects don't contain cache-control header.

TrustedRedirectResponse implements CacheableResponseInterface (by extending from SecuredRedirectResponse). When caching is enabled, and the redirect response status code is anything other than 301, a Cache-Control header is output. However, when the status code is 301 (permanent redirect), no Cache-Control header is emitted.

The lack of a cache-control header on 301 redirect responses means that intermediate CDNs and reverse proxies either don't cache the response at all (for example Akamai respects Cache-Control), or fall back to caching it for a short period (for example Acquia Varnish). Some browsers cache 301 redirects if Cache-Control is missing.

In order for a response to be cached in FinishResponseSubscriber, \Drupal\Core\EventSubscriber\FinishResponseSubscriber::isCacheControlCustomized() has to return FALSE.

  /**
   * Determine whether the given response has a custom Cache-Control header.
   *
   * Upon construction, the ResponseHeaderBag is initialized with an empty
   * Cache-Control header. Consequently it is not possible to check whether the
   * header was set explicitly by simply checking its presence. Instead, it is
   * necessary to examine the computed Cache-Control header and compare with
   * values known to be present only when Cache-Control was never set
   * explicitly.
   *
   * When neither Cache-Control nor any of the ETag, Last-Modified, Expires
   * headers are set on the response, ::get('Cache-Control') returns the value
   * 'no-cache, private'. If any of ETag, Last-Modified or Expires are set but
   * not Cache-Control, then 'private, must-revalidate' (in exactly this order)
   * is returned.
   *
   * @see \Symfony\Component\HttpFoundation\ResponseHeaderBag::computeCacheControlValue()
   *
   * @param \Symfony\Component\HttpFoundation\Response $response
   *
   * @return bool
   *   TRUE when Cache-Control header was set explicitly on the given response.
   */
  protected function isCacheControlCustomized(Response $response) {
    $cache_control = $response->headers->get('Cache-Control');
    return $cache_control != 'no-cache, private'&& $cache_control != 'private, must-revalidate';
  }

Drupal's current behavior was introduced with a change to Symfony\Component\HttpFoundation\RedirectResponse in Symfony 3.2 (Symfony issue). The constructor for RedirectResponse explicitly unsets the Cache-Control header, causing isCacheControlCustomized() to return TRUE, which renders the response not cacheable.

Proposed resolution

Emitting the Cache-Control header for 301 responses would make them cacheable downstream. It also does not make sense to have the temporary redirects (302) be cacheable, while the permanent redirects (301) are not (or at least not explicit).

Initial attempt attached to output Cache-Control on 301 responses by checking if the cache-control header was unset by Symfony.

Remaining tasks

Write tests.

User interface changes

None.

API changes

None.

Data model changes

None.

An issue has been created for Drupal 8 already, but this is for Drupal 7 particularly.

Problem/Motivation

MySQL 8 has been release and includes performance enhancements. It would be nice to integrate those enhancements with Drupal 7.

Proposed resolution

Test a variety of Drupal 7 distributions running with MySQL 8 and fix bugs as they appear.

Remaining tasks

• Add support

User interface changes

• Note during the site install that MySQL 8 is supported.

API changes

N/A

Data model changes

N/A

I have created a workaround patch that serves as a temporary workaround.

Problem/Motivation

Modules that have gone through a lot of changes can accumulate a lot of update hooks and post update hooks over time. This can result in the module.install and module.post_update.php files becoming quite lengthy. After a certain amount of time it may be considered acceptable to remove some of those legacy update hooks (e.g. during major version updates)

There is already a mechanism in core to deal with hook_update_N() functions: hook_update_last_removed().

However, there does not seem to be a corresponding function for hook_post_update_NAME() functions, and I don't seem to see any issues suggesting one in the issue queue.

What this means is you either can't ever delete these post update hooks, or you risk people adding in a post_update hook with the same name that was used previously (which could cause inconsistencies between people who had triggered that old post_update hook before and those who had not).

Proposed resolution

I propose creating a hook_removed_post_updates() function that could be added to a module.post_updates.php file, implemented like this:

function mymodule_removed_post_updates() {
  return ['foo', 'bar', 'baz'];
}

This function could signify that at one point, this module had the following post_update hooks defined, but no longer has them defined:

function mymodule_post_update_foo() {
  // Do all the foo things.
}

function mymodule_post_update_bar() {
  // Do all the bar things.
}

function mymodule_post_update_baz() {
  // Do all the baz things.
}

Then if a user attempts to update perform updates while using a removed post update hook, it throws an exception preventing the user from proceeding. This will help developers realize why their hook_post_update_NAME function isn't running as they're building them.

Remaining tasks

• Get resolution on #3.2 and #3.3
• Needs maintainer feedback
• Needs change record

User interface changes

Update UI will no longer let users proceed if they use a removed post update hook name.

API changes

/**
 * Return an array of disallowed names for hook_post_update_NAME() functions.
 *
 * This can be used to indicate post update functions that have existed in
 * some previous version of the module, but are no longer available. This
 * prevents that name from getting re-used in the future, which has the
 * potential to cause some users to not be able to process the updates.
 *
 * This implementation has to be placed in a MODULE.post_update.php file.
 *
 * @return string[]
 *   Optionally, hook_post_update_NAME() hooks may return a translated string
 *   that will be displayed to the user after the update has completed. If no
 *   message is returned, no message will be presented to the user.
 *
 * @ingroup update_api
 *
 * @see hook_post_update_NAME()
 */
function hook_removed_post_updates() {
  // Example list of names to now disallow in hook_post_update_NAME() functions.
  return ['foo', 'bar', 'baz'];
}

Data model changes

None

Release notes snippet

Added hook_removed_post_updates function

Problem/Motivation

Opening the Drupal 9 branch allows a few things to happen.

1. We can upgrade Drupal's PHP requirements to require Symfony 4 or higher (and Twig etc.)
2. Contrib modules can test against the Drupal 9 branch to ensure they still work
3. We can begin removing deprecated code, and backwards compatibility layers

In order for the Drupal 9 branch to be useful, we need to be able to do the below things soon after the branch is opened.

Proposed resolution

The 9.0.x branch opened alongside 8.9.x according to the normal release schedule.

Must-haves prior to tagging Drupal 9.0.0-alpha1

1. DONE: Contrib modules must be able to test against Drupal 9 without having to make an entire new code branch. #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches and #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning enable this
2. DONE: Make 9.0.x installable without depending on the core compatibility constant and resolve any other test failures: #3087874: [meta] Make 9.0.x branch pass testbot
3. DONE: #3079791: Bump Drupal's minimum PHP version to 7.2 as soon as 9.0.x is branched (a higher version may be required later)
4. Update Drupal's major PHP dependencies:
   1. DONE: #3088369: Update Drupal 9 to Symfony 4.4-dev
   2. DONE: #3094007: Update the 9.0.x branch to Symfony 4.4-beta2
   3. DONE: #3088754: Update to Drupal 9 to Symfony 4.4.0
   4. DONE: #3041076: Update Drupal 9 to Twig 2
   5. DONE: #3094146: Update Drupal 8 to the latest stable/compatibe Symfony 3.x versions
5. Remove deprecated dependencies:
   • DONE: #3087685: Remove deprecated jQuery UI components and fork remaining source code into core
   • DONE: #3067216: [meta] Deprecate (in 8.8) and remove (in 9.0) polyfills that are no longer needed
6. DONE: #3016471: Make localization file download major version agnostic
7. #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

Once these issues are resolved, a Drupal 9 branch becomes useful, because it allows for contrib testing of the upgrade path and updated dependencies. The release notes for the alphas will specify that deprecated code has not yet been removed entirely and that any use of deprecated code by contrib/sites will be incompatible by beta1.

Requirements for beta1 are at #3079680: [META] Requirements for tagging Drupal 9.0.0-beta1.

Should-haves

• #3094007: Update the 9.0.x branch to Symfony 4.4-beta2
• #3073936: [policy, no patch] Policy for Drupal 10 deprecations
• #3075954: Remove duplicate scaffold files
• #3091418: Update composer dependencies on 9.0.x
• #3099876: Establish a packaging pipeline queue

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

As part of #3094468: [plan] Update core JavaScript (and CSS) dependencies prior to 9.0.0-beta1 we need to update popper.js to 1.16.0
https://github.com/popperjs/popper.js/releases

Proposed resolution

Update it

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Imagine we generated this config file programatically:

system.theme.yml:

admin: seven
langcode: en
default: starterkits

In active config we have:

admin: seven
default: starterkits
langcode: en

The order is not the same but keys and values are fine, however drupal tell me that there are differences.
I check the code in core/lib/Drupal/Core/Config/StorageComparer.php:

  protected function addChangelistUpdate($collection) {
    $recreates = [];
    foreach (array_intersect($this->sourceNames[$collection], $this->targetNames[$collection]) as $name) {
      $source_data = $this->getSourceStorage($collection)->read($name);
      $target_data = $this->getTargetStorage($collection)->read($name);
      if ($source_data !== $target_data) {
...

This line if ($source_data !== $target_data) {, compares by identity:
$a === $b is TRUE if $a and $b have the same key/value pairs in the same order and of the same types.

If we change from:

if ($source_data !== $target_data) {

to:

if ($source_data != $target_data) {

Drupal do not see changes with the example shown above, how I expect.

We compare by equality:
$a == $b is TRUE if $a and $b have the same key/value pairs.

Here i upload a patch for that.

What do you think?

Source:
https://www.php.net/manual/en/language.operators.array.php
https://stackoverflow.com/questions/5678959/php-check-if-two-arrays-are-...

Currently you are able to allow a user to select from multiple view modes when embedding media; however, this list when embedding is not respecting if a view mode is enabled for that particular type.

For example: I have an Image media type and a Video media type, both have "Embedded" displays but only Image has a "Thumbnail" Display. Both displays are allowed in my CKEditor profile. When adding a video, it allows me to select "Thumbnail" which is not enabled, causing the Video to fallback to the "Default" display.

This is not intuitive and confusing for users.

One deprecated library in Stark and one deprecated preprocess function in Stable.

Deprecated code in the Twig theme engine is being handled in #3011393: Remove twig_without() and manual inclusion of twig.engine TwigEnvironment

After upgrading to 8.8 i keep getting unexpected error.

$config['system.logging']['error_level'] = 'verbose'; is added to the settings.php, still no more information.

After I updated the core manually I got the following error:

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.path_alias' doesn't exist: SELECT 1 AS expression FROM {path_alias} base_table WHERE (base_table.status = :db_condition_placeholder_0) AND (base_table.path LIKE :db_condition_placeholder_1 ESCAPE '\\') LIMIT 1 OFFSET 0; Array ( [:db_condition_placeholder_0] => 1 [:db_condition_placeholder_1] => /node% ) in Drupal\Core\Path\AliasRepository->pathHasMatchingAlias() (line 111 of core/lib/Drupal/Core/Path/AliasRepository.php)

Then I tried to uninstall the Pathauto module. Since there is no detailed error, just "The website encountered an unexpected error. Please try again later."

I probably messed something up with Pathauto, but version 1.6 was installed before the core update.
Do you have any idea, where should I start? All the updates were made manually.

Problem/Motivation

In order for a contrib project to be testable on Drupal 9 all the modules need to be marked as D9 compatible. This makes sense for the *real* modules provided by the project but it does not make sense for test modules.

Proposed resolution

Allow modules that are in the Testing package to default to the Drupal version under test.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a - well we could do one but it doesn't feel that important.

Problem/Motivation

Something in phpspec/prophecy 1.10.0 makes our tests fail on php7.3

They were passing previously

See https://github.com/phpspec/prophecy/compare/1.9.0...1.10.0
And https://github.com/phpspec/prophecy/pull/446

https://github.com/phpspec/prophecy/pull/446 changed the way that comparison for the default token (ExactValueToken) is done for closures.

With prophecy, when you do this:

$this->prophesize(Some:class)->someMethod($some_argument);

Internally it turns $some_argument into new \Prophecy\Argument\Token\ExactValueToken($some_argument) and then calls \Prophecy\Argument\Token\ExactValueToken::scoreArgument which now returns false if the comparator throws a ComparisonFailure

For closures, the comparator used is \Prophecy\Comparator\ClosureComparator which always throws a ComparisonFailure

Proposed resolution

The fix, is to use the long-form and instead of using the default ExactValueToken, use Argument::is() which maps to \Prophecy\Argument\Token\IdenticalValueToken which just does a straight equality comparison, which is fine for the two closures in the test that are broken.

The code we're calling in core that is failing

$this->decoratedFormState->prepareCallback($unprepared_callback)
      ->willReturn($prepared_callback)
      ->shouldBeCalled();

    $this->assertSame($prepared_callback, $this->formStateDecoratorBase->prepareCallback($unprepared_callback));

Where in this scenario, $unprepared_callback and $prepared_callback is a closure, causing the fail.

We actually expect direct equality here, so we should use Argument::is

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I couldn’t find any similar issues on Drupal.org so I opened this one, if anyone knows of a similar issue please feel free to link and close this as duplicate.

Problem/Motivation

This was found while diagnosing an issue on the Scheduler module. However it also affects the “Authored On” field.
https://www.drupal.org/project/scheduler/issues/3085947

The node edit form's "Authored On" field uses the timezone of whatever user was on that form during the last cache clear. This can end up with a Chicago User saving a node that has an “Authored On” value in UTC.

This only seems to affect new nodes, editing existing nodes are not affected.

Steps to Reproduce
Requirements: Have two users, one with a UTC timezone and one with a Chicago Timezone

Step One: Create content as an UTC User

1. Log in as the UTC user
2. Clear the Drupal cache
3. Create a new Basic Page
4. Note the Authoring information (e.g 4:00:00 PM)
5. Save and publish the node.

Step Two: Create content as a Chicago User

1. Log in as the Chicago user
2. Do not clear the cache
3. Create a new Basic Page
4. Note the Authoring information
5. Observe that the Authoring information shows approximately the same time at UTC (e.g 4:02 PM)
6. This should show a time relative to Chicago (e.g 11:00 AM)

For authoring information this is relatively benign however it does impact Scheduling.

Proposed resolution

It looks like this is being caused by code in the Datetime::getInfo() method.

core/lib/Drupal/Core/Datetime/Element/Datetime.php

public function getInfo() {

      // .. node: some code removed for brevity …

     return [
      '#input' => TRUE,
      '#element_validate' => [
        [$class, 'validateDatetime'],
      ],
      '#process' => [
        [$class, 'processDatetime'],
        [$class, 'processAjaxForm'],
        [$class, 'processGroup'],
      ],
      '#pre_render' => [
        [$class, 'preRenderGroup'],
      ],
      '#theme' => 'datetime_form',
      '#theme_wrappers' => ['datetime_wrapper'],
      '#date_date_format' => $date_format,
      '#date_date_element' => 'date',
      '#date_date_callbacks' => [],
      '#date_time_format' => $time_format,
      '#date_time_element' => 'time',
      '#date_time_callbacks' => [],
      '#date_year_range' => '1900:2050',
      '#date_increment' => 1,
      // Timezone is set here and gets cached. 
      '#date_timezone' => drupal_get_user_timezone(),
    ];
} 

The getInfo() method only gets called on cache clear, therefore the element that gets loaded gets the timezone of whichever user loads the page after the cache is cleared.

It looks like this was introduced as part of: https://www.drupal.org/project/drupal/issues/2799987

Problem/Motivation

My scenario involves the placement of a views block in layout builder for a content type. During the rendering process, section and section component information is not available once the views block build method is called. I need the ability to inject the section layout ID and the component region values into the views result row/item before it reaches an implementation of hook_preprocess_node().

Proposed resolution

After much digging, I found the SECTION_COMPONENT_BUILD_RENDER_ARRAY event. Using that event and a new one for SECTION_BUILD_RENDER_ARRAY, an event listener can be used to store the information needed in drupal_static() that can be accessed in the implementation of hook_preprocess_node().

Remaining tasks

Add tests.

User interface changes

API changes

Data model changes

Release notes snippet

When the workspaces module is already enabled, I can't update core to 8.8.0 and enable path_alias because WorkspacesAliasRepository.php throws an error Error: Class 'Drupal\path_alias\AliasRepository' not found in include() (line 10 of /var/www/html/docroot/core/modules/workspaces/src/WorkspacesAliasRepository.php)

A workaround is:

1. delete all workspaces in 8.7.x
2. disable the workspaces module
3. update core to 8.8.0
4. enable the path_alias & workspaces modules
5. re-add workspaces

but that is less than ideal.

Hello all, it’s time for the weekly migration initiative meeting. The meeting will take place in slack in various threads

This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to here.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Problem/Motivation

When adding / configuring an entity reference field, the selection config options expose a "Sort by" whose purpose / meaning is not very intuitive:

Proposed resolution

Improve the wording and/or add a description for that setting.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

- Update from Drupal 8.7 to 8.8
- Run drush updb (you get the same error using update script)
- Note the failure on views_post_update_limit_operator_defaults, with error

Fatal error: Cannot redeclare Drupal\views\Plugin\views\field\LinkBase::$languageManager in /Users/tmiller/Sites/drupal
/intelligrated/web/core/modules/views/src/Plugin/views/field/LinkBase.php on line 59

However I have now updated 5 sites to Drupal 8.8 and this did not occur on every site, only on two of those. Far as I can tell the common element between these two is that we are using Translations on these two, but not on the other 3.

I was able to get the update to finally apply cleanly by commenting out the duplicate declaration of $languageManager in the noted file. However, I also had to comment out 3 other duplicate declarations for getEntityTypeId(), getLanguageManager(), and getView() in this same file.

Proposed resolution

Seems likely the resolution is to just remove the duplicate declarations.

I'll put together a patch shortly that removes these.

See:

• https://www.drupal.org/SA-CORE-2016-003
• http://cgit.drupalcode.org/drupal/commit/?id=17ff00c
• https://httpoxy.org/

Drupal 7 core is not vulnerable, but porting the fix in .htaccess/web.config files would mitigate the issue when using vulnerable libraries or vulnerable code.

Credit for the D8 version of this patch (the security release):

alexpott, Michael Dowling, mlhess, xjm, Pere Orga, dawehner, greggles, coltrane, pwolanin, larowlan

Problem/Motivation

At the moment there is no generic revision UI, this means that every module with revisionable entities will need to create their own UI similar to the Node revision overview page (node/{node_id}/revisions. This means quite a bit of boilerplate code, especially for modules with multiply revisionable entities.

Proposed resolution

Create a BaseRevisionOverviewController for deleting a revision or reverting to a revision.

Remaining tasks

• Decide if we want to improve this in core
• Create a plan
• Implement the plan