Leaderboard

the error you are getting is a follow-on error, due to code being executed when a 'required' input is not present. if you have a section of code that requires a logged in user, your code should test if the session variable isset() before ever executing that code. this will stop the follow-on error. the actual problem is a session variable that should be set but isn't. in the first post and your post above, you have stated/implied that the SELECT query in the first post is being executed/working. how do you know it's working. what code is using the result from that query and what result or output are you getting that leads you to believe that particular query/section of code is working? taken by itself, a symptom of code that seems to work and also produces an error is usually a sign that the code is being executed twice, once with and once without the expected input data. next, there's a bunch of issues with the rest of the code you have posted - you should have an auto-loader to load the class definitions. also, 'require' isn't a function and the () around the filenames are not needed. the responsibility and most of the code in model.php is not needed. if you want to do something useful for a database class, extend the PDO class with a general-purpose prepared/non-prepared query method that accepts a second optional array of input parameters and prepares/executes the query if there are input parameters and just calls the PDO query() method if there are no input parameters. your main code should be responsible for making a database connection, since it knows if, how many, and where those connections should be used, then use dependency injection to supply the connection to any class that needs it. you should not use defined constants for the database connection credentials. this limits the code to using only a single database connection. you should use exceptions for database statement errors and in most cases let php catch and handle the exception, where php will its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) the exception to this rule is when inserting/updating user submitted data and a duplicate or out of range error can occur. in this case, your code should catch the exception, test if the error number is for something that your code is designed to handle, setup and display a message for the user telling them what was wrong with the data that they submitted. for all other error numbers, just re-throw the exception and let php handle it. you should set emulated prepared queries to false, you want to run real prepared queries, and set the default fetch most to assoc, so that you don't need to specify it in each fetch statement. by having a 'query' method that is actually preparing the query, you have created confusion and more work for anyone who will have to read/maintain this code. if you simply supply an array of the input data to the execute([...]) call, you don't need any of the code for binding inputs. also, by using bindValue(), you cannot directly execute the same query again with different data and is_int() in that code isn't doing anything for integer values that are in a string variable type. the verify() method also has responsibility and code issues. just some of them - the only user data you should store in the login session variable is the user id (auto-increment primary index.) you should query on each page request to get any other user related data/permissions. this is so that any change in the user data/permissions will take effect on the very next page request, without requiring the user to log in again. also, all header() redirects need an exit/die statement after them to stop code execution.

I think fetch returns false only on failure. A query can be successful but return no rows. You might want to check to that condition.

What does 'single' do and return?

I don't see where that variable is set anywhere.

Not enough information. Where and how was the session variable set? Is there a session_start call at the beginning of this script? There may be other issues, unrelated, with your query as well. You are not using prepared statements which may be OK as long as ':id' is not coming from a web page. Also it is bad practice to use * in a query. Specify only those columns you intend to actually use.