Jump to content

PFMaBiSmAd

Staff Alumni
  • Posts

    16,734
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by PFMaBiSmAd

  1. Are you sure that you are the only one making page requests? Any publicly accessible site is open to abuse. Perhaps some hacker is trying trying to break into your database or break into your script(s). The number of available database connections is (usually) managed on a per hosting account basis, so if you are getting that error, it (should) mean that it is due to your script(s). Have you actually asked your web host to provide information that they know about concerning when that error has been occuring, like how many connections are available and how many your account has been using? Beyond that, are you including any code using a URL (instead of using a file system path) to your own site that is also making a database connection in each piece of code, such as piecing together a web page by including various sections (menu, header, content, footer,...)?
  2. Unfortunately Unix Timestamps are the worst way of storing data that you need to manipulate using human calendar units (days, weeks, months, years) because you must perform a (relatively slow) conversion on all the data to get it into a format where you can perform the needed manipulation. If you use the mysql FROM_UNIXTIME(unix_timestamp,format) function in your query to convert and select the date in the format you want, you can then detect in your php code when the date changes and output a new date heading followed by the values under each date.
  3. mysqli_error requires that mysql-link as a parameter - mysqli_error($myConnection)
  4. Edit to the above: you can also order by the type using - ORDER BY FIELD(type,'sex', 'month', 'day', 'year') to get the fields in the result set to be in the order that you want them for the form. This would actually result in the simplest php code because you can simply iterate over all the rows and detect the change in the type to close out the previous form section and start the next section.
  5. You should not even have a table that is laid out like a spreadsheet where you have different columns for each field type with null values in the unused choices. What happens when you need to add more form field types to the design? You need to alter your table and you need to alter all your queries that reference that table because there are now more column names to reference. You should have one row for each possible form field, with a type column (sex, month, day, year) and a value column. The query would just be - SELECT * FROM tblFormFields ORDER BY type, value If you don't want to output the fields in the actual form in the order that ordering by the type (asc or desc) would result in, you can either add an `order` field to the table so that you can attach a specific ordering to the fields or you can do this in your php code by processing the rows in the result set and store them in an array with the type as the key, then iterate over that array in the order that you want the form fields to be in the actual form.
  6. display_product.php?=x (the links on your live page) is not the same as display_product.php?id=x (the correct links that your current code would produce and which would be needed to cause $_GET['id'] to exist.)
  7. Umm. The link to the live site you posted is still contains URL's like - display_product.php?=5 That's not correct. Has that live site been updated with your current code?
  8. If the URL contains an ?id=xx value, but your php code is not receiving it, either something is preventing the value from reaching your script or something is overwriting it. What does the following code show, when added immediately after the first <?php tag in display_product.php - echo "<pre>"; echo "GET:"; print_r($_GET); echo "</pre>"; Beyond doing the above to see what the $_GET array contains, it would take seeing all your code and any included/required files on the display_product.php page to be able to help you.
  9. When you click on one of the links, does the browser's address bar show an expected value for the display_product.php?id=??? The error you mentioned "when I enter the "WHERE id=$id"; I get errors on line 16" is because the $id variable is empty in the query. Is the code you posted all the code between where you are setting $id = $_GET['id'] and where you are using $id in the query?
  10. Actually, if I remember correctly, some spammer started this by bumping the thread earlier today to post a link and who's post has since been deleted from the thread.
  11. If your session_start() statement did not produce an error message (like the error in the first post in this thread) when you echoed something before it, then either the error_reporting/display_errors or the output_buffering settings are not actually what are being shown (php has had a history of displaying settings that it is not actually using.) In the same code, try to cause php errors. Add something like the following to see if you get any error messages - echo $i_dont_exist;
  12. The OP was last active 30 minutes (probably the forum's on-line timeout value) after starting the thread, 8 days ago. Given that someone with English as a second language would have likely used a spell checker and wouldn't have gone to the trouble to write more than a basic straight text post, this first post is likely just a spammer making up a vague, possible but unlikely, non-spam looking post to test if the account he just made works. A real person that went to the trouble of registering and asking a question that they were interested in getting an answer to would have checked back within a reasonable time after making a post.
  13. Here's a time saving tip - you need to have error_reporting set to E_ALL (or ever better a -1) and display_errors set to ON in your master php.ini so that php will report and display all the errors it detects. Restart your web server to get any changes made to your master php.ini to take effect and confirm that those two settings got changed in case the php.ini that you changed is not the one that php is using.
  14. Of course, because you are using the die() statement to display validation errors and your code will die on the first error that is found. To validate multiple pieces of user data, you should use an array to both hold validation error messages and to serve as a flag that errors have occurred. <?php $errors = array(); // define an array to hold errors if(some_validation_condition_is_not_met){ $errors[] = "user message you want to display for this error"; } // check if there were any validation errors - if(empty($errors)){ // no errors, use the data here... } You can loop over the $errors array to display any errors that have occurred.
  15. The section of code you just changed, for registering, doesn't originally have a $password variable in it. Did you add a $password variable (the one that is in your code is inside the login logic and doesn't exist when the registering code executes.) You also have the logic that defines the GetSQLValueString() function in your code THREE times. Delete the second two occurrences.
  16. The code you have, isn't doing what you expect. The second parameter of the md5 function isn't a salt string. It is a bool flag that determines what format the value is returned as. A 'salt' is a random string that you prepend and/or append to the actual password before you apply a hash function to it. Therefore, in php you would need to concatenate the salt string to the $_POST['password'] value.
  17. If your code works on your development system, then output_buffering must be on at some point. I.E. even if the error_reporting/display_errors are set to hide errors, the output would still be occurring and stop the session_start from working. Your error_reporting on both systems is definitely not E_ALL (or even better a -1).
  18. You are not executing your query, so your logic always reports that the username is available. You should also be developing and debugging your code on a system with error_reporting set to E_ALL (or even better a -1) and display_errors set to ON so that all the php detected errors will be reported and displayed, you will save a TON of time.
  19. You need to use the or trigger_error('Error Creating Database: ' . mysql_error()); debugging logic on all your queries. You also need to select the database you just created before you can create any tables in it or you need to specify the database name in the queries.
  20. Add the following, right after the $sql1 = '.....' statement to see if your code is even running - echo $sql1; If you don't get anything echoed, it is likely that your mysql.php code is dieing. Do you have the mysql extension installed in your php installation? Have you successfully executed any mysql_ statements in a php scirpt?
  21. What URL are you putting into your browser to request the file and what exactly do you get as output in your browser? If you get a blank page, what does a 'view source' in your browser show?
  22. Comment out the header() redirect near the end of the code.
  23. What trigger_error shows is dependent on the error_reporting/display_errors settings. Add the following two lines of code immediately after your first opening <?php tag - ini_set("display_errors", "1"); error_reporting(-1);
  24. The following is the basis for the code you are using (gotten from the php.net documentation.) You would put your application level validation logic inside the if(){...} statement, because you can only access and check the uploaded file information when the file was actually uploaded without any errors - <?php foreach ($_FILES["pictures"]["error"] as $key => $error) { if ($error == UPLOAD_ERR_OK) { $tmp_name = $_FILES["pictures"]["tmp_name"][$key]; $name = $_FILES["pictures"]["name"][$key]; move_uploaded_file($tmp_name, "data/$name"); } } ?> The code you have now makes no sense.
  25. What does adding the following three lines of code, immediately after the first opening <?php tag, show - ini_set("display_startup_errors", "1"); ini_set("display_errors", "1"); error_reporting(-1);
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.