Move CSS/JS aggregation settings to "Development settings" form

Hi All,

In order to make this change in Drupal 11's development version, I added this patch.
Here, the aggregation ccs/Js fields have just been transferred from the System Performance form to the Development settings form. Because many core files have been utilising this same system performance config, we have saved the configuration in system.performance itself to make things simpler.

Here is the patch.

I am reviewing this #3 patch

Tried to fix failures in #3.

Before adding #3 patch I have observed that css/js aggregation settings are there in performance form and as mentioned in the summary since drupal 10.1 there is a development form for development settings. Twig debugging , cache settings are there in development form. I have added screenshots for both the observation i.e 1. Development form Before Patch and 2.Performance form Before Patch.

navigate to Admin>configuaration>development>Performance to view performance form
navigate to Admin>configuaration>development>development settings to view development settings form

As per the scope of this issue CSS/JS aggregation settings needs to be moved to development settings form. Installed drupal 11.x on my local and Applied #3 patch on that. As per the scope CSS/JS aggregation settings are moved to development settings form from performance form. patch is working as expected. Attached screenshots of development settings form and performance form for reference. i.e 1. Development form after Patch 2.Performance form after Patch.

Hence suggest to moving this issue to RTBC +

Moving to NW due to test failure.

Also, may be we should make this functionality similar to Twig development mode checkbox, where enabling that checkbox opens the options. Thoughts?

Tried to resolve failed fix.

Continued from the patch from #8 and added the feature for checkbox requested in the #7, which makes sense so as to get a consistent behaviour in the form.Attaching the screenshots with the latest changes.

If any of the fieldset checkbox is checked, then bandwidth_optimization_checkbox should also be checked. Also a test can be written in DevelopmentSettingsFormTest.php for this checkbox as done for other checkboxes.

I have addressed all the feedbacks and also added the testcases.

Think this will need framework review.

Ideally unchecking Bandwidth optimization checkbox and saving form should remove any checked Aggregate CSS files/Aggregate JavaScript files checkbox. This is not happening right now.

This is moving the location of the form, but the development settings form was set up so that it doesn"t require config changes to make the changes. I think this issue should either do a version of that it not move it at all.

Thanks @catch for the background information. I think then we should move config to states in this issue and update issue summary and add CR.
Tags added for CR and IS update.

#17 and `update issue summary and add CR` from #19 still needs to be done.
Apart from that entries exists in system.performance.yml , AssetOptimizationTest.php which needs to be removed.

Also entries exists in migrations and related tests which might also needs to be removed.

Going to leave in review but brought this up in #yes-no-queue and myself and user @Christopher Matthews were -1 to this.

My reason is I don't users are going to assume aggregation is under development over performance.
Also we are now mixing a form of things that will and won't be saved to config. Is that going to clear to new and old users?

Just my 2 cents but won't die on that hill.

The Performance item has this description:

Configure caching and bandwidth optimization.

The Development settings item has this description:

Configure theme development settings

I think, that the aggregation seems to be closer to the bandwidth optimization as this is not primarily related to the development (for example it is for consideration on HTTP/2.0, ...).

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

These areas overlap, which makes it harder ...

Maybe we need to unify them all on a "Performance and development" page?

I do think solving ✨ Easy way to bypass all caching with Drush or settings.php Active would be a much bigger gain for developers.