Getting Started With PHP and Dynamic Content

Posted in Tutorials, Web Design4 years ago • Written by 18 Comments

If you have taken any basic HTML courses or look through tutorials you know how to build a website…. Well sort of. HTML is pretty much the first and main stepping stone of websites but it is merely the beginning. In this post I will show you a few techniques to get you stated in using PHP to make your sites more dynamic and much easier to manage.

Lets take for example you have an information site about carving spindles. Your site consists of a home page, an about us page, a contact us page, and a content page that has the instructions on creating the spindles. This is a small site and your knowledge currently is mostly only on HTML and CSS but you are tired of having to go and edit something on all 4 pages to simply make one change on the site.

Here is your current home page

<html>
     <head>
          <title>Creating Hand Carved Spindles</title>
     </head>
     <body>
          <div id="container">
               <div id="nav">
                    <ul>
                          <li>Home</li>
                          <li>Tutorial</li>
                          <li>About Us</li>
                          <li>Contact Us</li>
                    </ul>
               <div id="content">
                    <p>All of the information on your home page.</p>
               </div>
               <div id="footer">
                     <ul>
                          <li>Home</li>
                          <li>Tutorial</li>
                          <li>About Us</li>
                          <li>Contact Us</li>
                    </ul>
               </div>
          </div>
     </body>
</html>

Obviously an actual site will have much more than this but this is a very basic setup. Now, as you can see the content that falls between the “header” div and the “footer” div is content that is going to be on every site. So say you wanted to change the “Tutorial” navigation to read “How To Carve Spindles”, you would have to open each file and change the text in each individual one. In this example only having 4 pages to your site it obviously would not be a huge deal but if you had 20+ pages it would be awful. So to avoid having to make multiple changes we can use PHP include(). PHP include does exactly what it says. It will include the file that you tell it to and the webserver will display it as one file. This way you can span one simple file across as many pages as you like.

Let me break this down to show you what I mean exactly. Lets first create our header.html. To do so we will want to take all of the upper code that we want to appear on each page of the site.

header.html

<html>
     <head>
          <title>Creating Hand Carved Spindles</title>
     </head>
     <body>
          <div id="container">
               <div id="nav">
                    <ul>
                          <li>Home</li>
                          <li>Tutorial</li>
                          <li>About Us</li>
                          <li>Contact Us</li>
                    </ul>
               <div id="content">

You see we took all of the starting code that we need to create HTML files and went all the way to where the code will become unique for each page. I took even the ”

” because this will need to be on each page. So let’s do the same thing for the footer content.

footer.html

               </div>
               <div id="footer">
                     <ul>
                          <li>Home</li>
                          <li>Tutorial</li>
                          <li>About Us</li>
                          <li>Contact Us</li>
                    </ul>
               </div>
          </div>
     </body>
</html>

As you can see we did the exact same thing here. We started with the closing (

) div for the content div which is in the header.html. One thing that you always need to watch for when doing this is always have the same count of divs in the header as you do in the footer. This can get a little tricky if you have a design that has a lot of nested divs. Ok so now you might be wondering how exactly we would use this. So below will be our pages for this site.

index.php

php
     include('header.html');
?>
     <p>All your information on the home page.</p>
php
     include('footer.html');
?>

tutorial.php

php
     include('header.html');
?>
     <p>All your information on the tutorialpage.</p>
php
     include('footer.html');
?>

about-us.php

php
     include('header.html');
?>
     <p>All your information on the about us page.</p>
php
     include('footer.html');
?>

contact-us.php

php
     include('header.html');
?>
     <p>All your information on the contact us page.</p>
php
     include('footer.html');
?>

See now with this structure we no longer would have to change something on each page to be able to change something on each page. Say we have the first example of wanting to change the “tutorial” in the navigation to “how to carve spindles” then we would only have to change the header.html like such.

header.html

<html>
     <head>
          <title>Creating Hand Carved Spindles</title>
     </head>
     <body>
          <div id="container">
               <div id="nav">
                    <ul>
                          <li>Home</li>

	<li><span style="color: #<span class=;">ff0000</span>;">How to Carve Spindles</li>
                          <li>About Us</li>
                          <li>Contact Us</li>
                    </ul>
               <div id="content">

So when someone goes to your site and the web server looks at index.html it reads the include and output the content of the file for header.html and footer.html. This makes it all look like just one big HTML file, like we started with. You can tie this in with the post here about flat file caching to not only make it so you only have to edit header and footer info in one place but you can make your site run completely off of index/header/footer by including cache files.

On thing to keep in mind is that with dynamic websites comes a lot more responsibility as well as flexibility. You will have to do error checking through the use of conditional statements. When you are using these includes if the file that you try to include does not exist then there will be an ugly PHP error on your website. Conditional statements have many other uses and are probably one of the most basic and commonly used aspects of programming languages like PHP. Here is an example as how/where you would want to use it here.

<?php
     if(!file_exists('header.html'))
     {
          die('Sorry we are experiencing technical difficulties.  Please come back later.');
     }
     else
          include('header.html');
?>

This adds a check that the file exists so that your users will see an error message instead of seeing an ugly PHP error.

I hope you enjoyed the article. Please feel free to ask your questions in comments.

7 Written ArticlesWebsite

I am a web developer by trade but originally went to school for Information Technology - Network Engineering Technology at Purdue University. Getting into web development as a student web developer I developed a passion for it that left networking seem a bit boring. Even though I finished up my networking degree I stuck with web development lately I have been a WP7 advocate. My Blog.

18 Comments Best Comments First
  • Brett Widmann

    Tuesday, January 25th, 2011 21:57

    13

    This was really helpful. I appreciate the great information and the code works great.

    +1
    • Roy

      Sunday, March 13th, 2011 17:51

      14

      Thanks! This is helpful. However, after this, I got another question. If there are other linkages in the content pages, how can the content keeps displaying on the same area when entering to those links? I think this is a little difficult to explain, but I hope you would understand what I mean, thanks!

      -1
  • Rahul

    Thursday, October 7th, 2010 16:51

    8

    I never found one thing like these when I was in need..Well its never late to learn

    0
  • byme

    Wednesday, October 6th, 2010 15:11

    1

    i have learned php long time ago and until now i still confused
    huh

    0
    • brad

      Thursday, October 7th, 2010 12:46

      6

      What is it that you are confused about? Anything that I can help with? I have another blog coming soon that talks about server side (PHP) vs client side (HTML).

      0
      • progmata

        Thursday, October 7th, 2010 23:10

        9

        When come blog, and what will address, me too now learn php-html connect.

        Nice post btw.

        0
  • Edwar Beckett

    Wednesday, October 6th, 2010 19:22

    2

    Don’t mean to nag here … but testing for the existence of a header would be unnecessary and simply add processing overhead …

    Why wouldn’t your header exist?

    0
    • brad

      Thursday, October 7th, 2010 12:45

      5

      Not a nag at all but when you get more into programming you will realize the old saying is very true “What can go wrong WILL go wrong”. Most likely you do not need to check for your header but the amount of process overhead is so extremely small that it isn’t any concern. Unless you are serving it up on a and old P1 maybe.

      +1
      • Charles

        Tuesday, August 23rd, 2011 22:20

        17

        Any file can be accidently erased–Murphy’s Law says it will be the one file which you assume will always exist. I’ve used existence checks to do many different things, including recompile an entire set of code from scratch–in that case because it was absolutely vital that the code run in order for the company to run. It is far too easy for a programmer to accidently destroy a module which they don’t know is essential. In this particular case, the code needed was passing information between two MRP packages and resided deep inside the structure…errors caused by it’s failure could easily be difficult to find because they could crop up anywhere in either system….

        In code, assumptions will almost always find a way to bite you at the worst time and place.

        In my experience, it’s best to leave an essential part of the user interface ‘unfinished’ until all error checks and testing is complete. Management invariably decides that if it looks done on the outside, it must be ready to fly–and it’s the programmer’s fault if it crashes.

        Far to many people assume that errors of specific types will never happen, but fools are endlessly ingenious and if it can happen, it probably will happen.

        Actual code execution on any modern machine is a trivial portion of it’s functioning–far more energy goes to dealing with fancy interface stuff (unfortunately usually to the detriment of the actual functionality.

        It’s usually a great idea to watch a virgin user work with your programs in order to: 1) find error-checking holes 2) write user documentation 3) verify that things are actually doing what is needed (not necessarily what the customer wanted.)

        The worst thing that can happen to most code is for the documentation to be written solely by the program author, since they already know exactly how to use it, they have little empathy for the poor user who faces it for the very first time.

        It is most essential to document thoroughly those portions of the system which will be least commonly used. The daily use stuff, once learned, is not likely to be forgotten. I’ve seen financial systems which documented every detail of the day-to-day work, but month end was less well documented, and year end was almost undocumented.

        In 20 odd years of programming, the single hardest function was to convince management to permit me the time and effort to make certain that the code was ‘bullet-proof’ and verify that it actually did what was required.

        There are possible problems with redundant error checking, of course, since each piece of code added adds yet another place for the code to fail. But it is always best to at least check that out-of-range errors are caught and that error messages are meaningful (unlike most error messages.)

        0
  • Daniel

    Thursday, October 7th, 2010 00:36

    3

    Great tip! I always wanted to know how php worked with html pages. Are you going to post more advanced stuff in the future?

    0
  • ben

    Thursday, October 7th, 2010 06:12

    4

    Dig it! Great article. I wish they had one of these tutorials when I was learnding.

    0
  • Darren Nickerson

    Thursday, October 7th, 2010 21:18

    10

    A couple of your examples you forgot <? on your opening php codes. Just to let you know in case someone is copying the code. Great example of using php to make a design more like a template.

    0
  • Angol

    Friday, April 6th, 2012 18:27

    18

    This was really helpful to me too.
    I have a question> how do I group the files according to folders? php folder, html folder, css folder, & images folder?

    0
  • Nitin

    Thursday, April 21st, 2011 07:46

    15

    I am wondering to see the closing nav div tag in the code above

    0
  • Shrikrishna Meena

    Friday, October 8th, 2010 13:01

    11

    Well, As for beginners This article will definitely motivate them to start learning PHP.

    0
  • sanjay

    Monday, October 11th, 2010 09:29

    12

    this is helpful to newbies, perhaps more advance next time :D Btw nice post!

    0
  • Angol

    Friday, April 6th, 2012 18:27

    18

    This was really helpful to me too.
    I have a question> how do I group the files according to folders? php folder, html folder, css folder, & images folder?

    0
  • Nitin

    Thursday, April 21st, 2011 07:46

    15

    I am wondering to see the closing nav div tag in the code above

    0
  • Brett Widmann

    Tuesday, January 25th, 2011 21:57

    13

    This was really helpful. I appreciate the great information and the code works great.

    +1
    • Roy

      Sunday, March 13th, 2011 17:51

      14

      Thanks! This is helpful. However, after this, I got another question. If there are other linkages in the content pages, how can the content keeps displaying on the same area when entering to those links? I think this is a little difficult to explain, but I hope you would understand what I mean, thanks!

      -1
  • sanjay

    Monday, October 11th, 2010 09:29

    12

    this is helpful to newbies, perhaps more advance next time :D Btw nice post!

    0
  • Shrikrishna Meena

    Friday, October 8th, 2010 13:01

    11

    Well, As for beginners This article will definitely motivate them to start learning PHP.

    0
  • Darren Nickerson

    Thursday, October 7th, 2010 21:18

    10

    A couple of your examples you forgot <? on your opening php codes. Just to let you know in case someone is copying the code. Great example of using php to make a design more like a template.

    0
  • Rahul

    Thursday, October 7th, 2010 16:51

    8

    I never found one thing like these when I was in need..Well its never late to learn

    0
  • ben

    Thursday, October 7th, 2010 06:12

    4

    Dig it! Great article. I wish they had one of these tutorials when I was learnding.

    0
  • Daniel

    Thursday, October 7th, 2010 00:36

    3

    Great tip! I always wanted to know how php worked with html pages. Are you going to post more advanced stuff in the future?

    0
  • Edwar Beckett

    Wednesday, October 6th, 2010 19:22

    2

    Don’t mean to nag here … but testing for the existence of a header would be unnecessary and simply add processing overhead …

    Why wouldn’t your header exist?

    0
    • brad

      Thursday, October 7th, 2010 12:45

      5

      Not a nag at all but when you get more into programming you will realize the old saying is very true “What can go wrong WILL go wrong”. Most likely you do not need to check for your header but the amount of process overhead is so extremely small that it isn’t any concern. Unless you are serving it up on a and old P1 maybe.

      +1
      • Charles

        Tuesday, August 23rd, 2011 22:20

        17

        Any file can be accidently erased–Murphy’s Law says it will be the one file which you assume will always exist. I’ve used existence checks to do many different things, including recompile an entire set of code from scratch–in that case because it was absolutely vital that the code run in order for the company to run. It is far too easy for a programmer to accidently destroy a module which they don’t know is essential. In this particular case, the code needed was passing information between two MRP packages and resided deep inside the structure…errors caused by it’s failure could easily be difficult to find because they could crop up anywhere in either system….

        In code, assumptions will almost always find a way to bite you at the worst time and place.

        In my experience, it’s best to leave an essential part of the user interface ‘unfinished’ until all error checks and testing is complete. Management invariably decides that if it looks done on the outside, it must be ready to fly–and it’s the programmer’s fault if it crashes.

        Far to many people assume that errors of specific types will never happen, but fools are endlessly ingenious and if it can happen, it probably will happen.

        Actual code execution on any modern machine is a trivial portion of it’s functioning–far more energy goes to dealing with fancy interface stuff (unfortunately usually to the detriment of the actual functionality.

        It’s usually a great idea to watch a virgin user work with your programs in order to: 1) find error-checking holes 2) write user documentation 3) verify that things are actually doing what is needed (not necessarily what the customer wanted.)

        The worst thing that can happen to most code is for the documentation to be written solely by the program author, since they already know exactly how to use it, they have little empathy for the poor user who faces it for the very first time.

        It is most essential to document thoroughly those portions of the system which will be least commonly used. The daily use stuff, once learned, is not likely to be forgotten. I’ve seen financial systems which documented every detail of the day-to-day work, but month end was less well documented, and year end was almost undocumented.

        In 20 odd years of programming, the single hardest function was to convince management to permit me the time and effort to make certain that the code was ‘bullet-proof’ and verify that it actually did what was required.

        There are possible problems with redundant error checking, of course, since each piece of code added adds yet another place for the code to fail. But it is always best to at least check that out-of-range errors are caught and that error messages are meaningful (unlike most error messages.)

        0
  • byme

    Wednesday, October 6th, 2010 15:11

    1

    i have learned php long time ago and until now i still confused
    huh

    0
    • brad

      Thursday, October 7th, 2010 12:46

      6

      What is it that you are confused about? Anything that I can help with? I have another blog coming soon that talks about server side (PHP) vs client side (HTML).

      0
      • progmata

        Thursday, October 7th, 2010 23:10

        9

        When come blog, and what will address, me too now learn php-html connect.

        Nice post btw.

        0

Comments are closed.

54.196.162.238 - unknown - unknown - US