Hi,
after reading this thread, I'd like to summarize a few things and
put some things straight, as I found a bunch of glitches in previous posts.
In no particular order and certainly incomplete ...
get_user_name() -- using this function to "construct" a path is rather pointless and unreliably since there's barely any connection between the user name
reported to PHP and the physical/logical "path name" or structure leading to home directories, document roots or such. Mass hosters (need to) use other techniques to manage the mapping of path names and accounts, contract ids, grants, or other services.
phpinfo() -- tells you exactly where the
active copy of php.ini for the
active PHP version (4 or 5) resides, in case you wanna take it as the source for copies. It also tells you whether it's running as a "module" or "CGI".
speading php.ini files -- pointless in the hope to change "run time values" if PHP runs as Apache module (mod_php), 'cos the module reads this file once only, when the server is started (by the ISP). PHP-CGI -- if configured to do so -- primarily looks for this file in the
directory of the "main script" aka $PHP_SELF and if none is found test for another 10 well-defined locations. Read
http://php.net/manual/configuration.php to learn the rules of where, when and in what order some "php.ini" will be sought and loaded, the possible file names, dependencies on whether its CGI/CLI/module incl. differences of the operating systems.
For Joomla the "main script" is either of the index*.php files of the site, the admin and the installer. There's no need to copy php.ini files into any other directory, if there's no "main script" to call. If one calls /foobar/blabla.php, PHP will look for /foobar/php.ini only, not for /php.ini nor /include/php.ini --
Note: Some J!-Editors or Components use
popup-windows using a different "main script" (check their URL!). When ever that happens, you may also place a copy of your custom php.ini into that very directory, e.g. JCE/MosCE's Image Editor
php-XXX.ini -- PHP may not use an existing "php.ini" even if it's configured to do so, but looks for a very specific file where the
basename is suffixed by its internal "server api name": "cgi", "fast-cgi", "fcgi" or "apache2handler", hence you may have more luck by naming the file php-
cgi.ini rather than just "php.ini". See the result of
php_sapi_name() to find this name.
AddType xxxxx .php -- while many ISPs meanwhile allow you to toggle .php from PHP4 to PHP5 on a directory basis, the type name typically differs and there's no general rule.
You MUST ASK your provider what name they have used. "x-mapp-php5" is true for the german providers 1und1 and Schlund & Partner (same firm, diff. brands). I run client sites on various hosters and EACH has choosen a different type name. On my local box I used
php5_script, as suggested in the manual. (AFAIK, the type name
is fixed to "php5_script" if -- and only if -- PHP5 runs as an Apache module (mod_php), however one may add more types for the same thing in Apache)
php_value xx yy -- only applies to PHP module. Period. Read Elpie's
Guide to .htaccess as a great companion to this subject.
.htaccess & php*.ini -- are NOT interchangeable, as Beat already said. The former belongs to the web server
only and allows to configure (parts) of the
web server configuration and it's active modules. The latter
only belong to PHP of any type, with each may favour a special named file as mentioned above.
The PHP-CGIs evaluate their .ini on each request, hence giving you the ability to change runtime values using separate .ini's in the main script's location, the module does so only if the server is started. To change module settings, you must use the php_value directive. If you happen to have access to Apache's httpd.conf do it there, otherwise use .htaccess and be aware of the possible impact (see Elpie's Guide.)
PHP4 or PHP5 -- by design you can't have both as a module on the same web server (instance) so you need to use their respective method to change run time settings: .htaccess for the module, php.ini for CGIs.
Unfortunately PHP5 isn't yet the default "php handler" for many mass/large hosters but
often runs in parallel, in CGI mode configured to lauch for .php5 files.
Maybe PHP4 runs in CGI mode as well.
Presuming there's no .htaccess to switch the handler type, have two files with
inside and save one as "whatever.php" and the other as "whatever.php5". Check the header block to find out which PHP version and "Server API" applies: anything with "cgi" in that name means, well, CGI mode. The module usually has "apache" in the API name (i.e "apache2handler" on Apache 2.x) -- I have no clue what it's called for IIS or other web servers, sorry.
Finding path names.
ISPs may mount/link
physical storage into a
logical file structure, resulting in different path names apearing in PHP's scope. Handy looking values from i.e. $_SERVER['DOCUMENT_ROOT'], getcwd(), or dirname(__FILE__) must not contain/return the same paths because they origin from different sources (Apache, OS, PHP). While your php-script might be able to
read from each of these paths, that doesn't imply it can also be used to write/copy files into it.
To make things even more fun: via FTP you may encounter even another path to your "web space". The larger your provider the better the chances none of them match "visually".
e.g. physical paths as seen/known by the OS:
/drive1/clients/cheap/contract_id1/web
/drive2/clients/cheap/contract_id2/web
by the web server:
/foo/bar/anybody/account0001/www/htdocs
/foo/bar/anybody/account0002/www/htdocs
by PHP
/account0001/www/htdocs
/account0002/www/htdocs
free.fr for instance happens (or happend) to have such a funky "layout"
You're dealing with several levels:
- paths visible to applications
- logical paths
- their physical location
and you provider's idea of his very own "best practice" to handle all this with the lowest effort.
So instead of guessing and placing INIs all over the place or adding directives to .htaccess for no good: save yourself some time and nerves, and
ask you provider first if the required "feature" (.htaccess, php.ini) is supported at all or search their support/faq pages. The provider may even change a setting for you if this has no impact for other client's setup. Mass hosters are unlikely to do that for you: they're that cheap 'cos they use a "one size fits all" approach.
If this is bugging you, have a drink less per month and save that money for a better provider and service.
Don't reply to my post telling me your provider does it this way or that way: I'm sure he does.
"Disclaimer": There are as many exceptions to the above as there are common, bad and best practices. The above statements are partly simplified a small resume of what I learned in the last couple of years, and I still get stunned now and then on how "creative" or dumb some ISPs [still] are.
Please let me know if any of the above is plain dead wrong or essentially different under a certain environments (i.e.
suexec): I'm always open to learn something new :-)
Have fun,
CirTap
Login
Register
Rules
FAQ
The team
