Bug #14692
Access to file resources does not work with mod_fcgid
| Status: | Needs Feedback | Start date: | 2005-04-20 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | Michael Stucki | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| TYPO3 Version: | 4.2 | Complexity: | ||
| PHP Version: | 4.3 | |||
| Votes: | 0 |
Description
Using the Green Static template on a fresh 3.8b2.1 show these in the FE Admin panel:
Parse template:
"media/uploads/green/menu_back.png" is not a file (non-uploads/.. resource, did not exist).
And 8 others similar errors.
/Page generation/pagegen.php, initialize genearate:
"media/scripts/gmenu_layers.php" is not a file (non-uploads/.. resource, did not exist).
Other static templates generate same kind of errors just for different files.
(issue imported from #M1007)
Related issues
| related to Core - Bug #17535: index.php assumes current working directory to be PATH_site | Resolved | 2007-08-16 |
History
Updated by Michael Scharkow about 8 years ago
I can confirm this but I have no clue what's wrong.
Updated by Rupert Germann about 8 years ago
I can not confirm this - neither for 3.8.0beta2.1 nor for latest cvs version.
What I tested (in both versions):
- created a new page
- created a new rootlevel TS template (create template for a new site) with the static template GREEN
- created some subpages
- tested the new site -> works
System: debian/sid, PHP 5.0.4
Updated by Benjamin Mack over 5 years ago
I think we can close this bug then, heh?
Looks like it's been here for two years...
Updated by Michael Stucki about 5 years ago
I think I'm having the same problem here. Seems like if PHP is run with mod_fcgid, the CWD is not automatically set to PATH_site. Therefore, all file references need to be prefixed with PATH_site first.
Attached is a patch which takes care of the issue.
Updated by Michael Stucki over 4 years ago
I don't like the alternative solution, but it seems it works a lot better...
Updated by Marcus Krause over 4 years ago
I can confirm the issue. Michael's "alternative solution" solved it.
Updated by Cyrill Helg almost 4 years ago
Hmm what about applying this patch to core?
Updated by Marcus Krause almost 4 years ago
No objections! In contrary, I'd highly appreciate it.
Might be that Stucki is probably searching for the most perfect solution. ;-)
Updated by Cyrill Helg almost 4 years ago
For over 4 years? crazy!
Updated by Michael Stucki almost 4 years ago
Well, it seems I was no longer able to reproduce the issue. I'm using mod_fcgid here as well but the problem does not happen.
- michael
Updated by Martin Schönbeck over 3 years ago
I had this problem now with PHP 5.3.1 on an openSUSE 11.2 with Apache 2.2.13 and suphp 0.7.1. I fixed it for the moment by copying index.php into the doocroot. I'll dig into it a little bit more in January 2010.
I did some more investigation. The problem arises with the cgi-version. It does not appear with mod-php. Because cwd also delivers the expanded path, when php-cgi is called from the shell, it's no problem of apache integration. fix_pathinfo doesn't change anything.
Updated by Mario Rimann about 3 years ago
Applying the alternative patch solved the issue on a chrooted openSuSE setup for me.
Updated by Andy Weber over 2 years ago
I had the same problem today with TYPO3 4.4.4, PHP 5.3.0, Apache 2.x with mod_fcgi 2.2.10 running on CentOS 5.5. Applied the alternative patch and now it works fine.
After 5 years still not in core? Are there any reasons why not?
Updated by Thorben Kapp over 2 years ago
I also noticed this problem and tried to solve it the last two days. I use also TYPO3 4.4.4, PHP 5.2.4 Apache 2.2.8. I wanted to switch from mod_php to php via fcgid and ran into this issue.
In my oppinion ,this does not need to be in core. I solved this issue by setting the option doc_root=/var/www/path_to_site/ in the php.ini. I use an own php.ini for every site. So setting this is no problem. I hope this helps somebody else.
Updated by Wouter Wolters about 19 hours ago
- Status changed from Accepted to Needs Feedback
- Target version deleted (
0)
Do we still need to have something fixed here? IMO this is a misconfiguration on the server side.