I have a website which consists of a bunch of static HTML pages. Obviously there's a lot of duplication among these (header, menu, etc). The hosting company I plan to use supports PHP, which I know nothing about. Presumably PHP provides some sort of #include mechanism, but what changes to I need to make to my HTML pages to use it?
For example, suppose I have a page like this
index.html
<html>
<head></head>
<body>
<h1>My Common Header</h1>
</body>
</html>
Obviously I need to move the common part into it's own file:
header.html
<h1>My Common Header</h1>
Given the example above (and assuming all files are in the same directory):
What do I add within the body tag to get header.html included?
Do I need to rename index.html or add some special tags to indicate that it's a .php file?
Do I need to make any changes to header.html?
Update: I want to emphasise that my objective here is simply to find the lowest-friction means of reducing duplication among static HTML files. I'm a bit reluctant to go down the server side includes route because I don't yet know what type of server (IIS/Apache) I'll be hosting the files on, and whether includes will be turned on or off. I was drawn towards PHP only because it is about the only thing I can presume will be available that will be able to do the job. Thanks for the responses.
Thanks,
Donal
You are looking for include (or one of its derivative such as include_once, require, require_once):
header.php
<h1>My Common Header</h1>
index.php
<html>
<head></head>
<body>
<?php include('header.php'); ?>
</body>
</html>
And so on, for your footer for example.
You don't need to use PHP to get this functionality, and it's generally a bad idea to do so due to potential security concerns. Essentially, you're swatting a gnat with a nuclear bomb. If you're not using a dynamic language, then you're looking for server side includes.
In IIS, for instance:
<!--#include virtual="file.inc"-->
Be aware that you often have to configure the server to utilize them, as this feature is often turned off by default. Both IIS and Apache support server side includes, but they use different configurations.
You can find more information here:
Server Side Includes
EDIT: I don't mean that it's a bad idea to use PHP, just using PHP solely for including other files. It creates a larger attack surface by bringing PHP into the mix when it's not needed, thus the potential for security issues when the functionality of PHP is not required.
EDIT2: I think it's a bad idea to assume you won't be a target because of your size, and thus you can ignore security. Most sites are compromised by automated worms and turned into malware hosts, spam zombies, or pirated software/media servers. Apart from the fact that you might end up being involved with infecting others, your site can become blacklisted and it can cost you real money in bandwidth overage charges. We're talking hundreds or thousands of dollars.
Just because you're a small site doesn't make you any less of a target. Just being on the internet makes you a target.
Forget doing it on the server altogether.
If all you really want to do is maintain some static pages -- and don't anticipate ever having to really use PHP -- I'd just do it with Dreamweaver, which will allow you create and manage templates and variable content on your end.
No includes needed. No templating engine needed. (These would be overkill for what you are trying to accomplish.)
You should first change the file extensions of index and header to be .php, then you can do:
<html>
<head></head>
<body>
<? include 'header.php'; ?>
</body>
</html>
And your header.php file just has
<h1>My Common Header</h1>
While you can just use the "include", "require", or "require_once" directives to include things in one page, you might have better luck with a template engine like Smarty
While using an include file for the header is a solution I went a different route when I faced the problem several years back: I wanted all pages to use the same layout (which I assume is rather common ;-). Thus, as I only wanted to change the content of the page I made the page content the file that gets included and have a master template file that includes header and footer. For setting the page to be included I resorted to creating quite small php scripts that only set a variable that holds the page to get included. In some cases the page can also get named by a GET parameter. Of course this requires proper validation of that parameter. In the long run I don't need to worry about the HTML itself anymore -- all I do is write small snippets (which should be complete for themselves of course) that get included.
A possibly even better solution would be to use an existing template framework. Due to the contraints I had back then I wasn't able to do so, but I would do it when facing the same issue again.
Back in the day, I used SSIs (the "<!--#include virtual="file.inc"-->" method described above by Mystere Man) quite a bit for static HTML pages and I would definitely recommend using that.
However if you want to eliminate any uncertainty about whether support for that will be enabled on the server, you could develop your separate files locally and merge them into the resulting files before uploading to your server. Dreamweaver, for example, supports doing this in a seamless fashion.
Or you could do it yourself with a rather simple script in your language of choice by doing simple string replacement on markers in the files, replacing {{{include-header}}} with the contents of a "header.html" file and so on.
Edit
Oops! Somehow I didn't see Clayton's post with the same note about Dreamweaver.
OK this is a semi-programming related question only.
PHP does have include(), which is really easy to use, but it doesn't contribute to future maintainability. I wouldn't recommend it, especially for big sites.
I'm a pro-frameworks. I've used CodeIgniter, CakePHP and even Smarty template engine. If you are serious about PHP, do consider CakePHP. There's this "layouts" concept where you frame your header, footer, css, javascript outside of the main content; e.g. for the "about us" page, your content would be something like:
This is an about us page that tells you a whole bunch of stuff about us...
CakePHP takes this this content, and wraps your layout around it:
header
css
javascript
This is an about us page that tells you a whole bunch of stuff about us...
footer
Related
I realize this question is similar to this one but there didn't seem to be a definitive answer there. Currently I'm using <?php include "banner.html"; ?> but in order for this to work I need to change the ext of ALL pages to .php instead of .html.
I don't think this is really best practice. I'd prefer to keep my basic webpages as html files and reserve php files for server-side logic - isn't that the way it's supposed to be??
The banner should be displayed at the top of each page by default as soon as the page loads, so from what I've read jquery.load() is not appropriate as that should typically be triggered by user input. This is not an ASP.NET project so master pages is not an option. Also heard about HTML templating but after googling it I walked away more confused than ever.
I don't think this is really best practice.
It's fine, especially for small sites.
I'd prefer to keep my basic webpages as html files and reserve php files for server-side logic - isn't that the way it's supposed to be??
Keeping business logic and view logic apart is a good idea, but you don't need to go so far as to ban .php extensions on files that don't include business logic.
You might want to investigate the MVC pattern and the approaches taken by frameworks such as CodeIgniter or CakePHP if you want to see how other people keep their logic and HTML separate.
Either go ahead and convert the files to .php (totally fine practice), or use file_get_contents rather than include to get the HTML content:
<?php echo file_get_contents('banner.html'); ?>
I was wondering if it's the right thing to include the tags like etc via another page.
What I mean by that is:
<?php include_once("header.php")?>
The content for each individual page
<?php include_once("footer.php")?>
Header.php contains:
<!DOCTYPE html>
<head>
<title>My Website</title>
</head>
<body>
Footer.php contains:
</body>
</html>
I am using it that way because when I have a lot of pages, it's a lot easier to just change one/two page(s). That way I spare time.
But the question is, is it bad to use a "template" style for my website?
( I saw some similair questions like this one but they didn't really answer my question, that's why I started a new topic - Sorry if it's wrong )
No problem with this I think - it's certainly better than duplicating the same content across multiple pages. Don't Repeat Yourself is a core tenant of programming, and this approach helps in that regard. The performance impact of the PHP includes is absolutely minimal and not worth worrying about, compared to advantage of easier maintenance.
You might be able to go further still though. Do you really need to repeat the includes on every page ? If all the pages have identical headers and footers, then you could make just one page that has them, and an area for dynamic content in the middle instead (this is the approach ASP.NET takes).
No, this is great. You will actually find there are more and more things you would like to move into included files, for example the sidebar for your website could be in its own file. This is exactly what PHP what made for, to allow for easier maintenance of your website.
Any PHP will be slower than only HTML. For example people use cacheing plugins for wordpress sites, so just HTML will be requested and the php server wont have to work as hard, and the page will be quicker. But the benefits of using PHP clearly outweigh this with the popularity of wordpress.
All php calls are made once, so multiple calls of php is not like multiple calls for css files or JavaScript.
As the site grows you will be happy to make one change that will affect all pages, rather than have to change each page. A simple example is a seasonal greeting in the header. Simple to ad and take away with your template. not so without. And that is before the more obvious link changes.
This is a good direction, just don't repeat yourself. Anyway, to get some more robustness from this templating idea you can try to take a look on the following libraries:
Twig : http://twig.sensiolabs.org
Smarty: http://www.smarty.net
Why don't people make .php files for their CSS and JavaScript files?
Adding <?php header("Content-type: text/javascript; charset: UTF-8"); ?> to the file makes it readable by browsers, and you can do the same thing to css files by setting the Content-type property to text/css.
It lets you use all the variables of PHP and methods into the other languages. Letting you, as an example, change the theme main colors depending on user preferences in css, or preloading data that your javascript can use on document load.
Are there bad sides of using this technique?
People do it more often than you think. You just don't get to see it, because usually this technique is used in combination with URL rewriting, which means the browser can't tell the difference between a statically-served .css file and a dynamic stylesheet generated by a PHP script.
However, there are a few strong reasons not to do it:
In a default configuration, Apache treats PHP script output as 'subject to change at any given time', and sets appropriate headers to prevent caching (otherwise, dynamic content wouldn't really work). This, however, means that the browser won't cache your CSS and javascript, which is bad - they'll be reloaded over the network for every single page load. If you have a few hundred page loads per second, this stuff absolutely matters, and even if you don't, the page's responsivity suffers considerably.
CSS and Javascript, once deployed, rarely changes, and reasons to make it dynamic are really rare.
Running a PHP script (even if it's just to start up the interpreter) is more expensive than just serving a static file, so you should avoid it unless absolutely necessary.
It's pretty damn hard to make sure the Javascript you output is correct and secure; escaping dynamic values for Javascript isn't as trivial as you'd think, and if those values are user-supplied, you are asking for trouble.
And there are a few alternatives that are easier to set up:
Write a few stylesheets and select the right one dynamically.
Make stylesheet rules based on class names, and set those dynamically in your HTML.
For javascript, define the dynamic parts inside the parent document before including the static script. The most typical scenario is setting a few global variables inside the document and referencing them in the static script.
Compile dynamic scripts into static files as part of the build / deployment process. This way, you get the comfort of PHP inside your CSS, but you still get to serve static files.
If you want to use PHP to generate CSS dynamically after all:
Override the caching headers to allow browsers and proxies to cache them. You can even set the cache expiration to 'never', and add a bogus query string parameter (e.g. <link rel="stylesheet" type="text/css" href="http://example.com/stylesheet.css?dummy=121748283923">) and change it whenever the script changes: browsers will interpret this as a different URL and skip the cached version.
Set up URL rewriting so that the script's URL has a .css extension: some browsers (IE) are notorious for getting the MIME type wrong under some circumstances when the extension doesn't match, despite correct Content-Type headers.
Some do, the better thing to do is generate your JS/CSS scripts in PHP and cache them to a file.
If you serve all of your CSS/JS files using PHP, then you have to invoke PHP more which incurs more overhead (cpu and memory) which is unnecessary when serving static files. Better to just let the web server (Apache/nginx/lighttpd/iis etc) do their job and serve those files for you without the need for PHP.
Running the PHP engine does not have a zero cost, in either time or CPU. And since CSS and JavaScript files usually rarely change, having them run through the engine to do absolutely nothing is pointless; better to let the browser cache them when appropriate instead.
Here’s one method I’ve used: The HTML page contains a reference to /path/12345.stylesheet.css. That file does not exist. So .htaccess routes the request to /path/index.php. That file (a) does a database request, (b) creates the CSS, (c) saves the file for next time, (d) serves the CSS to the browser. That means that the very next time there’s a request for /path/12345.stylesheet.css, there actually is a physical static file there to be served by Apache as normal.
Oh, and whenever the styles rules are edited (a) the static file is deleted, and (b) the reference ID is changed, so that the HTML page will in future contain a reference to /path/10995.stylesheet.css, or whatever. (Actually, I use a UNIX timestamp.)
I use a similar method to create image thumbnails: create the file on first request, and save a static file in the same place for future requests. I’ve never had occasion to do the same for javascript, but there’s no fundamental reason why not.
This also means that I don’t need to worry about caching headers in PHP: only the first invocation of each CSS file (or image thumbnail) goes through PHP, and if that is served with anti-caching headers, that’s no great problem.
Sometimes you might have to dynamically create javascript or styles.
the issue is webservers are optimized to serve static content. Dynamically generating content with php can be a huge perforamce hit because it needs to be generated on each request.
It's not a bad idea, or all that uncommon, but there are disadvantages. Caching is an important consideration - you need to let browsers cache when the content is the same, but refresh when it will vary (e.g. when someone else logs in). Any query string will immediately stop some browsers caching, so you'll need some rewrite rules as well as HTTP headers.
Any processing that takes noticeable time, or requires a lock on something (e.g. session_start) will hold up the browser while it waits for the asset.
Finally, and quite importantly, mixing languages can make editing code harder - syntax highlighting and structure browsers may not cope, and overlapping syntax can lead to ugly things like multiple backslash escapes.
In javascript, it can be useful to convert some PHP data into (JSON) variables, and then proceed with static JS code. There is also a performance benefit to concatening multiple JS files ago the browser downloads them all in one go.
For CSS, there are specific languages such as Less which are more suited to the purpose. Using LessPHP (http://leafo.net/lessphp/) you can easily initialize a Less template with variables and callbacks from your PHP script.
PHP is often used as a processor to generate dynamic content. It takes time to process a page and then send it. For the sake of efficiency (both for the server and time spent in programming) dynamic JS or CSS files are only created if there isn't a possible way for the static file to successfully accomplish its intended goal.
I recommend only doing this if absolutely you require the assistance of a dynamic, database driven processor.
The bad sides: plenty, but to name just a few:
It'll be dead slow: constructing custom stylesheets for each request puts a huge load on the server, not something you want.
Designers create CSS files, programmers shouldn't (in some cases shouldn't be allowed to). It's not their job/their speciality.
Mixing JS and PHP is, IMHO, one of the greatest mistakes on can make. With jQuery being a very popular lib, using the $ sign, it might be a huge source for bugs and syntax errors. Besides that: JS is a completely different language than virtually any other programming language. Very few people know how to get the most out of it, and letting PHP developers write vast JS scripts often ends in tears. JavaScript is a functional OO (prototypal) language. People who don't full understand these crucial differences write bad code as a result. I know, because I've written tons of terrible JS code.
Why would you want to do this, actually? PHP allows you to change all element's classes while generating the page, just make sure the classes have corresponding style rules in your css files and the colours will change as you want them, without having to send various files, messing with headers and all the headaches that comes with this practice
If you want more reasons why you shouldn't do this, I can think of at least another few dozens. That said: I can only think of 1 reason why you would think of doing this: it makes issues caused by client-side cached scripts less of an issue. Not that it should be an issue in the first place, but hey...
In HTML is there such a line of code that will do the same thing as PHP's require_once? I'm just curious because there are some lines of codes that I want to duplicate through multiples sheets without needing to require myself to type it each page.
I know I can do it via PHP, but I am looking for an HTML variant? Is there such a beast or am I barking up the wrong tree?
That depends on what you want to include. Including a PHP-File is not possible, if you want to include a CSS stylesheet, use:
<link rel="stylesheet" type="text/css" href="yourstylefile.css" />
and for a Javascript file
<script type="text/javascript" src="yourscriptfile.js"></script>
Of course you have to put that code between the header-tags.
No, there is no include mechanism in HTML. Unless you count SSI.
Edit: wait, "sheets"? You mean CSS?
Yeah, SSI is the closest you're going to get. However, there are many non-server-side ways to get around this. Several web development applications have html templating systems that replicate server-side includes on the development side. For example, dreamweaver allows you to insert repeatable regions into HTML templates. When you modify the "included" file, Dreamweaver will modify all HTML files that use that block. As this is not a true include, but rather an HTML-updating system, you do have to then re-upload these files if you use a remote server, but if you have to stick to plain HTML it can make projects much more manageable and is much better than using iframes.
Lastly, there is also the option of having Javascript build a repeating block of code. You can simply include a common javascript library on every page <script type="text/javascript" src="templater.js"></script> and have it build the element on the client's side (either with an innerHTML call or inserting elements into the DOM). This has the obvious downside that
It requires Javascript to work
It might mess with SEO
It may slow down page loads (from the client side anyhow)
Using a proper include in a server side language is of course the best approach, but in a pinch these are both potential alternatives.
Technically you can create an iframe on your page which will load and handle a separate page but it does not function like include or require once. And to this I know of no alternatives.
I have a few pages out (not too many though) and I was just thinking that I might want to change all of the pages to php instead of html. I am planning on using php in the future, I am just not quite ready yet to make it my full-time language. I know anythign you can do with html pages, you can do with php pages, but I just wanted to know, is there any reasons to stay with html compared to switching to PHP before my site gets too big and I wind up having to change 100 pages, and renaming hundreds of links?
The only reason I can think of is a small hit in performance.
Most web servers like Apache, LightTPD are configured to serve .html files as static files while .php files will have to first go through the PHP engine to be interpreted and only then delivered to the client.
Your pages will still be HTML. PHP allows websites to be generated dynamically, that is, you can display a username for users. However, what is sent to the browser is still HTML.
I recommend that you start switching to PHP because even if you choose not to use PHP, your pages will still work and render fine. However, if you stick with .html and then decide to switch to PHP, then you'll have to convert every single link. So convert now, and save time.
One thing I should note: It is possible, but usually not done, to have .html pages render as PHP by modifying server settings. However, in most cases, the .php is used, as most servers are already configured to run .php though the PHP engine. But in case anyone with a large site has this question, this is an option.
You pretty much answered your own question. If you ever reach the stage where you want to add dynamic content to an HTML document, you're going to need to change the file extension, or alter the webserver configuration to have PHP process .html files.
Generally, you will want every page to contain, if not dynamic content, then at least consistent content. Things like headers and footers, that require a massive amount of copy-pasting in straight HTML or a single include() in php. PHP allows for much cleaner organization and much less repetition, even if you're not after dynamic content for your pages.
The extension doesn't really matter. the PHP marker won't have any real effect until you begin embedding the tags into the files to engage the script processor.
Although it's true that you can do anything with PHP that you can do with HTML, the contrary is not true. With PHP you can do things that are not possible with HTML. Specifically, you can create dynamic pages with PHP, that is, pages whose contents are not fixed once you've written them.
If your pages are static, then you should continue to use HTML, if you need dynamic content, then you must use PHP (or another template/programming language).
why stay with just html when u can have both? u can have static html pages for static content and php pages for dynamic content. You can manage not just links but almost everything with php. I am creating a site with just 30 pages and I can say, while I do have both php and html, some things get out of hand (links, templates, data, etc). Imagine having 70 more...
Well, there aren't that many disadvantages maybe except for the fact that you might end up with this sort of code