views:

58

answers:

4

I am creating a website for products. I am wondering: is it better to use a single dynamic page using PHP, or generate an HTML page for every product, updating the pages from a php template file in a cron job? Most of the material on the page (eg. basic product information) will not change over time , but other parts of the page will be generated from database lookups (inventory, reviews, etc.)

I have heard some people arguing that it is better to have static url's (eg. category/product1.html) instead of dynamic ones (eg. products.php?id=1234) for SEO purposes. The problem I found with the former method is that it seems inconvenient to do database lookups from an HTML page. The way I implemented it was using javascript->php:

<script type="text/javascript" src="http://localhost/inv_lookup.php?UPC=&lt;?php echo $UPC; ?>"></script>

But then in the PHP file, you have to print javascript-formatted text:

    echo "document.write(\"" . $field . " : <b>" . $row[$i] . "</b> <br/> \")"; 

This kind of DB lookup seems sloppy to me. Any suggestions?

A: 

There's no reason you can't do it as a single .php file. With the appropriate mod_rewrite rules, you can dynamically remap a example.com/products/1234 into example.com/product.php?id=1234 URL internally.

And if you really hate exposing PHP, you can always configure the web server to treat .html files as PHP scripts (AddHandler php5-script .html).

As for printing "javascript-formatted text", it's easier to use JSON to do "formatting" for you:

<?php
    $product = array('name' => 'Deluxe Widget', 'id' => 1234);
?>
<script type="text/javascript">
    var product = <?php echo json_encode($product) ?>;
    document.write(product.name + ': <b>' + product.id + '</b><br />');
</script>
Marc B
A: 

1) Don't update static html pages with cron and php. thats just crazy talk.

2) Use heredoc syntax if you want cleaner variable interpolation:

echo <<<EOF
  this is a {$row['0']} and a "$varable" for  you. oh yeah don't forget the '
EOF;
Byron Whitlock
Well, creating more or less static pages / parts is a must for very large websites (those who even have seperate datacenters for continents / countries, think for instance a product catalogue with hundreds of thousands of products for a major electronics firm), doing it with a cron is indeed very silly. Updates should just be pushed to the servers.
Wrikken
A: 

Suggestions:

  1. Indeed storing & serving a page as plain HTML is very resource effective.
  2. Ideally, there should be no part in the URL showing any language or implementation (no .asp, no .php, no .cgi, no .html). That way, you can switch at will, and every part of your URL is to the point for the resource you are viewing. Look into apache's mod_rewrite and the like.
  3. As you noticed, some parts are more volatile then others, so storing content 'parts' (main navigation, product description, reviews) etc. separately is advisable.
  4. Cron jobs are most likely not going to cut it. When someone alters a price in the backend, the frontend should show that as soon as possible. Creating hooks to invalidate / recreate content on change are going to make your life a lot easier.
  5. Most likely you still want some barebone php script on the frontend, which concatenates are your separate caches, and is possibly able to create an html portion on the fly when a cache isn't available.

As a final suggestion: I'd peek at what major frameworks, CMS's & eCommerce solutions implement as a cache, there are a lot of errors you can make, and most are already solved.

Wrikken
A: 

I have 3 points to make on this question...

Point 1

Rather than having to emit javascript from inv_lookup.php, it might be cleaner to emit HTML and then load it dynamically using AJAX. This is literally a few lines of code w/ jQuery:

<script type="text/javascript">
jQuery(document).ready(function() {
    jQuery('#inventory').load('./inv_lookup.php?UPC=[upc_goes_here]');
});
</script>

<div id="inventory">Please wait...</div>

Point 2

Unless you have a huge amount of traffic, or have a really slow database, you could probably get away with generating your pages completely in PHP. I personally use ASP.Net and SQL Server which is supposed to be slower, and have built plenty of sites that are completely dynamic.

Point 3

Marc B mentions using mod_rewrite to handle SEO friendly URLs. If you have the time, that is the Cadillac method of making your site SEO friendly. With that said, if you are only going to be using it to move the "Product Id" from the query string to the file path, you are not going to gain much in terms of SEO. My preferred technique is to have a dynamic/bare-bones HTML sitemap with links to all of your products. If you have too many products to fit on a page, you could have a hierarchy of sitemaps. For example:

  • Top Level Site Map
    • Product Category 1 (link)
    • ProductCategory 2 (link)
    • Product Category 3 (link)
  • Product Category 1 Site Map
    • Product 1 A (link)
    • Product 1 B (link)
  • Product Category 2 Site Map
    • Product 2 A (link)
    • Product 2 B (link)

etc

Add a link from the footer of your home page to the sitemap. Google and others will easily be able to parse these sitemaps and recognize that your content is varying by a query string parameter.

If you have extra time, you are better off coming up with content for your "title" and "meta description" tags.

dana