Forum Moderators: open
I am developping an intranet/internet application. About 20 programs are already running but before I continue I would like to have some advise about using “php include” or “include file/virtual”.
I want to include header, menu and footer layouts in almost all my layouts. I can use ssi include file/virtual or PHP include (or?).
What is advisable for future development and (ofcourse) performance?
I am not an expert with PHP but I have been told that using php include can only be done in a file with an extension .php. If this is true then I have to rename all my .htm layouts which I already created, linked, etc. So I wouldn’t be so happy with this option but if this is the BEST option then I will change them.
Thank you in advance for any advise.
Rob
HP Unix 11i
Apache 1.3.19 (will update to 2.0 soon)
Mozilla Firefox 2.0.0.11
Microfocus Server Express Cobol
Not true. You should be able to include an html file into the document. As far as using php, you can make some powerful templates with php that may help you down the road, so if you are looking for something like that, the php is probably the better way to go.
The php include can include any file (.txt .htm etc). But the php include only works inside a file with the extension .php.
Inside mylayout.htm I want to include a file myheader.txt so inside mylayout.htm (not .php) I wrote <?php include(“myheader.txt”)?> The file myheader.txt won’t include. But when I do it inside mylayout.php then it does include. How can I make sure that a php include inside a layout with the extension .htm will recognize the php include?
Inside apache I defined:
<IfModule mod_mime.c>
AddType application/x-httpd-php .php
AddType application/x-httpd-php .html
AddType application/x-httpd-php .htm
AddType application/x-httpd-php-source .phps
</IfModule>
Is there something I overlooked?
Rob
>> I have been told that using php include can only be done in a file with an extension .phpNot true. You should be able to include an html file into the document.
Erm? Have I missed something? ... Yes, you can include any type of file (inc .html) using a PHP include, but the file you are including into would normally need to have a .php extension. Because the server would need to parse the file for php in order to process the include statement. The exception to this is if you have configured the server to process other file types for PHP, not just .php files. You could for instance instruct the server (via the .htaccess file) to parse .html files for PHP.
Also... SSI's are normally only possible in files ending .shtml - unless, like PHP above, the server is configured to parse other file types for SSI's.
Personally I would tend to go for PHP includes if PHP is available, SSI otherwise.
(Oops, I see you've already posted!)
AddType application/x-httpd-php .php .html .htm
Just note that this will parse all your html files as php.
The last thing I wrote used SSI to 'include' the page content. Then I used an unobtrusive JS script to convert the site to AJAX if available. As all the pages content were already in separate include files this was extremely easy.
Plus, SSI's don't require any faffing around with the server settings.
For .shtml pages, but how about if you want to use includes on .htm or .html pages? And is it compatible if you want to add some PHP functionality to the pages as well?
For .shtml pages, but how about if you want to use includes on .htm or .html pages? And is it compatible if you want to add some PHP functionality to the pages as well?
Yes for .shtml pages, just like PHP works with .php pages.
As for functionality with both at the same time, I honestly don't know. I'm not a PHP coder.
If you use <?php> in a normal .html I guess it won't work, so probably not. But what about using an SSI to include a .php file?
Give it a try and let us know!
I honestly don't know
Actually, I was lying. I really do know, as I realised while doing the washing up.
As well as the #include directive, you can use the #exec command to execute any other program and 'paste' it's output into the HTML. So yes, using SSI you can still include PHP code.
To include use this:
<?php
include($_SERVER['DOCUMENT_ROOT'] . '/somefolder/another folderifyouwant/yourfile.php' );
?>
$_SERVER['DOCUMENT_ROOT']
Provides an absolute path so you can move the document to different locations on your server or even a different server altogether.
But what about using an SSI to include a .php file?
You can include a .PHP file with the #include directive of SSI and the file will be parsed by the PHP processor if Apache has been setup properly.
I have used SSI for more than ten years (still working on some sites) but all new developments are with PHP includes. This is not because of the extra features that PHP offers--although it is handy when you need to perform some more data processing than just including headers and footers--but mainly because the PHP syntax is more readable than SSI. Speed of execution is no issue in both cases on modern webservers. I haven't seen any significant increase in loading time between plain HTML files and pages that are created with multiple includes with either SSI or PHP.
On all sites where I use SSI or PHP, I have setup Apache in such a way that files with the .html extension are parsed as either SSI or PHP. This is because I think the user shouldn't know which technology is behind the site. The output is HTML in both cases, and therefore I chose that extension for the pages.
This is what SSI's were designed to do.
PHP is a dynamic scripting language.
The reasoning behind choosing one over the other is basic. When scannning a file structure it is easy to guess at what the files are meant to do. You see .shtml files, you can guess they will use and need includes. You see .php files, you can presume these are performing some dynamic function. .htm and .html are static files. .asp are going to be parsed as Active Server Pages.
Tweaking the server config to parse all files (whether SSI or PHP) is cool and all that, getting a program to do something additional is fine, but it becomes very confusing for a new programmer to figure out what the heck you're thinking when at every turn you add something unexpected. :-) There is a total loss of convention and standard. You spend an unnecessary amount of time just learning the playing field.
This X 100 on any extremely large project, or if you ever get bored with it and hand it over to someone new.
I have ten year old projects which changed from plain HTML files in the beginning, via SSI includes, to fully dynamic PHP generation. Changing the way my webserver parses the source files allowes me to keep the original URLs, with three different page generation technologies. You should also read [w3.org...] where Tim Berners-Lee explains why an URL should be independent of the technology behind the scenes to produce the content.
Not to mention the intrinsic power that 10 year old URLs have in the search engines.
While both will work effectively for the task, I always say right tool for the job.
But if the right tool for the job changes in the future at least you don't have to go hunting down all your includes. Say for example you have your main nav and it's a simple html include. At some point in the future you instead want to get fancy and have a menu that is dictated by the page that is being requested or maybe do a SQL query to grab sub links or whatever, you only have to change the include if you're using php or some other server side scripting language.
I think that's a pretty big advantage.
