Jump to content

mac_gyver

Staff Alumni
  • Content Count

    4,527
  • Joined

  • Days Won

    123

mac_gyver last won the day on February 22

mac_gyver had the most liked content!

Community Reputation

490 Excellent

About mac_gyver

  • Rank
    Staff Alumni

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

148,785 profile views
  1. don't actually move any data between tables. in fact, once 'live' data is inserted into a table, it is almost never actually deleted. all you need to do is record and use a 'status' value. you should have a user table that holds the unique, one-time, user information. the auto-increment integer id column in this table establishes a user_id that you would use to relate any other user data, such as the user's status, back to the user it belongs to. you would have a status table that defines the different status values (id and name columns.) the auto-increment integer id column in this table
  2. check is a reserved work and should not be used as a column name. either use a different name for that column or you must enclose the column name in back-ticks to cause it to be treated as an identifier.
  3. $this (programming pun intended) is the correct syntax, but produced a different error than the one you posted about the undefined variable. what was the error message in $this case? i'm going to guess that the database connection probably failed and there's no useful error handling in the code. while not the cause of the most immediate problem, your main code should be responsible for creating the database connection, then use dependency injection to supply that to any class that needs it. by making each class responsible for getting a specific database connection, your code is not ge
  4. odd syntax errors are often caused by copy/pasting code from web pages where it has been 'published' and 'beautified'. it contains non-ascii characters that when treated in a php code context breaks the php code. the solution is to delete and re-type the line of code. there should be no quotes in the print_r() output around the associative array index names (just tested.) there's something going in your form field name attributes. what is the code/markup for your form fields?
  5. you also have a reply in your previous thread pointing out an issue with using both bindParam() and supplying an array to the ->execute(...) call -
  6. don't use variable-variables, ever. they are not needed, ever, and for the posted code, those bindParam() statements aren't doing anything. you are overriding them by supplying an array to the ->execute(...) call. using bindParam/bindValue and supplying an array of value to the ->execute(...) call are mutually exclusive methods of supplying values to the query. you should simply supply an array of values to the ->execute(...) call. i was hoping that getting working php/pdo errors would point to a problem i saw in the code. you are hard-coding the table name (Sites) in the $sql qu
  7. you have to find what's causing a problem in order to fix it, otherwise you are just putting Band-Aids on top of symptoms, and the real problem remains. there are significant problems in the posted code - no comments to let anyone know what the intent of any section is, variables created for nothing, inconstant/no error handling, putting external data directly into sql query statements, running queries inside of loops... you will only see a http 500 error page in a browser due to a 'primary' request to a page, not an ajax request. if you are seeing a http 500 error page, it's for the acti
  8. the code handling that from submission isn't even part of the posted code, though it should be - the form should submit to the same page it is on, so the most immediate problem is in some different code. you need to find the php.ini that php is using and set error_reporting to E_ALL and set display_errors to ON, so that php will report and display all the errors it detects. stop and start your web server to insure that any changes made to the php.ini will take effect and then use a phpinfo(); statement in a .php script file to check that those settings actually got set to those values.
  9. that's not what I stated/asked about php's error related settings. you are setting the pdo error mode to exceptions (twice.) what this does is cause an error with a prepare(), query(), exec(), execute(), ... statement to throw an exception. if you don't catch the exception in your code, php will catch it. if php's error related settings are not set up to report and display (or log) all php errors, nothing will happen with this information. your script will just halt at the point of the error. as to the try/catch block you do have for the connection. a connection error is a fatal prob
  10. you are most likely getting an error from the ->prepare() call. do you have php's error_reporting set to E_ALL and display_errors set to ON, preferably in the php.ini on your system, so that php will help you by reporting and displaying all the errors it detects?
  11. what symptom or error did you see that leads you to believe that?
  12. regardless of what you do to pre-check the username, from the point in time when you pre-check if the username is available, to the point where the user actually submits the form, someone else could have submitted the same username and it is no longer available. your database table must enforce uniqueness, by defining the relevant column(s) to be unique indexes. you must then have error checking for the INSERT query to detect if a duplicate was attempted to be inserted, and report back to the user if the username already exists.
  13. there's no reason for the php code to even be making a database connection, unless it was testing if the database server is running and the connection credentials are valid, which it isn't doing.
  14. just about everything in this code is working against you finding out what the code is actually doing. put the php error related settings into the php.ini on your system. if for some reason you can only (temporarily) put them into your code, put them before all other php statements and put them into both of the relevant files. you are likely having an error at the session_start() statements... don't use output buffering unless you want to specifically buffer output. by always using output buffering, you don't know if the lack of php errors or other indications from your code, is du
  15. php is a server-side scripting language. if you are not making a http(s) request to a web server for the .php file, the php language engine isn't being invoked. when you directly enter the URL of the .php file in question in your browser's address bar, do you get the expected output?
×
×
  • 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.