Bug #91263
closeddisableCompression is not respected when CSS are concatenated
0%
Description
I am using this:
page.includeCSS { // some CSS ekkoLightbox = path/to/ekko-lightbox.css ekkoLightbox.disableCompression = 1 }
As such I expect this CSS to be concatenated with any other CSS but not compressed at all, thus simply concatenated.
I am not using any 3rd-party compression tool, Core one.
This CSS (see attachment) is already compressed and contains some comments which are actually needed for embedded resources to be taken into account, this is the reason why I don't want any further compression on it.
Problem is that disableCompression
is only taken into account when CSS (possibly JS?) are NOT concatenated. This originates from \TYPO3\CMS\Core\Resource\ResourceCompressor::concatenateCssFiles:135
where we read
$targetFile = $this->createMergedCssFile($filesToInclude); $concatenatedOptions = [ 'file' => $targetFile, 'rel' => 'stylesheet', 'media' => $mediaOption, 'compress' => true, 'excludeFromConcatenation' => true, 'forceOnTop' => false, 'allWrap' => '' ];
Thus the files to be concatenated are concatenated and afterwards the file is marked as to be compressed.
I would expect each file to be compressed (or not) and then concatenated. Possibly the file would be very slightly less-well compressed, but this would respect the intent of the integrator.
Files
Updated by Garvin Hicking 10 days ago
- Is duplicate of Bug #93184: "includeCSS" with "excludeFromConcatenation" wrongly moved before concatenated file added
- Is duplicate of Bug #82636: concatenation changes include order of CSS files, breaks CSS. added
Updated by Garvin Hicking 10 days ago
- Status changed from New to Closed
I am closing this issue in favor of #93184 and #82636, where in the latter I hope to address that using sitepackages with dedicated frontend buildchains and/or HTTP/2 multiplexing or server-side compression is the more "modern" approach to embedded CSS/JS assets. I hope you can understand the need to collate issues like these, and if they do not find proper "adoption" or get addressed, we need to somehow set a focus that goes along other similar decisions which favor HTTP/2 and not relying on application-level caching.