termidave

I've always used it heavily in MVC-style setups. With the output buffer functions you can process and render a portion of the page within its own object before a piece of the template or view has already been rendered. This can help you to set up a dynamic templating system where you can just modify the database to change page layouts. It also allows me to perform post-processing on a rendered view, such as applying attributes, styles, or converting links. There have also been times where some framework like CakePHP is just misbehaving and is throwing output like newlines when you need to modify a header sometime later in your code, in which you can call ob_clean() (without first doing an ob_start(), so it's performed on the standard output) before modifying the header to fix the problem.

To find what the next table ID should be you'd pull the tables in the information_schema, cast them to extract the ID, and add 1 to the max: SELECT MAX(CAST(TABLE_NAME AS UNSIGNED))+1 FROM information_schema.TABLES WHERE TABLE_SCHEMA='my_database_name' AND TABLE_NAME REGEXP '^[0-9]+_tablesuffix'; Using CAST() will throw truncation warnings, however. You can always pull all of the tables into your PHP code and then sort through them, but this way at least it's all done by MySQL.

You should not separate the tables out when you need to categorize, for many reasons. A simple normalization technique will be a lot cleaner and solve your problem. [*]Create a table that will hold all products (laid out like the example above). [*]Create a table that will hold all of your categories, with at least an ID field and a name field to identify the category (much better than trying to remember all of the table prefix IDs!) [*]Create a table (something like "products_categories") that will link the two together, with a product_id and a category_id That way, when you need to pull the products for a certain category ID, you can run this query: SELECT p.* FROM products p INNER JOIN products_categories pc ON pc.product_id=p.id WHERE pc.category_id=34; ...and category 34 would be something like "Pet Products" which will help you identify it later.

Where did you get this "<formitem>" tag from? Is it in your doctype? My guess is that Internet Explorer recognizes it as a node if it's getting to the alert at the end, but like usual, it's failing silently because it can't handle a "<formitem>" tag. If you replaced formitem with something standard, like a div, I bet it will work in IE which would confirm that IE can't handle the nonstandard tag.

There are two security issues I see right off the bat. The first one is that you're embedding variables directly into the SQL string. You should instead prepare the statement, bind the variables, and then execute the statement. This will protect you from the dreaded SQL injection. Check out the examples here: http://www.php.net/manual/en/mysqli.prepare.php. If you're feeling lazy, you can at least run the fields through mysql_real_escape_string() before embedding it: $fullname = mysql_real_escape_string($fullname); $photo = mysql_real_escape_string($photo); $sql = "INSERT INTO members(fullname,photo) VALUES('$fullname', '$photo'); The second is that you are not filtering the uploaded file. A user could upload a PHP file to your server, go directly to it, and take over your site. Validate the mimetype of the file, and since it is a photo, you can throw it through some image processing functions before moving it to its final directory. Here are some great examples: http://www.php.net/manual/en/features.file-upload.php You can check to see if a file already exists by using file_exists()