By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,382 Members | 1,743 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,382 IT Pros & Developers. It's quick & easy.

Dividing PHP and HTML - maybe easy

P: n/a
Hi,

Summary:
Best way to divide out the HTML and PHP in some code I inherited. How can I
keep the HTML files separate?

Full Details:
I've now been working two weeks on PHP / MySQL code I inherited and the
client is a happy bunny. This was my first crash course outing with PHP, but
with basic PERL experience found it fairly easy to pick up and used the code
I inherited as my guide.

However, the current code has every page as being top half php, bottom half
HTML (with some embedded PHP where necessary)

Eg.
START OF FILE
<?php

do some general processing to set up variables
?>

<HR>

<!--HTML CODE-->
<!-- note that the current code does not even output a HTML HEAD tag - any
reason why this might be?--?
<? occasional bit of PHP ?>
<P>
End of HTML
END OF FILE

The HTML pages are ugly and they have very much hard coded formatting
information in them.
Hence the application is entire need of an overall.

What is the best way to approach this?
I really would like to keep the HTML parts in another file so they could be
editing in programs like dreamweaver to be honest. I obviously want to role
out the use of CSS so that I can change the look and feel quickly.

Is there a command in PHP that when the main processing is done you can
reference another file which contains HTML to be displayed but none of the
current variable information is lost.
I say this because if I use the header(location:) command I have to repost
the form variables which is pain.

Ideally I could just have the main PHP bit in the code, and when it is done
it references a HTML page that is displayed(That HTML page may contain
snippets of PHP). So functionally things still work as they are, but it lets
me put the HTML in a physically different file.

I hope this makes sense.

Thanks in advance.

Kind regards

Dave

PS: Having just written this, I then tried to open one of my PHP files in
dreamweaver and what do you know, it opens and of course handles the PHP.
Still I still think the question is valid and maybe I will be told it is not
a good idea to use Dreamweaver to manage code with PHP in it.
Jul 17 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Dave Smithz wrote:
Hi,

Summary:
Best way to divide out the HTML and PHP in some code I inherited. How can I
keep the HTML files separate?

Full Details:
I've now been working two weeks on PHP / MySQL code I inherited and the
client is a happy bunny. This was my first crash course outing with PHP, but
with basic PERL experience found it fairly easy to pick up and used the code
I inherited as my guide.

However, the current code has every page as being top half php, bottom half
HTML (with some embedded PHP where necessary)

<!-- note that the current code does not even output a HTML HEAD tag - any


If you look at the HTML source output by the server, does it have a
<head>? If it does, PHP may be configured to automatically prepend a
file to every script. (It can also be configured to append a file.) If
there is no <head>, then you've got some work to do if you intend to
make it comply with the HTML spec's.

I'm no expert, but one way would be to put the HTML block in a file with
the same name as the PHP file, but with an HTM[L] extension, then
include the HTML file at the end of the PHP file:

foo.php:
-----
<?php

do some general processing to set up variables

include "foo.html";

?>
-----

foo.html:
-----
<HR>

<!--HTML CODE-->
<? occasional bit of PHP ?>
<P>
-----

NM

--
convert UPPERCASE NUMBER to a numeral to reply
Jul 17 '05 #2

P: n/a
Hi Dave.

One way to completely separate PHP & HTML is to use Templates.

Two templating systems come to mind:

1. PEAR::HTML_Template_IT
Man page:
http://pear.php.net/manual/en/packag...emplate-it.php
PEAR Home: http://pear.php.net/
PHP comes with all required to install PEAR core elements, among which (I
think) is HTML_Template_IT.
I have used this extensively and find it works extremely well. My only
concern is that I find template load time is relatively high, with my 10K+
templates taking 0.2 - 0.3 seconds to load.
This is why I intend to investigate another templating system...

2. Smarty.
Home: http://smarty.php.net/
I have not used this yet, but note it has a smart caching feature, caching
templates once loaded. Heaps of other features also. Just reading it myself
now.

Probably plenty of other templating solutions, but these two are part of the
php nuclear family, with plenty of news group and other support.

Hope this helps.

Laurence

"Dave Smithz" <SPAM FREE WORLD> wrote in message
news:42********@news1.homechoice.co.uk...
Hi,

Summary:
Best way to divide out the HTML and PHP in some code I inherited. How can
I
keep the HTML files separate?

Full Details:
I've now been working two weeks on PHP / MySQL code I inherited and the
client is a happy bunny. This was my first crash course outing with PHP,
but
with basic PERL experience found it fairly easy to pick up and used the
code
I inherited as my guide.

However, the current code has every page as being top half php, bottom
half
HTML (with some embedded PHP where necessary)

Eg.
START OF FILE
<?php

do some general processing to set up variables
?>

<HR>

<!--HTML CODE-->
<!-- note that the current code does not even output a HTML HEAD tag - any
reason why this might be?--?
<? occasional bit of PHP ?>
<P>
End of HTML
END OF FILE

The HTML pages are ugly and they have very much hard coded formatting
information in them.
Hence the application is entire need of an overall.

What is the best way to approach this?
I really would like to keep the HTML parts in another file so they could
be
editing in programs like dreamweaver to be honest. I obviously want to
role
out the use of CSS so that I can change the look and feel quickly.

Is there a command in PHP that when the main processing is done you can
reference another file which contains HTML to be displayed but none of the
current variable information is lost.
I say this because if I use the header(location:) command I have to repost
the form variables which is pain.

Ideally I could just have the main PHP bit in the code, and when it is
done
it references a HTML page that is displayed(That HTML page may contain
snippets of PHP). So functionally things still work as they are, but it
lets
me put the HTML in a physically different file.

I hope this makes sense.

Thanks in advance.

Kind regards

Dave

PS: Having just written this, I then tried to open one of my PHP files in
dreamweaver and what do you know, it opens and of course handles the PHP.
Still I still think the question is valid and maybe I will be told it is
not
a good idea to use Dreamweaver to manage code with PHP in it.

Jul 17 '05 #3

P: n/a
"Dave Smithz" <SPAM FREE WORLD> wrote in message
news:42********@news1.homechoice.co.uk...
Hi,

Summary:
Best way to divide out the HTML and PHP in some code I inherited. How can I keep the HTML files separate?


"The downside of separating HTML from PHP code is you don't get to use PHP
in your HTML code."

That's a rather banal statement but it's a point that people often fail to
consider. PHP is a very powerful tool. When you exclude it from HTML then
you lose a lot of power in controlling the appearance of your web pages. My
advise is unless you really need to do it, don't.

Instead of separating code by technology (HTML vs PHP), separate them by
purpose. For example, I keep code that deal with the user interface in a
file call interface.php. It contains mostly HTML with some PHP sprinkled in:

<? function PrintHeader($title) { ?>
<html>
<head>
<title><? echo htmlspecialchars($title); ?></title>
</head>
<body>
<? } ?>
<? function PrintMessage($msg) { ?>
<div>
...
</div>
<? } ?>
<? function PrintFooter() { ?>
</body>
</html>
<? } ?>

To print the various parts of the page I just call the appropriate function.

This is a more powerful technique than simply including a header.htm and a
footer.htm, as you can pass parameters to these functions and utilize PHP
functions for text manipulations. The file will also render correctly in a
browser/editor.
Jul 17 '05 #4

P: n/a

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:2M********************@comcast.com...
"The downside of separating HTML from PHP code is you don't get to use PHP
in your HTML code."
The downside of mixing php into your html is that you land up with
unmaintainable code, especially if you are creating a dynamic website for a
third-party (think customer?) who can only handle html.

It also makes redesigning the site a lot harder, since you have to be
incredibly careful about moving the PHP code around. Also, I would argue
that separating PHP and HTML files isn't "separating files by technology";
rather, it's "separating code and data".

Creating html-type templates, with simple text placeholders for fields,
allows non-expert users to play with the presentation without breaking the
site. It also allows you various other options, like:

- 'You can change anything in the /templates directory, just don't touch any
of the PHP files'

- Automatic uploading of template files, so that you can block the
client/intranet editor/whoever from editing/accessing the source code.
Apart from the potential considerations of "who gets to see the source
code", it also means you can provide users with a *safe* way to modify a
site's look

- Online editing of template files - use CMS-type markup to change the look
of a site, without any requirement for HTMl editing or FTP access, etc.

- Running all (or most) of your site through a single PHP file - I like to
use URL rewriting for this. Avoid duplicating the same code across multiple
files, so that you don't forget to change that essential line in 52
different places

- More readable code - you can see what's happening, and why, and where.

- Better code maintainability in general

- Better security - you can make sure that there are no unexpected PHP tags
in the templates

- etc, etc
That's a rather banal statement but it's a point that people often fail to
consider. PHP is a very powerful tool. When you exclude it from HTML then
you lose a lot of power in controlling the appearance of your web pages.
My
advise is unless you really need to do it, don't.


PHP *is* a very powerful tool, and like all powerful tools, performs best
when handled carefully. If you are fixing a climbing frame for a child,
using an arc-welder, you fix the frame and give it back to them. You don't
leave the welder there where they can use it.

Embedding php is great for quick-and-dirty tasks. If you're doing something
more complex, it is no longer quick, and all you're left with is dirty. I
would advise, only embed php in html if you have to. If you extend the site
in future, you may live to regret it!

Matt
Jul 17 '05 #5

P: n/a
NC
Dave Smithz wrote:

Summary:
Best way to divide out the HTML and PHP in some code I inherited.
How can I keep the HTML files separate?
Templating might help...
<!--HTML CODE-->
<!-- note that the current code does not even output a HTML HEAD tag
- any reason why this might be? -->
Because <HEAD> and <BODY> tags became optional as of HTML 4.0,
perhaps?
Is there a command in PHP that when the main processing is done
you can reference another file which contains HTML to be displayed
but none of the current variable information is lost. .... Ideally I could just have the main PHP bit in the code, and when
it is done it references a HTML page that is displayed(That HTML
page may contain snippets of PHP). So functionally things still
work as they are, but it lets me put the HTML in a physically
different file.


Have you used include/require at all?

Cheers,
NC

Jul 17 '05 #6

P: n/a
NC wrote:
Dave Smithz wrote:

<!--HTML CODE-->
<!-- note that the current code does not even output a HTML HEAD tag
- any reason why this might be? -->


Because <HEAD> and <BODY> tags became optional as of HTML 4.0,
perhaps?


The tags are not required by earlier versions either.

Their being omissible is not in itself a reason to omit
them. Ciwah's recommendation, I faintly recollect, is to
include both sets of tags.

Slainte!

--
Jock
Jul 17 '05 #7

P: n/a
"Matt Mitchell" <m_****************************@metalsponge.net> wrote in
message news:mL******************@fe1.news.blueyonder.co.u k...
The downside of mixing php into your html is that you land up with
unmaintainable code, especially if you are creating a dynamic website for a third-party (think customer?) who can only handle html.
Well, I'm not saying one should never use templates. If one of the
requirements is allowing the end-user to edit the HTML, then you implement
it, accepting the necessary trade off. If it's not, then why tie your hands
yourself?
It also makes redesigning the site a lot harder, since you have to be
incredibly careful about moving the PHP code around. Also, I would argue
that separating PHP and HTML files isn't "separating files by technology";
rather, it's "separating code and data".
You are not saying much as why having PHP code in HTML makes for
unmaintainable code--other than that it is. No one is arguing for mixing
things up randomly. As I said, one should divide code up by purpose. If the
purpose of a block of PHP code is controlling some aspect of a webpage's
appearance, then it's perfectly natural to place it where it has its affect.
If you're changing the appearance of the site, then chances are, you need to
change any PHP code related to representation too.
Creating html-type templates, with simple text placeholders for fields,
allows non-expert users to play with the presentation without breaking the
site. It also allows you various other options, like:
Just wait till your non-expert user starts messing around with your input
fields and hyperlinks. It's a freaking support nightmare. HTML is hardly the
safe medium that you described. Make a small mistake and you have a
cross-site scripting vulnerability and the whole application is shot.
- Better security - you can make sure that there are no unexpected PHP tags in the templates


One word: phpBB. The Santy worm exploited a weakness in phpBB's template
system.
Jul 17 '05 #8

P: n/a

"NC" <nc@iname.com> wrote in message
Have you used include/require at all?


Errrrr, actually I had only read about require_once, but it would seem that
include can just allow me to have the HTML part (with little bits of
embedded PHP where necessary) in a separate file that is called with an
include.

Not tested it yet but it seems when I use an include it will be interpreted
as HTML treated as if in the same file. This is great and good enough for my
needs. Because I came to PHP from inheriting someone else's code, I have
missed a formal tutorial in some of the basics.

Cheers and let me know if I'm wrong on my assumptions above.

Regards

Dave
Jul 17 '05 #9

P: n/a
"Chung Leong" <ch***********@hotmail.com> wrote in message
news:u_********************@comcast.com...
: Well, I'm not saying one should never use templates. If one of the
: requirements is allowing the end-user to edit the HTML, then you implement
: it, accepting the necessary trade off. If it's not, then why tie your
hands
: yourself?

Because that way I can change the way something looks, without having to
worry about how it works. It also means I can change the way it works,
without having to change the way it looks...

: You are not saying much as why having PHP code in HTML makes for
: unmaintainable code--other than that it is. No one is arguing for mixing
: things up randomly. As I said, one should divide code up by purpose. If
the
: purpose of a block of PHP code is controlling some aspect of a webpage's
: appearance, then it's perfectly natural to place it where it has its
affect.
: If you're changing the appearance of the site, then chances are, you need
to
: change any PHP code related to representation too.

So moving something displaying on the left of the page to the right is a
PHP, not an HTML issue???

: Just wait till your non-expert user starts messing around with your input
: fields and hyperlinks. It's a freaking support nightmare. HTML is hardly
the
: safe medium that you described. Make a small mistake and you have a
: cross-site scripting vulnerability and the whole application is shot.

No, it depends on what fields you let them substitute in, and how you do it.

If the list of available placeholders is something like

[field:user:username] [field:site:sitename]

without including things like
[field:config:dbpassword]

then you're OK. If your template system is braindead enough to display
current filepath, database host, user password, etc, then it is a fault with
your templating system, and with your code, not with the concept of
templates. Similarly, the existence of computer viruses doesn't prove that
computers are useless, it proves that you have to adopt sensible security
practices.

Validate user data. Don't allow them to insert javascript, php code, sql
injections etc. Don't pass query strings into your app without checking
what they contain, and removing the nasty stuff.

:
: > - Better security - you can make sure that there are no unexpected PHP
: tags
: > in the templates
:
: One word: phpBB. The Santy worm exploited a weakness in phpBB's template
: system.
:

That's a flaw in phpbb's template system. I fail to see how a template
system that allows you to put
<?php
system('rm -fR ./*');
?>

or to allow an html file containing the same, can be a good thing.

Jul 17 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.