'stale_file_threshold' is not a supported key

abhishek_gupta1 → made their first commit to this issue’s fork.

@Mehrdad201 which Drupal 10 version have you installed? I've noticed a similar issue 🐛 'ipless' is not a supported key. Active happened after 10.2 update.

@Orkut Murat Yılmaz I am using the latest version. 10.2.0

A member with id @apaderno has explained this error in stack exchange.

here is his explanation:

The issue is in the Advanced CSS/JS Aggregation module that, in its SettingsForm::submitForm() method, sets the stale_file_threshold value in the system.performance configuration object.

The issue is in the Advanced CSS/JS Aggregation module that, in its SettingsForm::submitForm() method, sets the stale_file_threshold value in the system.performance configuration object.

$this->config('system.performance')
  ->set('stale_file_threshold', $form_state->getValue('stale_file_threshold'))
  ->set('css.gzip', $form_state->getValue('css_gzip'))
  ->set('js.gzip', $form_state->getValue('js_gzip'))
  ->save();

Drupal core validates the configuration objects with schema files like system.schema.yml; since stale_file_threshold is not defined in that file, Drupal reports an error.

This can only be fixed by the project maintainers. The module should not write a configuration value the System module does not recognize in its configuration object.

It is fine to change the css.gzip and the js.gzip values because the configuration schema defines both of them, but adding new values just causes errors like the one you saw.

@OrkutMuratYılmaz The error should appear even with Drupal 9 or Drupal 8.

@Mehrdad201 and @apaderno, thank you both. I'm understanding the concept of Drupal configuration object better now.

@OrkutMuratYılmaz you are welcome my friend.

The PR is correct. It even adds the new configuration value to the .schema.yml file.

Hi everyone,

Thanks a lot for raising this issue and for providing an explanation on the issue at #4, it's greatly appreciated.

Sorry for not having replied in this ticket earlier, but I thought I could go ahead and make the necessary changes in this ticket's merge request directly, which seems to have already been kindly reviewed at #10.

Based on what I understood from #4, it seems it is no longer possible to make changes to another configuration object if this one validates against a schema, which seems to be the case with core config objects now.
Therefore, the simplest viable solution that I could find was to move the configuration key stale_file_threshold out of core system.performance to module's configuration advagg.settings.

As mentioned in the previous comment, these changes have been processed and are ready to be reviewed or tested by a maintainer in merge request 35.
Otherwise, if you would like to apply the changes through composer patches, the following diff URL seems to work fine:
https://git.drupalcode.org/project/advagg/-/merge_requests/35.diff

We would greatly appreciate if you could please try testing the changes and give us your comments and feedback, in particular whether this approach of moving the config key could work for the module advagg.
In any case, feel free to let us know if you have any questions or concerns on any aspects of this MR or this ticket in general, we would be glad to help.
Thanks in advance !

Adding related issue 📌 Remove the aggregate stale file threshold and state entry Fixed : config key stale_file_threshold was removed in 10.1, in particular, see comment #3301573-61: Remove the aggregate stale file threshold and state entry → , where it seems the config key was removed "too" early and should have been deprecated instead (which could have allowed the module to transition smoothly with this change, instead of breaking the form submission with this ticket's error message).

So apparently, this issue should only appear with versions 10.1.x and above. Versions below should still have have the config key stale_file_threshold in core's system.performance (similar to what we currently have for css.gzip and js.gzip).

I couldn't find an associated change record though.

Thanks in advance for your feedback and comments !

After applying the patch, installing Advagg, uninstalling it and the removing it with Composer, I still get error message: 'stale_file_threshold' is not a supported key.

Do we have any other way of removing it from Drupal's config?

Drupal 10.2.0.

Thanks.

Szy.

@DYdave You are right. The only change record created for that issue is AssetCollectionOptimizerInterface::getAll() is deprecated → , which does not say anything about configuration object values; it only say something about state values (which are different).

@szy The PR adds an update hook that clear that value. Did you run update.php after applying the patch?

@apaderno, update via update.php and update via drush were not triggered.

drush updb
 [success] No pending updates.

Yes, I've applied the patch, I've even copied the file's code from the repository to be sure. Removed/required with composer, cleared the cache, etc.

Szy.

Hey @DYdave,
According to #11 comment here's a patch that can help for composer patch install.

Regards,
Abdel

Thanks a lot everyone for the great feedback and follow-up on this issue.

Thank you very much Alberto (@apaderno) for the clean-up and review in the PR, it's greatly appreciated.

Szymon (@szy), I'm afraid this looks like an issue with Drupal Core....
With a little bit more digging, I was able to find the following relevant ticket : 🐛 Deprecate system.performance stale_file_threshold Fixed
with the corresponding MR: Add stale_file_threshold back deprecated.
https://git.drupalcode.org/project/drupal/-/merge_requests/5918

In other words, Szymon, if you upgrade to 10.2.1 (https://git.drupalcode.org/project/drupal/-/commits/10.2.1, see commit 9fb6b609), just released today, then the issue should be fixed in your project.

Otherwise, you could also just go for the corresponding patch, if you don't want to update:
https://git.drupalcode.org/project/drupal/-/merge_requests/5918.diff

As for the current patch (MR!35) and ticket, as far as the advagg module is concerned, I suppose it probably still stands, as it still makes sense to anticipate the deprecation of the key stale_file_threshold (removed in 11.x), which seems to still be used by the module, corresponding to a settings form field whose value is used in module's cron....
It would seem to make sense to move the key over to module's config advagg.settings.

One thing though, I'm not sure exactly how the patch would impact versions prior to 10.1, since they'd have the key in two different config objects (values in two places)....
So perhaps creating a new minor release/branch for the patch (6.1.x?), along with a version constraint would be necessary?
(Imagine someone on 10.0 or 9.x using advagg, with this patch, once it's included in a stable release, for example)
I'm not sure exactly how the key stale_file_threshold is used by core prior to being deprecated... if it isn't used anymore from a specific version, then it shouldn't be a problem to ignore it (which I would suppose is the case, but probably to be further confirmed/tested).
 

In any case Szymon, feel free to let us know if you're still stuck with this issue, we'd be glad to suggest other solutions (drush, manual import/export of config, etc....) or work-arounds.

Would be glad to hear your testing feedbacks and comments on this last point, concerning the version constraint, and of course, the patch in general.
Once again, thank you all very much for your follow-ups and much appreciated contributions.
Cheers!