mac_gyver

it sounds like the session data files are being read and locked. the permission issue isn't due to the permission settings, but that some other instance/process is reading the file at the same time. this would be either due to session garbage collection (you can temporarily configure it to not run as a test or perhaps it is configured to run on each session start?), some code that's reading/scanning the session data files (do you have some code that's trying to read and manage the session data, such as logging users out after a time?) , or multiple concurrent instances of your script accessing the same session data (this can occur when ajax requests are used.) as to why this worked before and has now changed, I don't have any suggestions. it would take knowing everything your code is capable of doing, session related, uploaded file related, ... are there currently a bunch of unusual requests being made to the site or just your requests for troubleshooting this problem?

while this isn't the cause of the session data file open/permission error, it indicates there's something going on on the server. i'm going to guess something like the allocated disk space is full, causing the FTP service error and the session data file error. searching for - 'php session Permission denied (13)' gives a number of results, most of them having to do with the actual permissions. you haven't answered @requinix's question about - What's the hosting setup? If this is shared web hosting, you would typically have a session data folder within your account's directory tree for 'your' session data files. the 2nd warning message about headers already sent has nothing to due with the problem. this warning is due to the 1st warning message being output. once the problem with the session data file open()/permissions is solved, both of these errors messages will go away.

there are migration appendices in the php documentation that list the removed and backward incompatible changes in each php version. the mysql_ database extension was removed, so, that code won't run at all and will need to be updated. if your code is organized so that the database specific code is grouped together and located before the start of the html document on any page, updating the database 'layer' would be straightforward. you just need to produce the same query result that the rest of the code needs. if your code is not organized like this, doing so will make it easier to test and debug the database code. if you do update any of the database specific code, forget about the mysqli extension. it is overly complicated and inconsistent when dealing with non-prepared and prepared queries, requiring you to essentially learn two different sets of statements. instead, learn and use the much simpler and better designed PDO extension. instead of putting dynamic values directly into sql query statements, you should use prepared queries. if code is currently using any ...escape_string() or addslashes() functions, these are removed. converting an old query to a prepared one is straightforward - remove, and keep for later, any php variables that are inside the sql query statement. note: any wild-card characters in a LIKE comparison are supplied as part of the data value remove any quotes or {} around the value and any concatenation dots/extra quotes that were used to get the php variable into the sql query statement put a simple ? prepared query place-holder into the sql query statement for each value call the PDO prepare() method for the sql query statement call the PDOStatement execute() method with an array of the variables you removed in step #1 for a query that returns a result set, fetch the data from the query. see the fetch() method when fetching a single row of data. the fetchAll() method when fetching all the rows of data at once. and occasionally the fetchColum() method when fetching a single column from a single row of data. forget about any num_rows method or property. just fetch then test if/how many rows of data there are. php8+ uses exceptions by default for database statements that can fail - connection, query, exec, prepare, and execute. when using exceptions no discrete error checking logic will get executed upon an error and should be removed. your main code will only see error-free execution. if execution continues past a statement that can throw an exception, you know there was no error, without needing any program logic. the only database exceptions you should catch and handle in your code are for user recoverable errors, such as when inserting/updating duplicate user submitted data. the exception catch block would test for a duplicate index error number and setup a message for the user letting them know what was wrong with the data that they submitted. for all other error numbers, just rethrow the exception and let php handle it and for all other type of queries do nothing in your code and let php catch and handle any database exception, where php will use its error related settings to control what happens with the actual error information, via an uncaught exception error (database errors will get displayed or logged the same as php errors.) two other major things that old code likely used that have been removed are register_globals and magic_quotes. for register_globals, you will need to use the correct super-global variable that data is in - $_POST, $_FILES, $_GET, $_COOKIE, and $_SESSION. for magic_quotes, any conditional logic testing for them and applying stripslashes() can be removed. old code found on the web is also filled with unnecessary things, such as trying to strip tags from data, copying variables to other variables for nothing, and missed out on applying htmlentities() to dynamic values being output in a html context, right before outputting it. if you want to post examples of your existing code, i/we can show what it would look like using current practices.

as already stated -

the attached code doesn't produce a php syntax error. there are only 270 lines. any chance you made a change and didn't save the file before trying to execute it? btw - addslashes() should never have been used with database code.

no matter how large you set the max_post_size setting, someone can upload a file that is larger. the size of the file someone tries to upload is out of your control. your code must test for this condition and handle it. also, by increasing the setting beyond a reasonable size, it will allow hackers to flood your server with huge uploaded files, consuming all the available processing and memory on the server, allowing a denial of service (DoS) attack.

when the size of the post method form data exceeds the post_max_size setting, both the $_POST and $_FILES arrays will be empty, because the web server discards the form data before causing your php script to be executed. your code trying to test $_POST or $_FILES will fail because there is nothing to test. after you have detected if a post method form has been submitted, assuming there's at least one correctly coded post or file field (and uploads are enabled on the server), your code should test if both $_POST and $_FILES are empty, and setup a message for the user letting them know that the form data was too large and was not processed.

you could get a count (.length property) of the number of tr elements in the tbody

the most immediate problem is you are mixing a normal get request for a page, for a Create operation, with an ajax request for existing data, for an Update operation. the number of form fields being displayed is determined by the query for the machinemaster/customerassign data. when you are Updating existing data, the number of form fields must match the existing data. you also have a secondary problem related to this in that if there is a validation error for the submitted form data, which can include dynamically added fields for the Create operation, you need to repopulate the correct number of form fields with the submitted form data, not the initial data. so, two things - don't use ajax for this, and organize the code for the page in this general order - initialization post method form processing get method business logic - get/produce data needed to display the page html document you would put the code to query for the initial data, either for the machinemaster/customerassign data (Create operation) or the customerdata data (Update operation) in item #3 on this list, and only execute it if the form has never been submitted. the way to accomplish this logic is to use a php array variable to hold a trimmed working copy of the form data. you would assign this variable a trimmed copy of the $_POST data inside the post method form processing code, then use elements in this array variable throughout the rest of the code. for the item #3 code, if this php array variable is empty (assumes there is at least one correctly coded field in the form), you would query to get the initial data and fetch it into this array variable, that then gets used throughout the rest of the code.

do you have a specific question, problem, or error, related to a small part of the 2809 lines of posted code? next, OOP is not about wrapping your main code in a class and adding $var-> in front of everything to make it work. all that did is exchange one defining and calling syntax for a more verbose one that didn't make it easier to create an application. you should have instead created a general-purpose validation class, a general-purpose sql query class, and a general-purpose form class, then define the expected fields, their labels/names, data types, validation rules, sql query rules, and form field rules in an array, then use this definition to control what the general-purpose code does. adding, changing, or deleting a form field, its validation, and its processing should just require adding, changing, or deleting a line in the defining array. btw - for file uploads, there are upload errors that result in a non-empty ['name'] element. you must test the ['error'] element to determine if a file uploaded without any error.

all the split() statements that your search/replace change to preg_split() can simply use explode() there's was an existing preg_split() in the code that your search/replace changed to preg_preg_split() that needs to be changed back to just preg_split()

your current symptom of not rechecking the radio fields is either because you changed the way you are saving the answers to the session variable (there would be php errors), and you didn't close all the instances of your browser to clear the session data and start over, or the session start is failing (there would be php errors.) do you have php's error_reporting set to E_ALL (it should always be set to this value) and display_errors set to ON, so that php will help you by reporting and displaying all the errors it detects? note: array_merge() renumbers numerical array indexes (your last code 'worked' for me but moved the checked entries to the next radio button due to the re-indexing.) you need to do what the 1st posted code was doing, and save them based on the page number, but you also need to reference the correct page of answers when you are rechecking the radio fields.

one of the great points of using exceptions for errors is that your main code will only 'see' error free execution. no discrete error checking logic will ever get executed upon an error and should be removed, simplifying the code. php's error_reporting should always be set to E_ALL. temporarily set display_errors to ON so that php will display all the reported errors, which will now include any uncaught database exceptions.

the default setting now in php8+ is to use exceptions for errors for both the mysqli and PDO extensions. assuming you haven't turned this off or caught the mysqli exception yourself, but aren't handling it correctly, a database connection or query error wouldn't allow the code to finish. it would halt at the point of the database error. so, it's more likely that a query just isn't matching any data or is being skipped over. is your code testing if there is not any data from a query and outputting a message stating so? beyond this, there are just too many possible reasons your code might appear to being displaying nothing from a query. you would need to post all the code necessary to reproduce the problem, less the database connection credentials.

what symptom or error are you getting?

here's a note about AddPage(), which does the same as the <pagebreak> tag - apparently WriteHtml() adds the first page at the beginning of a new document, so the specific <pagebreak> adds a second one.

as far as i can tell, mpdf doesn't support writing-mode or text-orientation - https://mpdf.github.io/css-stylesheets/supported-css.html the only reason you have a case where the letters are vertical is because there's only horizontal space in the layout for a single letter at that point. i recommend that you just add a <br> tag between each letter using code.

what data type are startTime and endTime? just date or datetime? when someone books a single night, what are the startTime and endTime values, for example if startTime is 2024-06-27 (today where i am at), what is the endTime value? based on the answer to these questions, the most likely cause is this - while ($start_date <= $end_date) {. when start_date has a day added to it and is equal to end date, you could be counting a row of data twice. some points about the code - don't run queries inside of loops. just use a single query to get all the data that you want at once. to produce output broken into sections by some value (product id), just index/pivot the data when you fetch it using that value as the main array index. you can then simply use two nested foreach loops to loop over the data to produce the output. if you use an array for the $month1, $month2, ... variables and use an array for the $month1_total, $month2_total, ... variables, with the array index being the month number, all the switch/case logic will go away. you can simply use the $month variable to directly reference the correct entry in these arrays. i'm not sure what the '$month3_endTime' and '$month1_startTime' values are doing in the query. they are not the cause of the current problem, but they could exclude data, producing lower quantities then expected.

https://www.php.net/manual/en/function.array-merge.php

sadly, a significant portion of the programming information found on the web is poor quality, in that it lacks security, for every context, provides a poor User eXperience, is filled with unnecessary code that doesn't contribute to a goal, some of which actually helps hackers/bots, and because it lacks error handling and validation logic, my work under prefect conditions, but won't work and won't tell you why when anything goes wrong. you can examine the code examples on the web to get the gist of how you can do things, but you must insure that the code you produce works in an expected way for all possible conditions. so, well written code is secure, in every context, provides a good User eXperience, making it clear what the user can do at each step, and if they do something that didn't work, that's under their control, what they can do to correct the problem, uses simple code that's not filled with unnecessary typing and logic, and has error handling and validation logic, so that it will log problems for you (the site owner/developer) and display relevant messages for the visitor when something doesn't work. you have three threads on this forum from the end of last year related to a contact form. did any of that lead to working code? in one of my replies, i posted a list of practices, one of which was a suggested layout of code for a single page solution. did you make use of any of that information?

you haven't stated what the code does or does not do. the user interface (UI)/user experience (UX), after clicking on the Scan ID card button, shouldn't require the user to be navigating back and forth between pages. the user should be able to continue to scan id cards, with any result message being displayed on the current user interface. to do this, you would use ajax to submit the data, then display any response. you should also be using a post method request to submit the scanned student_id. whatever this function is doing, it is probably incorrect. you should only trim input data, mainly so that you can detect if it was all white-space characters, then validate the trimmed value. since this code requires a student_id input, at a minimum, you would validate that the trimmed value is not an empty string, before using it. the attendance table student_id and date columns should be defined as a composite unique index. you would then simply just attempt to insert the data. if the combination of student_id and date doesn't exist, the row will be inserted. you would setup and display a message stating that the data was inserted. if a row of matching data already exists, the query will throw an exception (you should be using exceptions for database statement errors, this is the default setting now in php8+.) in the exception catch code, you would test if the error number is for a duplicate index error. if it is, setup and display a message letting the user know that the data has already been inserted. if the error number is for anything else, which would include things like mistakes in the sql query statement, just rethrow the exception and let php handle it. i do see a possible problem, which would be producing a database error in the current code. you are not fetching the data from the SELECT query, so the INSERT query should be failing with an error (i don't know if the store_result() call prevents this), but since you will change your code to just use the INSERT query as described in the above paragraph, this potential problem will go away. your user login should store the user_id in the session variable, then query on each page request to get any other user data, such as the username, user permission. this insures that any changes made to the user data will take effect on the very next page request, without requiring the user to log out and back in again. the file upload handling in generate_id_card.php is not testing if there is any $_POST/$_FILES data before trying to use the form data. if the total size of the form data exceeds the post_max_size setting, both $_POST and $_FILES will be empty. after you test that a post method form has been submitted, you must test that there is data in $_POST/$_FILES before using it. also in generate_id_card.php (which is actually a student registration operation), you should be selecting from existing classes. you would submit the class_id, not the class name. you should have first name and last name columns, so that you can distinguish between names like Martin Ross and Ross Martin. if you store the uploaded file using the generated student_id/insert_id, as part of the filename, you will avoid the need to check for duplicate filenames, because student_id are unique. any time your code knows the student_id, you can directly find the uploaded photo using that id.

also, don't use the actual filename in the download link, as this will allow directory traversal, with the current download.php code, to be used to download any file off of the server, such as your database connection credentials. instead, use an id in the link, then in the download.php code, query to find the actual filename, if any, based on the id. it's an error if the submitted id doesn't match a row of data or if there's no defined file for that id.

for your last two errors, here are some possibilities - you copy/pasted the code from the web where it was 'published' and it doesn't contain only ascii characters. see if deleting and retyping the line(s) of code corrects the problem. because these frameworks have their own error reporting, you may only be seeing a snippet of the actual error information. assuming your code is something like - $this->setOutputCallback(...), what does using var_dump($this); show?

this checks the datatype of the variable, not what's in the variable. get, post, cookies are by definition strings, regardless of what value they hold. change this to is_numeric().

how about clicking on the testdate.php row?