Bug #25303
closed
js/iecompatibility.js inclusion triggers compressor bug
0%
Description
When the linkvalidator modfunc is shown via Web-Info the log is filled with:
Core: Error handler (BE): PHP Warning: filesize(): stat failed for /var/www/conet/htdocs/typo3/atibility.js in /var/www/conet/htdocs/typo3_src-4.5.2/t3lib/class.t3lib_compressor.php line 342
In linkvalidator the BACK_PATH is set correctly. It also adds 3 JS files that are correctly compressed.
The problem lies in the template lib. linkvalidator creates an instance of template and calls setModuleTemplate(). In this method, $this->loadJavascriptLib('js/iecompatibility.js') is called, which calls $this->pageRenderer->addJsFile($this->backPath . $lib);
BUT the backpath is set only in insertHeaderData() which is for FE only!
Can the loadJavascriptLib() call be removed from setModuleTemplate(). According to my debug out iecompatibility.js was already added to the JS list before. If not, is there a way to automatically detect the backPath if the method is called from BE? A third option would be to add a setBackPath() method which has to be called from each BE module that uses the template lib, but this is not so nice...
(issue imported from #M17918)
Updated by Ingo Pfennigstorf over 13 years ago
- Target version deleted (
0)
This maybe also results in not having a scrollable Viewport. When there are many broken links you can't scroll down or even use any paginator.
In the Error log:
Core: Error handler (BE): PHP Warning: filesize(): stat failed for /var/www/w3s/htdocs/typo3/atibility.js in /data/www/typo3/typo3_src-4.5.2/t3lib/class.t3lib_compressor.php line 341
Updated by
Updated by Tomasz Krawczyk over 13 years ago
I have the same warnings in the php log file and in the BE. My environment is: TYPO3 v 4.5.3, PHP 5.3.6 OS: Windows Server 2003, IIS 6. My warnings occur when functions filesize() and filemtime() are used in class.t3lib_compressor.php line 341. It happens not only with atibility.js file but also with many other js and css files.
The PHP documentation sais that those 2 functions fail when file doesn't exist. So, I made simple test. When I made test.php file executing filesize() and filemtime() with non existing file as a parameter then I saw the same warning. There is no warning if the file exists.
In my xclass in the t3lib_compressor::compressJsFile() and t3lib_compressor::compressCssFile() methods I changed fourth line from:
$unique = $filenameAbsolute . filemtime($filenameAbsolute) . filesize($filenameAbsolute);
to:
if( file_exists($filenameAbsolute) )
$unique = $filenameAbsolute . filemtime($filenameAbsolute) . filesize($filenameAbsolute);
else
$unique = $filename . strval( rand(0, 100000) );
Now I see no warnings.
I know my solution is ugly. So, please, core developers review my patch.
Updated by Ernesto Baschny over 13 years ago
- Status changed from New to Accepted
- Priority changed from Should have to Must have
- Target version set to 4.5.4
The problem lies within t3lib_compressor::getFilenameFromMainDir. Then given the $filename = 'js/iecompatibility.js' it will return 'atibility.js' (stripping the first 9 chars from the name), which is then further processed by the other methods.
Changing line 147 from:
$file = PATH_site . $file;to:
$file = PATH_site . TYPO3_mainDir . $file;solves this problem, but it has to be proven if this has no side effects, or what it means exactly.
Updated by Daniel Minder over 13 years ago
Ernesto, I implemented your patch, thought about its implications and tested. Unfortunately, now I get the same warnings as before, but in TemplaVoila:
Core: Error handler (BE): PHP Warning: filesize(): stat failed for /var/www/html/typo3/js/extjs/ux/flashmessages.js in /var/www/html/typo3_src-4.5.3/t3lib/class.t3lib_compressor.php line 341
The header comment of the function says only "Finds the relative path to a file, relative to the TYPO3_mainDir", but it does not say how it expects the input file name! And so, other extension programmers got used to its current behaviour and passed file names relative to PATH_site (e.g. "t3lib/js/extjs/ux/flashmessages.js" for TV).
I looked again why this happens here with linkvalidator and found out that the backPath of the template object is set AFTER calling setModuleTemplate, which results in the error. I've created bug report #28255 for this.
Alexander, Thomas, are you also using linkvalidator and can you relate the log warnings to the display of the linkvalidator report in the backend?
So, I guess the reason for this error is neither the compressor nor the template class as I assumed earlier but lies in the extensions using either the template class or addJsFile of the renderer in a wrong way. Therefore, I vote for a won't fix.
Updated by Chris topher over 13 years ago
- Status changed from Accepted to Resolved
- Target version deleted (
4.5.4)
Thanks for digging into this one, guys!
Resolved with #28255.
Updated by