Bug #60737
Symlinks as Document roots are breaking the cache
| Status: | Resolved | Start date: | 2014-08-01 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | - | Spent time: | - | |
| Target version: | next-patchlevel | |||
| TYPO3 Version: | 6.2 | Is Regression: | No | |
| PHP Version: | Sprint Focus: | |||
| Complexity: | easy |
Description
Hi there,
my hoster uses symlinks to the document root to resolve the domain to the document root.
- If there is a host-specific pseudo-DocumentRoot, use it instead of the default one
RewriteCond %{REQUEST_URI} !^/f?cgi-bin/ RewriteCond /var/www/virtual/julia/%{HTTP_HOST} -d RewriteRule (.*) /var/www/virtual/julia/%{HTTP_HOST}$1
That causes errors when trying to load file paths with GeneralUtility::getFileAbsFileName() because the PATH_typo3 constant contains the current document root. (the current domain of this request).
But the cache holds absolute paths to the symlink document root of the request which triggered the caching.
So the getFileAbsFileName returns empty filePaths, because the absolute file paths passed to it didnt start wih the PATH_typo3.
So we have to realpath them before checking.
Im going to push a patch to gerrit, give me a minute it is my first time ;)
Related issues
History
#1 Updated by Gerrit Code Review about 1 year ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/31941
#2 Updated by Frederik Vosberg 12 months ago
Can I do something to help?
#3 Updated by Gerrit Code Review 12 months ago
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32177
#4 Updated by Gerrit Code Review 12 months ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/31941
#5 Updated by Gerrit Code Review 8 months ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/31941
#6 Updated by Helmut Hummel 8 months ago
- Status changed from Under Review to Needs Feedback
Frederik Vosberg wrote:
That causes errors when trying to load file paths with GeneralUtility::getFileAbsFileName() because the PATH_typo3 constant contains the current document root. (the current domain of this request).
But the cache holds absolute paths to the symlink document root of the request which triggered the caching.
Can you point out which cache entries are written with realpath and describe in which context GeneralUtility::getFileAbsFileName() fails?
#7 Updated by Stefan Froemken 8 months ago
Hello Helmut,
we have similar problems on our servers. Apache runs on a symlink /www -> /kunden and if you are logged in by SSH "pwd" shows you /kunden.
So, if TYPO3 Cache was deleted and the next call comes from scheduler/CLI the Cacheentries will be created with /kunden.
If you then try to call Login screen of TYPO3 Backend the whole CSS is broken. The path to these files are wrong. To create relative paths the Core removes the amount of letters of PATH_site from the absolute paths in Cache. In our case we have a difference of 2 letters.
After clearing the cache and call BE again it works.
Stefan
#8 Updated by Helmut Hummel 8 months ago
Stefan Froemken wrote:
we have similar problems on our servers. Apache runs on a symlink /www -> /kunden and if you are logged in by SSH "pwd" shows you /kunden.
So, if TYPO3 Cache was deleted and the next call comes from scheduler/CLI the Cacheentries will be created with /kunden.
If you then try to call Login screen of TYPO3 Backend the whole CSS is broken. The path to these files are wrong. To create relative paths the Core removes the amount of letters of PATH_site from the absolute paths in Cache. In our case we have a difference of 2 letters.
This issue you describe is resolved with https://review.typo3.org/#/c/31565/ and is included since 6.2.5
#9 Updated by Stefan Froemken 8 months ago
Thank you Helmut for searching this ticket. I just have created a new instance with current master and you're right. It works now.
#10 Updated by Anja Leichsenring 8 months ago
- Status changed from Needs Feedback to Resolved
fixed with #58288
