Seems we need to clear some caches on form save

Created on 12 February 2025, 2 months ago

Problem/Motivation

Seems we need to clear some caches on form save, otherwise the cron seems to read the old config values, until cache is cleared.
Unsure what to clear... any ideas?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

🐛 Bug report
Status

Active

Version

1.0

Component

Code

Created by

🇩🇪Germany Anybody Porta Westfalica

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

Comments & Activities

  • Issue created by @Anybody
  • 🇩🇪Germany Anybody Porta Westfalica

    @grevil any suggestion which it should be? Container maybe?

  • 🇩🇪Germany Anybody Porta Westfalica
  • 🇩🇪Germany Grevil

    Could also be \Drupal::cache('config')->invalidateAll();.

    It would even be better, if we could directly invalidate the user_registration_reminder config, although I am unsure how to do this, as "invalidate()" requires a cache id. Might be the same as the settings id, or this is used for an entirely different "config". Not sure, we should test this.

  • 🇩🇪Germany Anybody Porta Westfalica

    Thanks @grevil I think other modules should have the same issue in their config forms? I'm even wondering why core doesn't handle this through https://git.drupalcode.org/project/user_registration_reminder/-/blob/1.x...?

    Or do we have a typo or mistake somewehere?

    Maybe this helps? https://www.drupal.org/node/2406455

    But thb. I don't even understand why this is cached at all, I mean this is not about a render array or something... and we're changing config through Drupal's API - so the API should be able to handle this.
    Maybe we should first ensure this is really a caching issue...

  • 🇩🇪Germany Grevil

    This could be interesting!

          $email_update_status_emails = $form_state->getValue('enable_update_status_emails');
          if ($email_update_status_emails) {
            // Reset the configuration factory so it is updated with the new module.
            $this->resetConfigFactory();
            $this->config('update.settings')->set('notification.emails', [$account_values['mail']])->save(TRUE);
          }
    

    (From SiteConfigureForm(), "submitForm()" in core)

  • 🇩🇪Germany Grevil

    Hm... or maybe not, not idea...

    The implementation suggests, that this won't help:

      /**
       * Resets the configuration factory.
       */
      public function resetConfigFactory() {
        $this->configFactory = NULL;
      }
    
  • 🇩🇪Germany Anybody Porta Westfalica

    Mhm I really don't think that should be needed...

    Okay for now let's postpone this until we have an idea what needs to be done in detail and why. The effect is minimal, I think.

  • 🇩🇪Germany Grevil

    This is what AdminToolbar does in their settings form:

        parent::submitForm($form, $form_state);
        $this->cacheMenu->invalidateAll();
        $this->menuLinkManager->rebuild();
    

    So honestly, I would start with \Drupal::cache('config')->invalidateAll(); and then give some other potential cache bins a shot:
    https://gitlab.com/webksde-public/drupal/drupal-snippets/-/snippets/3636....

Production build 0.71.5 2024