Problem/Motivation

We want to deprecate drupal_static() and drupal_static_reset(): #1577902: [META] Remove all usages of drupal_static() & drupal_static_reset()

However, for backwards compatibility, we have to turn drupal_static_reset() into a special case that does not call @trigger_error().

In general, code that calls drupal_static_reset() without calling drupal_static() is very likely needed for BC.

Examples of this include drupal_flush_all_caches() and \Drupal\Core\Test\FunctionalTestSetupTrait::prepareEnvironment().

Proposed resolution

Formally deprecate drupal_static_reset() without calling @trigger_error(), along with documentation explaining why we don't call it.

Find all these usages necessary for BC.

Add @todo and @see for these usages, pointing to the change record: https://www.drupal.org/node/2661204

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

Mile23 created an issue. See original summary.

andypost’s picture

andypost
he/him
Primary language Russian
commented

I think it needs better CR about how to prevent using static cos it brings state to services

claudiu.cristea’s picture

claudiu.cristea
Primary language Romanian
Location Arad 🇷🇴
commented

\Drupal\migrate\MigrateExecutable::attemptMemoryReclaim() needs this call too.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

> \Drupal\migrate\MigrateExecutable::attemptMemoryReclaim() needs this call too.

I'd argue it's fine to drop that without replacement as the chances that there's any memory worth reclaiming is lower and lower.

I'd argue we could just close this and use the approach that you proposed in the main issue for the few calls like this that must still call it.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

nicxvan’s picture

nicxvan commented

I think this is actually not as hard as it initially seems.

Once we deprecate all other instances in core we introduce a special key clear_all.

Then we do this:

if ($name === 'clear_all') {
  drupal_static(NULL, NULL, TRUE);
}
else {
  trigger_error.....
  drupal_static($name, NULL, TRUE);
}

Then the two remaining calls we call with clear_all as the argument and won't trigger the deprecation and all other calls will.