In #1646580: Implement Config Events and Listeners, and storage realms for localized configuration we implemented a system of events and listeners for implementing overrides of config data (for instance for the purposes of internationalization.) A couple of open questions came out of that discussion

- How should we prioritize core implementations? These will run in a 'last executed wins' system when two listeners save to the same config data, so what should the priorities be?

- We also need to figure out priorities of the events within the systems. beejebus from that issue: "we have to consider both the priority of listeners within an event, and the order of different events across an object. so, as the patch stands, locale overrides override global conf overrides. perhaps we should collapse both of these subsystems to use the same event, something like 'config.override'?"

Comments

sun’s picture

Title: Figure out priorities for config listeners » Figure out priorities for config event listeners
Issue tags: +Framework Initiative, +WSCCI, +Configuration system, +symfony

I actually think this issue goes far beyond the configuration system, and applies to all subscribed event listeners throughout Drupal... tagging appropriately.

Crell’s picture

When registering a symfony event in the subscriber class you can specify a priority, which will determine the order in which they get called. (It's priority, not weight, because it orders backwards from Drupal's normal "negative first" ordering, I believe. So it goes.) So if you care, you can set your listener directly. (aka, this is per-hook weights, as we've always wanted.)

Eronarn’s picture

I found something interesting in the Symfony docs: http://symfony.com/doc/2.1/cookbook/service_container/event_listener.html

There is an additional tag option priority that is optional and defaults to 0. This value can be from -255 to 255, and the listeners will be executed in the order of their priority. This is useful when you need to guarantee that one listener is executed before another.

We're already violating this guideline elsewhere (#1964482: Non-canonical Symfony priority in LanguageRequestSubscriber). We should avoid doing it here.

Crell’s picture

Issue summary: View changes
Issue tags: -WSCCI

I don't know why this was tagged WSCCI...

dawehner’s picture

@crell
Well, the point made by sun is that priorities made by core aren't that unimportant, so thinking about it in general might be a good idea.

Crell’s picture

Sure, auditing our priorities to make sure they're logical is fine. But that has nothing to do with web services. :-)

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.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.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.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.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.