Project

General

Profile

Actions

Bug #85162

closed

form.css compression in BE not working when TYPO3 is in a subfolder

Added by Presedo Roberto almost 6 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Won't have this time
Assignee:
-
Category:
Backend User Interface
Target version:
-
Start date:
2018-06-06
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
8
PHP Version:
7.1
Tags:
Complexity:
easy
Is Regression:
Sprint Focus:

Description

With TYPO3 in a subfolder (let's say http://www.mysite.com/subfolder/typo3) and CSS files of the backend compressed, the EXT:form/Resources/Public/Css/form.css is not found and the resulting compressed file is empty.

\TYPO3\CMS\Form\Controller\AbstractBackendController::resolveResourcePaths should return array(0 => 'typo3/sysext/form/Resources/Public/Css/form.css') but returns array(0 => '/subfolder/typo3/sysext/form/Resources/Public/Css/form.css')

This is passed to \TYPO3\CMS\Core\Page\PageRenderer::doConcatenateCss which passes the cssFiles list to \TYPO3\CMS\Core\Resource\ResourceCompressor::concatenateCssFiles. Here the file is not found and an empty compressed file is generated.

The rest of BE CSS files are rendered correctly. Forms css files are declared in EXT:/form/Configuration/Yaml/FormEditorSetup.yaml:10. As this is declared in a YAML file, maybe the CSS compression is using a different process which handles this differently.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #90689: ResourceCompressor can't deal with paths relative to docroot (Reoccurrence)Closed2020-03-09

Actions
Actions #1

Updated by Presedo Roberto almost 6 years ago

When on BE debug mode, no compression, no problem

Actions #2

Updated by Benni Mack almost 6 years ago

  • Target version changed from 8.7.15 to 8.7.19
Actions #3

Updated by Susanne Moog over 5 years ago

  • Target version changed from 8.7.19 to Candidate for patchlevel
Actions #4

Updated by Georg Ringer about 4 years ago

  • Related to Bug #90689: ResourceCompressor can't deal with paths relative to docroot (Reoccurrence) added
Actions #5

Updated by Markus Klein about 4 years ago

  • Status changed from New to Closed
  • Priority changed from Should have to Won't have this time
  • Target version deleted (Candidate for patchlevel)

We are solving this issue for newer versions with #90689.
I close this report therefore.

Actions

Also available in: Atom PDF