Problem/Motivation

+++ b/core/includes/config.incundefined
@@ -99,6 +108,54 @@ function config($name) {
+function config_context_enter($context_name) {
+  if (drupal_container()->has($context_name)) {
+    $context = drupal_container()->get($context_name);

Could move to a container-aware service.

Proposed resolution

Move to a container-aware service.

Remaining tasks

  • implement the move

User interface changes

No UI changes.

API changes

Yes?

Original report by @catch

Follow up for #1763640-207: Introduce config context to make original config and different overrides accessible and #212

+++ b/core/includes/config.incundefined
@@ -99,6 +108,54 @@ function config($name) {
+function config_context_enter($context_name) {
+  if (drupal_container()->has($context_name)) {
+    $context = drupal_container()->get($context_name);

@catch:

This looks like it could move to a container-aware service?

#212
@alexpott:

@catch said on irc that moving config_context_enter() to a container-aware service could be explored in a later patch.

Comments

YesCT’s picture

Gábor Hojtsy’s picture

#1763640: Introduce config context to make original config and different overrides accessible landed now. It would be great if @catch could elaborate on this suggestion. I understand it is about making the function be able to work with a container provided as an argument (such as for testing?). Is that the suggestion?

Gábor Hojtsy’s picture

Status: Postponed » Active
tim.plunkett’s picture

It could just be a means of returning a context-driven config factory. But it so uncommonly used so far, we should just have everyone get it injected.

Taken from #1925660: Convert system's system_config_form() to SystemConfigFormBase:

  /**
   * Constructs a \Drupal\system\Form\CronForm object.
   *
   * @param \Drupal\Core\Config\ConfigFactory $config_factory
   *   The factory for configuration objects.
   * @param \Drupal\Core\Config\Context\ContextInterface $context
   *   The configuration context used for this configuration object.
   */
  public function __construct(ConfigFactory $config_factory, ContextInterface $context) {
    $this->configFactory = $config_factory;
    $this->configFactory->enterContext($context);
  }

  /**
   * Implements \Drupal\Core\ControllerInterface::create().
   */
  public static function create(ContainerInterface $container) {
    return new static(
      $container->get('config.factory'),
      $container->get('config.context.free')
    );
  }
alexpott’s picture

I like the look of #4 - makes sense and is clean... once all forms are converted to ConfigFormBase we can get rid of config_context_enter()

alexpott’s picture

#1938338: Replace drupal_container() in Configuration system actually cleans up config_context_enter to use Drupal::service()

Gábor Hojtsy’s picture

Does that help with this issue or makes this a duplicate? :)

alexpott’s picture

Status: Active » Closed (won't fix)

re #7 I was undecided... I think we should won't fix this issue due to #1924990: [meta] Convert all of system_config_form() to SystemConfigFormBase and #1938338: Replace drupal_container() in Configuration system... it may well be possible to completely remove config_context_enter() once all the forms are converted. Or we might choose to have a procedural function as a helper and the version in #1938338: Replace drupal_container() in Configuration system is what we want.