I am completely redoing my personal site, just because it's time for a little change. It's been the same for nearly three years, and instead of changing the colors a little bit and moving things around, I'm starting from scratch so I can do it right. I need some help though.

I've been fooling around with HTML for about 5 or 6 years now, but I've never been neat with it. Sure, I indent my tables and everything fine, and I have no problem finding what I need in my own code, but I want to code right. Not only that, but I want to be fully compliant. I read up on how to be XHTML compliant, and that's what I'm aiming for. It won't be too hard, as I've always done most of the things that make it more strict anyway. I always write tags in lower-case, put quotes around my values, and close tags properly. The main difference is that now I'll be writing different empty elements (<br />).

So, I've read up on the DTD stuff (I assume I'll use "transitional"), and now I want to know what I need to do to be fully HTML 4.01 compliant.

Lastly, I need to know a couple PHP things. First the large one: how do I do this "page creation on the fly" thing. I don't really understand it.

The other thing I want to know is just a code thing. I was wondering if there is a way for a page to know where it is on the server, or the address it's at. For instance, I want a page that's loaded to know which directory on my site it is in.

Thanks, I know this is a lot, but I'm just starting this whole process over and I want to do it right this time. This is what happens when you learn HTML by starting with Frontpage . Don't worry, I only used it for a few months, but I've been trying to correct myself ever since.

The other thing I want to know is just a code thing. I was wondering if there is a way for a page to know where it is on the server, or the address it's at. For instance, I want a page that's loaded to know which directory on my site it is in.

Those types of things are in $_SERVER.

Put this in a page to see them all:

<PRE>

<?php print_r($_SERVER); ?>

</PRE>

This only works on a PHP-enabled web page and server, as should be obvious, but was not pointed out explicitly.

Right. He said:

Lastly, I need to know a couple PHP things.

And then listed two things.
So I was assuming he wanted to know how to do that in PHP.

I want a page that's loaded to know which directory on my site it is in.

One question: Why? Maybe there's a better way to achieve what you're trying to do.

Well, I want to have one bit of code for my menu, like I've had before. I want to have the button for the appropriate section to be different when you're on one of those pages. I was just going to find a way for the page to know where it was loaded, then load the appropriate image for that button at that point. If there's another way to do it I'm open to suggestion!

And as I said, I'd like to try this "on the fly" thing that people keep mentioning. Not sure what they mean though.

When most web types talk about 'on-the-fly' page generation, they just mean that the page is built from a number of elements, usually pulled from a database specifically for the person making the request for that page.

Almost every page you write with some PHP in it can be considered to be generated 'on-the-fly'. A good example would be a basic page containing a news story. The client calls the page with the URL news.php?id=10. Your server goes to the news.php page, runs an SQL query and pulls the news story in from the database, inserts it into the middle of some HTML and returns that page to the client.

That makes sense. I guess I'm doing some of that already. Would includes count in that way?

I was just going to find a way for the page to know where it was loaded, then load the appropriate image for that button at that point. If there's another way to do it I'm open to suggestion!


I typically write my sites to run from a wrapper script. This means that the URL always contains the section of the site you are in and it can simply be called by looking at the variables passed to the script, rather than the actual file being loaded.

For example:

index.php?f=about instead of about.php
index.php?f=news instead of news.php

To the user, it looks like the entire site is running from one huge script, but in your index.php script, simply put the line:

include($f.'.php');

This will just load the file named news.php. You'll want some error handling code here - check that the file exists and if it doesn't default to something like home.php.

For your navigation, you can now work out what page you are on simply by looking at the content of $f.

Another benefit of using wrapper scripts is that you can call commonly used code in one place, so you don't need to have include calls and database connection code at the top of every script.

Thanks, that's an interesting idea, and I'm sure I could get it to work, but what do I do about my Gallery and message boards? That wouldn't really work, would it?

Includes count, but I suppose it's really anywhere that you return something based on what the user has requested, such as content from a database, do an if/else, or return something that changes constantly like the current date and time.

I tend to refer to this type of thing as 'dynamic' pages.

It really depends on how the gallery and message board scripts work. There's lots of ways to get around that though.

Not sure what you'd look for in how they work, but I would think it would be difficult to use this method since the board is generating its own links.

I'm not sure I like the idea of a wrapper, because I like to be organized by directory and such, and I kind of like the users to see that reflected in the address, but I'll think about it.

I just remembered something. Gallery and the message board have their own style sheets, so maybe I could try to do something with that for those sections.

I'm not sure I like the idea of a wrapper, because I like to be organized by directory and such, and I kind of like the users to see that reflected in the address, but I'll think about it.

That's where mod_rewrite comes in. You can make a URL of http://www.site.com/news/23/ map to http://www.site.com/index.php?f=news&id=23.

There's a tutorial here: http://www.alistapart.com/articles/succeed/

I see. That's interesting, and I'll read up on that, but I'd just like to ask why simply reading the $SCRIPT_URL variable isn't the way to go? Seems more simple to me.

So I've worked out the menu thing using part of the PHP solution Ricin posted at the top of the thread.

Now I need some standards help. I've not had too much of a problem with the XHTML transition, except for one thing that they have made incredibly difficult: table height.

Okay, so the HTML table height tag has deprecated. But they've made it so that it is far more difficult to do using CSS. Why? This is incredibly frustrating.

So I have a table 750 pixels wide which I want to fill the page. This table only has two rows, the top one with a menu 60 pixels high, and the bottom one I want to expand to the size of the current area. In order to get the table to expand at all, I had to have this in the style sheet:

html, body
{
text-align: center;
margin: 0px;
padding: 0px;
height: 100%
}

I'm doing this entirely in styles now, because I've been told to So I have a class for the table with 'height: 100%', and class for the cells in the first row (three of them) all with 'heigh: 60px'. In old, lenient, HTML (in IE, at least), this would automatically expand the bottom row to fill out the 100% specified for the table. This does, in fact, make a table that fits 100% of the screen, but the top row has been pulled taller, and the two rows don't even match in size! Even when I take out the height for the top row, when I should get a result of two rows each taking up half of the screen, it's the same odd size as before.

So, I put the 60px height back in for the top row, and try adding a 100% to one of the cells on the bottom (still using classes). This time everything initially looks like it should, with the menu the correct height and the bottom row filling the rest of the screen, but then I notice that I have a vertical scrollbar. Turns out that the 100% for the bottom row meant 100% of the entire page and not just what was left after the 60px is taken out.

So I ask two things: first, how do I do what I'm trying to do using CSS? and second, why in God's name is this supposed to be better? Using simple HTML I could do this with absolutely no problem whatsoever. Yes, browsers displayed things differently, but as far as I could see that was the fault of the browsers and not the standard. It's a standard that wasn't lived up to. Why is this supposed to be different, and why the hell did they make it so difficult??

I couldn't figure out how to do it with tables, but you can do it with divs in strict mode:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">

<html>

        <head>

                <title>

                        table test

                </title>

                <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

                <style type="text/css">

                        html,body {

                                background: blue;

                                text-align: center;

                                margin: 0px;

                                padding: 0px;

                                height: 100%;

                        }

                </style>

        </head>

        <body>

                <div style="height: 100%; border: 10px solid #000000">

                        <div style="height: 60px; border: 10px solid #FF0000">upper</div>

                lower</div>

        </body>

</html>

Also note that you don't have to have styles defined for elements; you can put CSS stuff directly in the style attribute.

Oh, wait. I see how to do it with tables:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html>

        <head>

                <title>

                        table test

                </title>

                <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

                <style type="text/css">

                        html,body {

                                text-align: center;

                                margin: 0px;

                                padding: 0px;

                                height: 100%;

                        }

                </style>

        </head>

        <body>

                <table border="1" style="height: 100%; width: 100%">

                <tr style="height: 60px"><td>top</td></tr>

                <tr style="height: 100%"><td>bottom</td></tr>

                </table>

        </body>

</html>

I'd forgotten to give the table a style height of 100% as well as the other elements.

Oh hey! I wasn't aware that you could put styles on the rows instead of the cells. Interesting.

*edit*
well, I tried what you posted and got the same problem I had in the end the way I did it before. Did you get a scroll bar and about 60px of space to scroll down?

Nope. But, then, I was trying under OmniWeb.

It seems that IE is the only one that does it wrong.

These people seem to have come to the same conclusion.

Wow. Try resizing the IE window vertically. Making it smaller causes the 100% row to remain the same size. Making it larger causes the 100% row to grow to always be too big. I'd say that this is a huge bug in IE. Period. That doesn't help you, since most of your users will have the same bug, but it seems to be the case.

Try this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html>

        <head>

                <title>

                        table test

                </title>

                <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

                <style type="text/css">

                        html,body { text-align: center; margin: 0px; padding: 0px; height: 100%; }

			table.mytable  { width: 100%; height: 100% }

			td.hundred { width: 100%; height: 100%; vertical-align: top; border: solid 2px #000 }

			td.sixty   { width: 100%; height: 60px; vertical-align: top; border: solid 2px #000 }

                </style>

        </head>

        <body>

                <table class="mytable">

                <tr><td class="sixty">top</td></tr>

                <tr><td class="hundred">bottom</td></tr>

                </table>

        </body>

</html>

FWIW, that does the exact same thing for me: works everywhere but IE.

Perhaps I am misunderstanding what it is that is trying to be accomplished. We don't want the vertical scrollbar on the right hand side, but rather the bottom of the table coming to the bottom of the viewable window?

Right. That's how Mozilla 1.5, Firefox 0.8, and OmniWeb 4.5 all render that code, but not IE, which seems to tack on an additional 60px, so that the entire table can never be seen all at once. In other words, it assumes that 100% is an immutable size unchanged by any other elements on the page.

In other words, it assumes that 100% is an immutable size unchanged by any other elements on the page.

Don't get me started on wonky table layout algorithms in mainstream browsers.

Peter

I think it all works right if you use divs, though. The first example above works perfectly if you remove the border of the outermost div, otherwise, it overdraws by the height of the top and bottom borders. I'm not quite sure how to do side-by-side with divs, but I'm sure it's easily possible.

Thanks for all the work, Bitt. I appreciate it. It figures that I'm trying to adopt the standard, and now IE screws me over. My experience has usually been that IE renders things more logically than other browsers. Of course, it's probably becuase it was being more lenient than other browsers, which isn't all that great to begin with.

Grr. Frustration. I guess I won't have it fill the screen. Adding a bottom border of some sort to my pages is better than confusing my IE users with extra space that doesn't contain anything.

probably becuase it was being more lenient

I'm of the opinion that one should run every HTML page through http://validator.w3.org.

I would have done that before, but I was still recycling very old code from when I didn't care about following the standards at all. If it worked and displayed correctly for me, I didn't care.

Now that I'm following the standards, I definitely plan on running it through the validator. My style sheets too.

Uhm, try this:

<table width="100% height="100%">
<tr>
<td height="60px">Cel 1</td></tr>
<tr>
<td>Cel 2</td>
</table>

Edit/add/change rows/columns as necessary.. Any cels in the top row that should only be 60px high, add the "height='60px'". The cels of the table that "expand" to the rest of the table, DO NOT add a 'height' tag. Using styles on table sections, I've found, ruins it..

Me.

But that's not valid HTML post-3.whatever.

Yeah, if you specify the DTD at the top of the page, it won't allow ANY height tags in the page. It will allow height styles, though, but that produces what we've been discussing.

Also, I've found that if I try to mix width tags with width styles, I get unusual results. So, pretty much the only tags I have in my tables are class, cellspacing, and cellpadding. Why they didn't add those last two to CSS is beyond me. Seems hypocritical to me, to demand the use of styles for some things and just ignore others.

But that's not valid HTML post-3.whatever.

Why? Because it LACKS the WIDTH tag, or some other reason?

(Only asking for curiosity sake. I use that alla time, and have yet to have a problem on any of the 'common' browsers..)

Me.

Sorry. I completely missed that until i went back to look at the examples. Yeah, CSS w/h and tag w/h really mess things up. I have pulled alot of hair out trying to get things to lay out properly. (My beef was with WIDTH, and had numerous problems, where IE would do as expected, but then Opera/Mozilla would be 'short', then fix it, and IE would be too far right..) Unfortunately, since many, many people *USE* IE, you can't just say, 'screw Macrosoft..' and do it the way you want.. (Well, at least, you can't when you do commercial sites, like the one I'm workign on..)

Me..

Because height, amongst, I'm sure, other attributes, is deprecated in HTML 4 and greater, including XHTML.

So, basically, in HTML 4, they're moving everything to stylesheets? Interesting..
Thanks!
Me.

amongst, I'm sure, other attributes

Yup, plenty. I understand the idea, but anyone here could do it better than they are now. I haven't a clue what the W3C thinks they're doing. There seems to be no rhyme or reason as to how they decide to move to new standards.

I also like how many of the sites I see are talking about conforming to the standards, but they use the <font> tag, which I thought wasn't allowed.

I agree. I think it's stupid to deprecate all the tags' attributes so that you can reintegrate them within the style attribute. Have the browsers do half an iota of work and understand the regular attributes, too, and internally convert them to style-type information. It's just making things more difficult for HTML writers.

default to something like home.php.

I've been playing with something like this a little. I have an some other questions:

What if I want to return a 404 instead? How do I raise a 404 response error in PHP?

More specifically, I've got a bit of code like this:

<? 

if (file_exists($f)) {

    output_header();

    include($f);

    output_footer();

}

else {

    header('HTTP/1.0 404 Not Found');

}

...which works, but I'd like to raise the 404 error in such a way that Apache serves my ErrorDocument. Is this possible?

Oh, and a security question: currently, this allows access outside the webserver's directories (you can use /index.php?f=/etc/passwd for example). Any good tips on avoiding this kind of problem?

<?php 

if (file_exists($f)) {

    output_header();

    include($f);

    output_footer();

}

else {

    require("YourApacheErrorDocument.html");

} 

?>

require("YourApacheErrorDocument.html");

So you're saying that there's no way I can "raise an exception" from the PHP file to cause Apache to forget everything and treat it as a 404, then?

Nope, but that will accomplish the same thing. I would guess, however, that by the time you are processing the PHP file, Apache has determined that the target file exists, and can merely send back the result from the PHP file.

I've seen some references to throwing an

exit;

right after the header() making it do the right thing, but it doesn't work on my installation, which is admittedly quite old. You might want to give it a shot. Of course, make sure that it's the first piece of data you send.

Oh, and a security question: currently, this allows access outside the webserver's directories (you can use /index.php?f=/etc/passwd for example). Any good tips on avoiding this kind of problem?


I don't get this problem, probably down to the server configuration, but I've put a simple preg in place to remove anything that isn't alphanumeric, just in case.

$f=preg_replace('/[^0-9A-Za-z]/', '', $f); 

probably down to the server configuration

Are you running your server chroot-ed? There's nothing in my configuration that'd stop the www-data user from accessing stuff outside /var/www (and it has to run like that -- some things shouldn't be in the public webspace, but ought to be accessible to the webserver user).

Four options occur to me:

1. Turn the path given into a fully-qualified path and then check that it's a child directory of the path containing the PHP script. This assumes that I want to allow the illusion of subdirectories.

2. Alternatively, I could use a regex to turn slashes into underscores, e.g. and then disallow any other directory traversal.

3. Turn the file access into another HTTP access and allow the webserver to deal with it. Not a great idea from a usage point of view.

4. Stuff the content into a database.

I think I'll probably go with option 1 for this website. I want to keep the content in CVS, rather than in a database (the database means I'll need some kind of editing screen as well, which is a pain).