Leaderboard

Highly recommend switching to a library like PHPMailer or SwiftMailer - they're both easier to use and more reliable than php's native mail function.

the most common reason for a password_hash()/password_verify() to fail is because the database column is not long enough to hold the hashed value. another common reason are programming mistakes in the form/form processing code and a lack of server-side validation that results in the hash value not actually being from the password that was submitted in the registration code, or the value being used in the login code not being what you think it is. your post method form processing code should always trim the input data, mainly so that you can detect if all white-space characters were entered, then validate all inputs before using them.

I'm pretty sure you're encountering https://github.com/mdbtools/mdbtools/issues/312. Good news is that it was fixed, bad news is that it was fixed in mdbtools 1.0.1 and Ubuntu 24.04 currently only covers through 1.0.0. There might be a third-party PPA out there that has an updated version, but I don't know where to look for one. Or you could venture down the path of building it yourself, if you wanted: grab the Ubuntu sources, patch them according to this PR, and build. Or for a workaround, I think you'll be safe as long as you're not SELECTing anything that requires 64-bits of data length - meaning a VARCHAR(16777215) is okay but a VARCHAR(16777216) is not.

telling us that something doesn't work is pointless. we are not sitting next to you and didn't see what symptom or error you got that leads you to believe something didn't work. you must tell or show us what result you got and what the expected result should be. 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? have you checked in the browser's developer tools, console tab for errors? you should use 'require' for things your code must have. require/include are not functions. the () around the path/filename do nothing and should be removed. $_GET['email'] is an input to your code. it may not exist. you need to use isset() to prevent errors when it doesn't exist and you must trim, then validate it before using it, when it does exist. the two session variables are also inputs to your code. they may not exist. you need to use isset() to prevent errors when they don't exist.

The first thing I notice is that you have 2 session_start commands. I'm not sure that is the problem but remove the one in header.php.

If the only reason for that value is to write to the DB then you can do it in the insert query... INSERT INTO tablename (colx, coly, colz) VALUES (?, ?, NOW() + INTERVAL 10 MINUTE)

You're assigning $addingTenMinutes but then using $addingFiveMinutes, which doesn't exist. Also, strtotime('now() + 10 minute') is not a valid syntax for strtotime. Here is a corrected version: $addingTenMinutes = strtotime('+10 minutes'); $end_time = date('Y-m-d H:i:s', $addingTenMinutes);

sending a session variable from one page to another involves - having a working, error free, session_start() statement on both pages; have a server properly setup with a folder to hold the session data files; have the session cookie parameters setup so that they match the url for both pages; assign a value to a session variable on one page, that you are sure isn't getting cleared after you have set it, and test for and use the session variable on the second page. except for very overt symptoms, there is not a 'one symptom' is always caused by 'one thing' relationship in programming. if you are expecting someone here to be able to directly tell you what the cause of this problem is, you are mistaken. there are too many possibilities. when something in programming doesn't work, you must find where your code and data are doing what you expect and where they are not. the problem lies between those two points. if all you have done is run your code and notice that the output doesn't exist, you haven't narrowed down the problem. the first step in narrowing down a programming problem is finding any errors that the language is reporting. to do this, you must setup the error related settings and verify that they are actually the values that you have set them to. in your last thread, you would have been getting a fatal run-time error to alert you to one of the problems in the code, but you didn't indicate you were getting any errors. this means that php's error related settings (error_reporting, display_errors, and log_errors) are not setup so that php will help you. once you have set the error settings as i stated, and comment out the redirect, this will narrow down the possibilities, by either producing a error pointing to a problem or if doesn't produce an error this points to where to look at next.

you should do this directly in the sql query statement. MySql has a large number of datetime functions. what is the format of the 'date' column in the database table? if you do this in the php code, you must either compare objects with objects or compare formatted strings with formatted strings, with the same exact format, in a left-right order from most significant field (year) to least significant field (day.) the current php code produces a fatal error at the date_diff() method call, because the 2nd argument must be an object, not the $data["date"] string. $date is a datetime object, you cannot directly compare it with the $data["date"] string. you either must use the datetime ->format() method to produce a formatted string from the $date object, or you must create a datetime object from the $data["date"] string. $diff in a dateinterval object. to get the number of days, you would need to use the dateinterval ->format() method with the '%a' format specifier to produce the whole number of days.