Bug #14692

Access to file resources does not work with mod_fcgid

Added by old_gaumondp about 8 years ago. Updated about 19 hours ago.

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)

bug_1007.diff (2.3 kB) Administrator Admin, 2008-04-04 00:23

bug_1007_alternative.diff (1.1 kB) Administrator Admin, 2008-11-18 00:54


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.

Also available in: Atom PDF