system.performance.yml no longer considered after update

Created on 16 December 2023, 7 months ago
Updated 18 December 2023, 6 months ago

Problem/Motivation

I currently have a problem after upgrading from 10.1.6 to 10.2.0, the configuration /config/sync/system.performance.yml file is recreated, but it is completely empty. When calling /en/admin/config/development/performance, I get the following error message.

#0 [internal function]: Drupal\system\Form\PerformanceForm->buildForm(Array, Object(Drupal\Core\Form\FormState))
#1 /var/www/html/docroot/core/lib/Drupal/Core/Form/FormBuilder.php(536): call_user_func_array(Array, Array)
#2 /var/www/html/docroot/core/lib/Drupal/Core/Form/FormBuilder.php(283): Drupal\Core\Form\FormBuilder->retrieveForm('system_performa...', Object(Drupal\Core\Form\FormState))
#3 /var/www/html/docroot/core/lib/Drupal/Core/Form/FormBuilder.php(224): Drupal\Core\Form\FormBuilder->buildForm('Drupal\\system\\F...', Object(Drupal\Core\Form\FormState))
#4 /var/www/html/docroot/core/modules/system/src/Controller/PerformanceController.php(24): Drupal\Core\Form\FormBuilder->getForm('Drupal\\system\\F...')
#5 [internal function]: Drupal\system\Controller\PerformanceController->build()
#6 /var/www/html/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#7 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(627): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#8 /var/www/html/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#9 /var/www/html/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#10 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#11 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#12 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /var/www/html/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /var/www/html/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /var/www/html/docroot/modules/contrib/remove_http_headers/src/StackMiddleware/RemoveHttpHeadersMiddleware.php(49): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /var/www/html/docroot/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /var/www/html/docroot/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#23 {main}

I use Config Split as a module so that different environments receive certain settings. But even if I insert and configure the file system.performance.ymlfor the local environment... it is not processed/imported.

Even when I paste the file into the localhost sync folder and try to import it, it seems to be ignored altogether. Can anyone else confirm this behaviour?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

πŸ’¬ Support request
Status

Closed: works as designed

Version

10.2 ✨

Component
ConfigurationΒ  β†’

Last updated 4 minutes ago

Created by

πŸ‡©πŸ‡ͺGermany zcht

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @zcht
  • πŸ‡ΊπŸ‡ΈUnited States cilefen
  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    Does this happen without config split

  • πŸ‡©πŸ‡ͺGermany zcht

    Yes, this also happens if config split is completely deactivated/uninstalled. An empty system.performance.yml file is simply created. If you take the values from a default file and try to import the configuration, the file is simply ignored. if you call up /development/performance since, you get the same error.

    in my configuration with config split, the file is only changed for the stage and production environment. otherwise the configuration file for the locale environment can be managed normally with drupal, not with config split

    the only thing i did: updated drupal from 10.1.6 to 10.2.0 via composer, ran drush updb -y and drush cex -y. the mentioned file is recreated, the only content in the file is { }

    back to drupal 10.1.6 everything works normally again, the ui can be called up, the file has configuration. i'm trying to get to the bottom of the problem here, but so far i don't see a solution.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    Do you have anything in settings.php that is targeting $config['system.performance']?

  • πŸ‡©πŸ‡ͺGermany zcht

    thanks for the idea, yes two settings are set for the local environment, see here:

    // Disable CSS and JS aggregation.
    $config['system.performance']['js']['preprocess'] = FALSE;
    $config['system.performance']['css']['preprocess'] = FALSE;

    but even when removing these, the problem unfortunately remains. after updating to drupal 10.2, running drush updb and drush cex, the system.performance.yml file is simply deleted and therefore no form exists, which of course cannot be generated in the ui.

    even if the file is then restored manually and the configuration is imported via drush cim, this is completely ignored.

  • Status changed to Closed: works as designed 6 months ago
  • πŸ‡©πŸ‡ͺGermany zcht

    Thanks again for the shared consideration, found the problem, it was due to this patch ✨ Allow to validate Apache/Nginx configuration requirement for aggregation folder before enabling aggregation. Needs review . Once the patch is removed, the system.performance.yml remains and everything works normally.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    Thanks for reporting back!

    Hopefully this will help anyone else who has to duckduckgo the problem

Production build 0.69.0 2024