Contrib.social

Flushing all caches seems way too aggressive

Open on Drupal.org →
Created on 11 November 2021, about 3 years ago
Updated 2 March 2023, over 1 year ago

Problem/Motivation

Currently CSS Editor flushes all caches using drupal_flush_all_caches() after saving new CSS from the theme settings form. This is slow but it works when the module is used in isolation. But this can cause issues when used in combination with other modules. At least in one specific use case where we have a custom module that also alters libraries based on (theme) configuration. Our hook_library_info_alter() works fine after a cache rebuild (using Drush) but as soon as we save the theme settings form the implementation is not discovered anymore because a function_exists() during library discovery returns false somehow.

Steps to reproduce

Not sure since the issue is identified in combination with a custom module.

Proposed resolution

When I remove the drupal_flush_all_caches() from _css_editor_theme_settings_form_submit() all works fine. But our custom module and CSS Editor. It works because in our custom code we invalidate the library_info cache tag when the configuration is saved. So our proposal is to replace flushing of all caches by invalidation of the library_info cache tag in CSS Editor too. It should then work both in isolated use and in combination with custom code similar to ours.

Remaining tasks

-
- Review MR
- Merge MR

User interface changes

N/A

API changes

N/A

Data model changes

N/A

🐛 Bug report
Status

Fixed

Version

2.0

Component

Code

Created by

🇳🇱Netherlands ricovandevin

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024