Bug #14692
closed
Access to file resources does not work with mod_fcgid
Added by old_gaumondp over 19 years ago.
Updated about 11 years ago.
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
I can confirm this but I have no clue what's wrong.
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
I think we can close this bug then, heh?
Looks like it's been here for two years...
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.
I don't like the alternative solution, but it seems it works a lot better...
I can confirm the issue. Michael's "alternative solution" solved it.
Hmm what about applying this patch to core?
No objections! In contrary, I'd highly appreciate it.
Might be that Stucki is probably searching for the most perfect solution. ;-)
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
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.
Applying the alternative patch solved the issue on a chrooted openSuSE setup for me.
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?
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.
- 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.
- Status changed from Needs Feedback to Closed
- Assignee deleted (
Michael Stucki)
- Is Regression set to No
No feedback for over 90 days.
Also available in: Atom
PDF