homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

PHP - Acquiring URL
URL - the primary key to be
brotherhood of LAN

 8:46 am on Aug 1, 2002 (gmt 0)

I am toying with a PHP/mySQL setup and want to use the URL of a page as the primary key for a given table.

Ideally, page templates of PHP will be created that will be bespoke to each category......and be given a URL or "path" where the SQL statements within the PHP will be executed bespoke to that category (i.e. the content of the page).

The mechanism of the db will be dependent on the query "wondering" what page it is.....for instance..index.php

I am wondering if it is possible to gather the information of the URL without having to reference it in the SQL?

I.E. consider that I have one universal PHP template.....each new page created would require me to change the page according to the pageid to match the query.

If there was some way for the query to "read" the URL, I wouldn't have to change the template as the URL could be interpreted......where I could hopefully use it as a variable that will act as a sort of "turn key" to the PHP template....

This will be handy...because, for instance...if I had a navigation bar...it would most likely be called from the same table...and use a "path" row to describe the page URL relative to the root. If a user clicked on the link, then this "path" value would be used in the query of the next page.

I'm a PHP newbie...but basically I need a way to get the URL of a page into the SQL statement.........so that the "path" corresponding to that page can be used to query the data appropriate to that page.

Hope that is clear (enough) for some wonderful WebmasterWorld insight :) Look forward to solutions, alternatives and heads ups



 9:04 am on Aug 1, 2002 (gmt 0)

Hello BOL

I have done something similar using ASP so here are my thoughts.

I would reckon that using the URL as the PK would not be the best approach. Some URL's are massive so you you would need a large field. Why not use a table containing

URLID (PK) using SMALLINT depending on your record numbers
URL using VARCHAR(150)

So when you wish to display the detail page you have a link


Where X is the PK of the table. Then on the display page set up a variable $URLID

Then create your SQL and use the vale of X to filter the exact record.


Really cool when you get the hang of it, you can create boat loads of pages with just one template that get indexed. Top result :-)



 9:11 am on Aug 1, 2002 (gmt 0)


I'm afraid I got terribly confused reading your post. But it seems to be a touch overkill.

Have you had a look at a proper template engine? Smarty [smarty.php.net] is about the best you can get. It's very easy and save you alot of pain....


brotherhood of LAN

 9:12 am on Aug 1, 2002 (gmt 0)

Yeah top results sound good :) So I can put the variable where you mention it......sounds pretty workable....and high up on the funkability scale.

RE long URL's
Nah, hopefully not. As I say, the "path" or "URL" will be the PK. In the SQL query, the path is a relatively normal path...like widgets.com/index.php or /business/widgets/index.php or what not.

The table will have a relationship with categories which in turn will help decide what content is being displayed further down the page.

With all the above....it will just be a case of using a template, and publishing it to the corresponding URL. The "turnkey" so to speak will be the change in URL which will change the content and layout of the page bespoke to the page/category itself!

phew! PHP and mySQL.....they could put it in a pill called "headache" and I'd still get the same end results! :)


 9:31 am on Aug 1, 2002 (gmt 0)

WRT to primary keys, it was always suggeste to me that I should use and auto_incriment for my PK as they can never go wrong and you are never going to get another one the same

You will get better perfomance when looping/searching through the DB.

Look at the URL also with the paremeter appended if I understand your method correctly

URL as PK method

AUTO Num as PK

I have had a little experience with trying to convince the powers that be on a website that their biblically long URL paremeters containinquerystrings would have problems. In my experience it does. I know the shorter methods works, but I am not so sure about some loner URLS.

Just my opinion, hope you get it sorted.

Check your stick too BOL for an example where I have done this
<ADDED> you can check your STICK if you have one, but I meant your stickymail :-)


 7:25 pm on Aug 1, 2002 (gmt 0)


Sorry but I couldn't really follow the initial post but I did understand this

Ideally, page templates of PHP will be created that will be bespoke to each category......and be given a URL or "path" where the SQL statements within the PHP will be executed bespoke to that category (i.e. the content of the page).

This is exactly what I do (though I have to go look up "bespoke" everytime since we don't really use that word in American).

Anyway, use auto-increment for you PK. It's safest and easiest with MySQL. Then just have an indexed fields for path names and files names (so you can retrieve them quickly from a query).

Basically, I have categories, which have "category paths" and pages which have "page paths" None of these necessarily correspond to the physical organization of files on the disk, but rather to the logical (illogical?) structure of the site. I rewrite the URL to point to a single PHP file which takes the URL and parses it, finds out which page it wants from there, and then goes and gets the relevant include files and DB info and generates the page.

It's a little resource intensive, but it allows
- friendly urls without GET params
- a site structure that can be changed by just changing values in the DB, without changing file locations, so there's no chance that paths get broken.
- easy template branching - this file gets this template, this one gets that template, this file doesn't get a template at all, show as is.

I like it.


brotherhood of LAN

 7:37 pm on Aug 1, 2002 (gmt 0)

Hi Tom,

You hut the nail on the head on why I set out to do this. I agree my first post is a little shadily wrote out....sometimes hard to talk about a code I know nothing about/

I think its a good way to go for scalability.....and after trying to write down a db design....scaling top to bottom, seems like the URL is the only variable that is the concern outside the db, so introducing it as the primary key makes it much easier when playing around with data on the server.

Maintenance.....templates and a list of URL's :) I like it.

PHP is good for this "lowest common denominator" business....I'm really just playing around to see how "uniform" I can get a site bearing in mind all the possible variables that are played with during a visit.

Then.....content can once again be priority and king :)



 11:03 pm on Aug 1, 2002 (gmt 0)


I'm still not sure why the URL should be the primary key. In my case, the URL field is not necessary unique. Example, I could have


Since the first part of the URl is based on category (and is in a categories table), the table holding info for individual pages can sometiems duplicate. An auto-index PK means I don't have to worry about this. Of course, I don't want a given URL pointing to two different files, but that wouldn't crash anything, it would just randomize what the visitor saw :-) He or she would get the first result returned. It could create problems, but I don't think my admin interface would allow this.... er I hope


brotherhood of LAN

 11:43 pm on Aug 1, 2002 (gmt 0)

I'll be taking the sound advice and using an auto_increment primary key for that table.

The 2 main aims are
1. templates that are simple to change and update via the db
2. Easily creatable pages by simply changing the (now) ID of the page.....and publishing a new page with the relevant ID in the SQL

Hopefully, a nice clean cut layout will cut down file sizes and in general, keep things smooth.

The idea of "acquiring the URL" was that the part of the page URL past the TLD would be the same as the WHERE statement of the SQL query. It would simply mean I wouldnt have to change the template because the published file would allow the SQL to acquire the "URL" variable from the pages path....sort of thing.

Using a primary key just lengthens the process....if you see what I mean :)

Of course, if things were to be (or could be) done this way, it would mean duplicating some data in the tables involved....ie the "category" paths- but its an either/or sacrifice.

Hopefully, as well, there would not be a prob with duplicate ID's as mentioned in the above (ideal) situation :)


 4:12 am on Aug 2, 2002 (gmt 0)


You can always query on the url field, so it doesn't lengthen the process to have a numeric PK, but it does give you more flexibility.

Having the number also means that the PK of the record doesn't change if you decide to change the URL. Since MySQL doesn't respect referential integrity, this is fairly important.


table: categories
1. Widgets
2. Blodgets

table: items
Items - URL
1. blue widget - www.domain.com/widgets/blue/
2. red widget - www.domain.com/widgets/red/
3. yellow widget - www.domain.com/widgets/yellow/

table: cats-to-items
Item - Category
1 - 1
2 - 1
3 - 1

If I change the path, this table governing relations is unchanged.

In your system, this table would be
www.domain.com/widgets/blue/ - Widgets
www.domain.com/widgets/red/ - Widgets

Now if you change the path, you have to make sure that you change it in every table, since MySQL won't do any of that for you. It's simple enough, but it's simpler still to not have to worry.


brotherhood of LAN

 12:06 pm on Aug 2, 2002 (gmt 0)

> changing category

heh, never thought about me doing that....I guess I should consider that it may happen.'

Well, it seems a little more clearer what this sort of thing entails after reading around outside of here and the posts so far...thank you.

I had a scan of PHP "autoglobals" and it seems they will work for what seemingly is my ideal solution.

'PHP_SELF', or something like
$full_path = getenv("REQUEST_URI");
$root = dirname($full_path);
$page_file = basename($full_path);

Anyway, these pre-defined variables, ideally, if REQUEST_URI was the same as the "path" in any of the tables.....then ideally I could put PHP's equivalent of "REQUEST_URI=PATHID" or something to that extent.

Everytime a new file is published....it should "point to itself" in mySQL and provide the info that is relevant to that page via the db.

Sounds daft the more I think about it.....but the way I see it, I will simply have to maintain the db's and save the template under the correct filename.

1) Publish file to "wherever"
2) REQUEST_URI = wherever
3) page contents retrieved from mySQL relevant to "wherever"

PHP aside, that sounds smooth ;)

The way I see it...
a) No ?'s will appear in the URL's
b) Changes in the templates will be brought down to a minimum
c) anyone who is unfamiliar with the code filling in a form would not have to know this "magic" variable that will display the contents of the page

etc etc

Lots of potential in my mind, lack of knowledge about PHP and implementation. This sounds good, I am sure I will run into problems.....like the setup of PHP on my paying online account being different to the original settings I have installing it on my own comp.....

In regards to changing directories....I'm thinking that that wouldn't be too bad, considering I could download the (currently small) table, edit/replace it, re-upload it.

All good- I'll get to grips with PHP by the neck someday :)


 7:12 pm on Aug 2, 2002 (gmt 0)

a) No ?'s will appear in the URL's
b) Changes in the templates will be brought down to a minimum
c) anyone who is unfamiliar with the code filling in a form would not have to know this "magic" variable that will display the contents of the page

d) you stand a chance of remembering the urls to your pages.

'PHP_SELF', or something like
$full_path = getenv("REQUEST_URI");
$root = dirname($full_path);
$page_file = basename($full_path);

In essence, though what I do is a bit more complicated. I check and parse the URL to allow for the following cases:

1. The URL points to an actual valid file that is in that actual location on disk. This way I can create "secret" files that are accessble with a simple URL like

2. The URL points to a "directory" (albeit virtual dir in my virtual path, but I still want it to end up at the directory index page).

3. Invalid path - want that to go to my custom 404.


Global Options:
 top home search open messages active posts  

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved