Performance page provides incorrect/incomplete information about CSS and JS compression

I can confirm that the patch in the summary changes the text for the user in a Drupal 8.x-dev installation from March 6, 2013 to "Aggregate CSS Files". See screenshots.

Nice catch. :)

Committed and pushed to 8.x. Thanks!

I don't understand this patch. When I click the checkbox the files are gzipped and when I unclick it they aren't. So what was wrong with the original label?

The fact that there is a second variable does mean there's like a 1% use case where this isn't true but I think it's fine for our UI text to be optimized for the 99% :)

So it seems to me like we should roll this back, but then again at least it made the labeling consistent between CSS and JS (which as far as I know behave in an exactly parallel way).

So here is one way to fix it for both.

Well, I guess with a little extra effort we can make it work for the 1% too...

I'd be happy with either of these personally, though I guess the second one is technically more correct.

Hm, is that setting really common enough that it's worth exposing a UI for? (Also keep in mind that regardless of what those checkboxes say, compression won't happen if the zlib extension isn't available.)

By the way, it turns out that the second patch I posted above doesn't work correctly - the text never changes even if you edit the variables in settings.php. I believe that is because of #1934152: FormBase::config() and ConfigFormBase::config() work entirely differently, may result in unexpected side effects and I left a comment there.

I agree with David - I can't think of a situation where you would want to supress gzip of css/js alone - it works reliably out of the box and sites with unique needs tend to switch out the whole subsystem (advagg style) anyway.

This form is in the process of being converted to use SystemConfigFormBase (#1925660: Convert system's system_config_form() to SystemConfigFormBase) so any followup patches here may need a reroll depending on timing.

And revising title to try and avoid some confusion. I know this isn't a long issue, but regardless of the number of comments, it's still confusing when follow-up patches are added after the issue is fixed.

Or, quoting @xjm in #680546-100: Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield):

We really shouldn't reopen issues for non-rollbacks.

And now back to your regularly scheduled programming :)

Sure, we could roll it back like I was originally thinking and then try again from scratch, but it's not really a followup. The checkboxes were wrong before and they're still wrong now :)

Or I guess now that they don't mention compression at all, you could say they're not technically wrong, just providing less information. But I think CSS/JS compression is an important technical detail to mention correctly on the performance page.

Actually I just ran the site again, and I think this issue is already fixed. We have 2 different Checkboxes:

- Aggregate CSS files.
- Aggregate JavaScript files.

Will propose to review this on today's UX meeting.

I've also tested this issue but its fixed now.
There are two different check boxes names as:
- Aggregate CSS files
- Aggregate JavaScript files

PFA the screenshot for the same.

@alexpott we didn't since back then the meeting was almost all about adopting ReactJS and another issues.

@vulcanr: Do you still want to raise this at a UX meeting? Or can we close this since the UI text itself is now correct anyway?

I think that if it's correct now, this issue could be closed. I have been out from the UX meetings for a while because of schedule reasons.