Bug #14692
closedAccess to file resources does not work with mod_fcgid
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)
Files
Updated by Michael Scharkow over 19 years ago
I can confirm this but I have no clue what's wrong.
Updated by Rupert Germann over 19 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 Benni Mack almost 17 years ago
I think we can close this bug then, heh?
Looks like it's been here for two years...
Updated by Michael Stucki over 16 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 about 16 years ago
I don't like the alternative solution, but it seems it works a lot better...
Updated by Marcus Krause about 16 years ago
I can confirm the issue. Michael's "alternative solution" solved it.
Updated by Cyrill Helg over 15 years ago
Hmm what about applying this patch to core?
Updated by Marcus Krause over 15 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 Michael Stucki over 15 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 almost 15 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 over 14 years ago
Applying the alternative patch solved the issue on a chrooted openSuSE setup for me.
Updated by Andy Weber almost 14 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 Nissen almost 14 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 over 11 years 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.
Updated by Alexander Opitz about 11 years ago
- Status changed from Needs Feedback to Closed
- Assignee deleted (
Michael Stucki) - Is Regression set to No
No feedback for over 90 days.