Forum Moderators: phranque
What follows is an in-depth ticket sent to my host (who said this issue is beyond their scope of support... ughhh), however, the problem is quite simple: I can't get server-side includes to work with php5 when it runs as a module on apache. I checked (via phpinfo()) that I have mod_include in fact installed. I'm trying to include files that are a level up (outside doc root) from my document root, and hence have include_path defined. But I get an error, on the file that's trying to include, saying the file is not there (see #4 below)...
I'm on a dedicated virtual server with root access. Admissions: I probably have no place rooting around in the config files (pun intended)... but I like the fact that I have complete control. The problem though, is, that I have complete control. I'm on the following sw:
PHP Version 5.2.5
Apache/2.2.3 (CentOS)
Any help is greatly appreciated as I'm a bit up a creek if I can't use included files outside my doc root... plus any book/site recommendations on how a typical LAMP setup even works that is both general, in-depth, and written at a fifth grade level :o) would be excellent.
TICKET TO MY HOST:
I'm trying to include a .php file (that is outside httpdocs) into my test.php file (inside httpdocs). I'll try to be as detailed as possible so you can fully understand what's going on, and what I've tried:1) This file is real and existent: /var/www/hosts/example.com/httpdocs/test.php and contains the following line of code:
<?php
include('global-include/include.php');
phpinfo();
exit;
?>2) This file is real and existent /var/www/hosts/example.com/global-include/include.php and has contents:
<?php
#this is comment code and should not be displayed if this file is parsed right
echo 'hello, the file got included';
?>3) vhosts.conf specifies the the following php setting:
php_value include_path .:/var/www/vhosts/example.com
(I've tested vhosts to be sure it's values are being read, and they in fact are as I can turn display errors on and off)4) When you request: http://www.example.com/test.php, the following errors occur, along with the output of phpinfo():
Warning: include(global-include/include.php) [function.include]: failed to open stream: No such file or directory in /var/www/vhosts/example.com/httpdocs/test.php on line 2
Warning: include(global-include/include.php) [function.include]: failed to open stream: No such file or directory in /var/www/vhosts/example.com/httpdocs/test.php on line 2
Warning: include() [function.include]: Failed opening 'global-include/include.php' for inclusion (include_path='.:/var/www/vhosts/example.com') in /var/www/vhosts/example.com/httpdocs/test.php on line 25) I opened up this ticket at this point, because I had this same thing working on dv 3.0 two days ago, but now it doesn't, after the migration to dv 3.5. I know php5 is running as a module as opposed to fastcgi. I thought, however, the migration would allow for includes. I opened up this ticket and Brandon steered me towards the listed kb article. I followed it to a T. It didn't work, so I tried some shotgun solutions... and nothing seemed to work. Here's what I added to my .htaccess file (in httpdocs), which got me close:
#AddType text/html .php
#AddHandler fcgid-script .php
#AddHandler php-script .php
#AddHandler application/x-httpd-php .php
AddHandler server-parsed .php
Options +IncludesHowever, now when requesting http://www.example.com/test.php, a download box pops up AND the source of the page (if you cancel the download box) is:
<?php
include('global-include/include.php');
phpinfo();
exit;
?>I would love to know what I need to do to get SSI to to work. Thanks so much for the help! Additionally, I'd like to make the change in vhosts.conf (or better het httpd.conf) as opposed to .htaccess. If you could show me how to do that, I'd be thrilled!
PS: Just to clarify... the output of /test.php is the actual source code of test.php as opposed to a php file parsed into html format.
That said, I met a host that had b0rked the default path for PHP includes.
I was able to over-ride it using this line of code in the .htaccess file in the web doc root:
php_value include_path /vhost/vhost4/e/x/a/example.com/www/includes
Notice that path begins with a "/" and gives the full internal path to the folder.
Do you really need SSI, or could you use PHP includes instead?
[edited by: g1smd at 10:44 pm (utc) on Mar. 17, 2008]
1) This file is real and existent: /var/www/hosts/example.com/httpdocs/test.php
2) This file is real and existent /var/www/hosts/example.com/global-include/include.php
3) vhosts.conf specifies the the following php setting:
php_value include_path .:/var/www/vhosts/example.com
The paths are different, therefore it will not find your code.
Thankfully my host, just when I started thinking not good things about them, fixed the problem. Here's their response back to me:
You had the correct PHP include_path set, but you did not set the open_basedir correctly. As a courtesy, I edited the vhost.conf file to have the following information:<Directory /var/www/vhosts/example.com/httpdocs>
php_admin_value open_basedir ".:/var/www/vhosts/example.com"
</Directory>Your test.php file (http://www.example.com/test.php) now works properly. The reason you were downloading the PHP files was due to this line in your .htaccess file:
AddHandler server-parsed .php
Also you don't need Options +Includes in your .htaccess file.
I'm stoked it's fixed, but I want to learn in the process. 1) I thought the diff between php_value setting and php_admin_value was that the latter overrides the former? But, I remember trying to change open_basedir myself, and couldn't do it with the normal php_value method (e.g. php_value open_basedir ".:/var/www/vhosts/example.com"). Also, should I always be quoting strings when changing these values via a vhosts.conf file? Or does that really matter?
Cool guys. Thanks for the time!
I figured I would eventually want to add other functionalities in PHP and if it was a problem with SSI, why not use PHP to accomplish the includes in the first place? Sure enough, I do use some PHP for other things - like automating the update of the copyright date, and last updated - next is streamlining putting titles and meta tags on pages.
PHP is much more useful - but that was just the choice I made, others may disagree.
Marcia. Once my boss told me that I'm ridiculous for programing the copyright date to be dynamic. But I'll tell you what, it's one less thing I have to do in the new year! [and he's no longer my boss :o) ]
I accept credit cards too, and I use php's awesomeness to always give the user a range (current date + 12 years) of credit card expiration dates. Again, another thing I don't have to update.
I do the page title thing too, and it works excellent! I have a default page title, but if I define one on that page, it sucks in the new title. It's quite nifty. Something like:
//i'll set the title with custom content from my db so the pages are optimized for the dynamic content
$title = 'My custom title sourced from my db';
include('header.php'); //this header file actually brings in the title
//body goes here
include('footer.php');
Anyway, best wishes, and thanks for the thoughts.
This is sort of off-topic, but let me save you some time: You do not ever have to update the copyright date on a page to "keep it copyrighted." Actually, all you have to do is stay alive, since the copyright is based on the author's lifetime, not the page being updated.
The only time you'd have to update the copyright is if you materially change the text on the page. So, you might consider updating the copyright date only when the actual content changes -- not the navigation, not the includes, but just the "meat" of the page. In other words, LAST_MODIFIED is a better date to use than (current) TIME_YEAR.
There are a lot of myths, legends, and misinformation pertaining to copyright floating about the web -- All the way from "I can copy anything, since it's on the Web" to "I can copy something, change it a little, and then copyright my own version." The best source for information is the Copyright Office/Bureau/Ministry of your country. And if your country is a signatory to the WIPO treaties, then your Web copyright laws will be much like the laws of the U.S. and the DMCA. The DMCA is the U.S. act that incorporated the WIPO treaties into U.S. law.
Jim
copyright 2004-2008
It's a tiny detail, but if it instills an iota (wow, that word got thru FF spell checker) of confidence in my users/clients, than it's worth it for me.
Hmmmm... I think I get it. SSI is kind of it's own sort of "html" specific including deal, where you don't need a programing language per-say, to invoke it.
Yes, for the most part here, you got it. SSI is a (limited) feature in Apache to perform some server-side processing when coded appropriately within a requested document. When it comes to the question of Can I use SSI in a php document? [webmasterworld.com] Or, any type of document, I agree with Marcia 100% ... if you are using PHP to provide server-side processing you really don't need to invoke and use Apache SSI. However, the answer to the question is "yes, it can be done" and the linked thread in that document describes how for those that wish to punish themselves with the exercise ( direct link here [webmasterworld.com] )
1) I thought the diff between php_value setting and php_admin_value was that the latter overrides the former? But, I remember trying to change open_basedir myself, and couldn't do it with the normal php_value method (e.g. php_value open_basedir ".:/var/www/vhosts/example.com").
Yes and no. The difference is what type of php configuration directive you are attempting to change and where you change it. open_basedir [php.net] is of type
PHP_INI_SYSTEMin PHP < 6 which means it can be set in
php.inior
httpd.conf. Any directive type set with
php_admin_*can not be overridden by
.htaccess. Also,
php_admin_*can not be used in
.htaccessfiles. So, you could set
open_basedirin
httpd.confusing
php_valueor
php_admin_value. But if you used the latter, you would not be able to override it later using an
.htaccessfile, which would not work for this particular directive anyway because it cannot be changed at that level. It can seem a little confusing but pretend you are a hosting provider and you don't allow your end user's to change certain directives. You could set the value for each of their sites to their own temporary directory for sessions with
php_admin_value session.save_path [php.net] /path/to/example.com/sessions
Also, should I always be quoting strings when changing these values via a vhosts.conf file? Or does that really matter?
If an argument contains a space, the argument must be enclosed in double quotes.
[httpd.apache.org...]
Example code in this thread [webmasterworld.com]
PS: SSIs, in my head at least, will be forever toppled by PHP includes.