kicken

If you want help, it might be wise to actually post the code, or a URL to the code which you are wondering about. As it stands, I have no f*ing idea what you are talking about, nor do I have any desire to try and find out on my own.

Not necessarily. You'd need at least one file, your main router, within the public directly in order to process the requests. All the rest of your controllers/includes could be within a private directory and PHP will still be able to access them. It's not uncommon to have controllers/views/etc in a directory above the document root directory so that they are not accessible via the web server at any url. Then you just have a single index.php file in the document root which all the requests get re-written to. That PHP file would then include() the other files as necessary to complete the request.

There's no need to do the update if the row does not exist. //create sql query to check if unit exists $sql1 = $connection->prepare("SELECT Received_Date,RMA_Status FROM rma WHERE Unit_Serial_Number = '$scanISN' AND RMA_Number = '$rmaNumber'"); //run sql query $sql1->execute(); if ($sql1->rowCount() > 0){ //create sql query $sql = $connection->prepare("UPDATE RMA SET Received_Date = '$receiveDate', RMA_Status = '$rmaStatus' WHERE Unit_Serial_Number = '$scanISN' AND RMA_Number = '$rmaNumber'"); //run sql query if (!$sql->execute()){ $output = "RMA updated failed."; } else { $output = "RMA information updated."; } } else { $output = "RMA does not exist please contact support"; }

You could defer more specific processing to the child controller if you wanted. In my example above, I have two entries for shop.php, both begin '/shop/(\d+)' with the URL match. If you wanted, you could have just a single entry in your main control matching that prefix, then inside shop.php test more specific conditions such as '/shop/(\d+)/buy/(\d+)' or '/shop/(\d+)/sell/(\d+)'

You wouldn't write a million if or switch statements, you'd consolidate all your possible paths into some kind of array (or database) and then loop through them to determine where to go. For example: $routes = array( array( 'matches' => '^/fight/(\d+)$' , 'controller' => 'combat.php' ) , array( 'matches' => '^/village/(\d+)$' , 'controller' => 'village.php' ) , array( 'matches' => '^/shop/(\d+)$' , 'controller' => 'shop.php' ) , array( 'matches' => '^/shop/(\d+)/buy/(\d+)$' , 'controller' => 'shop.php' ) ); foreach ($routes as $rt){ if (preg_match($rt['matches'], $_SERVER['REQUEST_URI'], $urlparams)){ include $rt['controller']; } } That is just a simplistic idea, you could expand on it greatly.

Do a SELECT before hand to test for the existence of the record.

I would say your best bet would probably be to switch to buttons instead of a select box. As far as I know there is not a way to recognize a click on an option element. If you want to keep the look of a select element, a little css and extra JS would let you turn separate buttons/divs into something visually resembling a select element while allowing you to capture clicks on individual "options".

Trim would only handle spaces at the beginning and end of a string. It wouldn't help with any space variations in the middle of the string. For instance if your database contained the value 1500 LA BRANCH(two spaces between words) your query would fail to match, even though it would appear as though it should when viewing the record in phpMyAdmin.

I'd guess there is a difference in the whitespace which you can't see by looking at the phpMyAdmin output since HTML collapses whitespace. Try replacing each space in the query with a % and see if it matches.

You have to check the url to determine which page they want to go to. Unless your site consists of only two pages, one for those logged in, and one for those not.

If you have a column literally named '96', you are doing something horribly wrong. In your queries 96 is going to be treated as a numeric value, not a column name. 96='blah' is false and would match no rows.

I'd just trim the value first to clear leading/trailing spaces. val = val.replace(/^\s+|\s+$/, ''); var words = val==''?0:val.split(/\s+/).length;

Change: $params = array( $param1, $param2, $param3 ); to $params = array( &$param1, &$param2, &$param3 ); And see if that works. If it still doesn't work, you may also need to change function prepare ( $conn, $query, $params ) { to function prepare ( $conn, $query, &$params ) {

You're missing semi-colons at the end of the lines there.

You should pass the connection in as a parameter. function test($dbcon /*, other args */){ //... } test($dbcon);

Open your connection at the beginning of the request. Don't close it yourself, let PHP handle closing it at script end. That is the basic rule when it comes to managing a database connection.

Your index.php would be in charge of deciding which other files to includes/run. It would not handle any of the requests directly (except maybe an error request, ie 404). Also none of your links actually include the index.php filename in them. The request gets re-routed to index.php via a behind-the-scenes mechanism such as mod_rewrite. So what happens is the user enters the url (or click a link going to): http://example.com/blog/2013/12/1/192-a-simple-blog. mod_rewrite would then take this request, and rewrite it so that rather than the server trying to serve the file blog/2013/12/1/192-a-simple-blog it will instead serve up index.php. Inside index.php you would have the code examine the $_SERVER['REQUEST_URI'] variable which would contain the url the user tried to access (ie /blog/2013/12/1/192-a-simple-blog) and based on that URL determine how to handle the request. For example, the above might be matched by a regex such as: $blog_request = '^/blog/\d+/\d+/\d+/(\d+)-.*$'; if (preg_match($blog_request, $_SERVER['REQUEST_URI'], $urlparams)){ //This is a blog request, include the blog handler include './controllers/blog.php'; } Inside ./controllers/blog.php, we'd handle the retrival and display of the blog entry: $blogid = $urlparams[1]; $res = $db->query('select title, content from blogs where blogid='.intval($blogid)); //... $template->render('./views/blog.tpl'); As for why you'd want to do this rather than just have different files, there are a few reasons:1) It generally results in cleaner URLs since the URLs do not have to map to a real file. Instead they map to a concept/data object 2) index.php makes a convinent place to setup any necessary resources such as the database connection, session details, etc 3) It helps keep the backend files organized without having to worry about how their layout will affect URL structure

Generally you open the connection in some common include file which is used on all pages. Based on your file names, I am going to assume that required-all-pages.php fits that description so that is where you would open your database connection. As for closing it, you don't. Let PHP handle that at the end of your script. With a simple include setup like that, variables will be available across includes so if you simply do: $dbcon = new mysqli(...); inside of the required-all-pages.php file, then in all your other files you can query the database by just accessing $dbcon.

If your table is rejecting duplicates, it is because you defined that column as UNIQUE when you created it. All you need to do is remove that unique constraint and then duplicates will be allowed.

You should try and change your code so that you are only calling mysql_connect (or mysqli_connect) once. Calling it multiple times (with the same info) is unnecessary, though PHP should just return the existing connection rather than open a new one so it shouldn't be causing your issue. Yes, for the simple fact that mysql_* functions are deprecated and slated to be removed: PDO or Mysqli are the current recommended connection methods. Another thing to consider: if you are on a shared host, your issue may not have anything to do with your scripts. There could be scripts for one of their other customers that is eating up all the available connections, leaving your scripts (and others) unable to connect. This is something your host would have to investigate and correct, you would not have the capability.

The PHP Freelancing section would be the most appropriate.

Just add that condition to your WHERE clause. WHERE mpo.asin1 IS NOT NULL

I handle them by throwing an exception which is then caught at the top level and results in a generic error page being displayed. Eg, I have a router page something like: try { include($thePage); } catch (Exception $e){ ShowErrorPage($e); } The ShowErrorPage function just loads up a error template file displays it. I have a constant set in the app config file to determine whether error details are displayed. If it is true then the exception details and stack trace are displayed on the page, if false they are not. In either case, the error details are also logged to a file.

extract($_REQUEST); Would probably have the same overall effect. You should however have your developer update the code to no longer need either of these.

11.6. Data Type Storage Requirements Emphasis added As for what is stored in the row buffer (the 9-12 bytes) I do not know exactly, but it likely is some value used to reference where the real value is stored at.