Leaderboard

you still have not provided any context (meaning) of this data. name-numbered, labels and variables, are meaningless to us. if the mix of rows shown in the example picture is valid, i.e. you can have have any number of rows from each html table section, you should (probably) store the data from each row in each html table as a separate row in the detail database table, with an item_id column to indicate the meaning of each row of data. i have a recommendation for the dynamically added markup. don't write out the markup in the javascript yourself, where you have to keep it updated to match any changes or corrections (you are going to need to eliminate the use of duplicate ids) you make to the markup being output on the page. instead, define/store the output being output on the page in a php variable, so that you can echo it on the page and echo it as the markup inside the javascript. if you use back-ticks (template literals) around what you echo in the javascript, you can use the exact same markup in both cases. see this link - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

here's a separate list of points for the posted code - use 'require' for things your code must have. include_once, require_once, require are not functions. the () around the path/filename don't do anything and should be removed. every redirect needs and exit/die statement to stop php code execution. the current login check code still allows the rest of the code on the page to run. your form processing code and form need to be on the same page. this simplifies all the code, provides a better User eXperience (UX), and allows you to repopulate the form fields with any existing data so that the user doesn't need to keep reentering values over and over upon an error. this will also let you easily edit existing data when you get to that point. if db.php creates a database connection, why are you also creating a database connection in-line in the code? modern php (8+) uses exceptions for database statement errors by default. with exceptions, there's no need for discrete logic to test if a statement worked or failed and any existing discrete logic should be removed. you should be using prepared queries to prevent any sql special characters from being able to break the sql query syntax, which is how sql injection is accomplished. this will also greatly simplify the sql query syntax. if it seems that the mysqli extension is overly complicated, especially when dealing with prepared queries, it is. this would be a good time to switch to the much simpler and better designed PDO extension. do not query to get the current max() value for a column and use it. this is not concurrent safe. you need to the 'last insert id' function/method/property to get the autoincrement id from the first insert query. do not use any calculated total submitted from the browser. the submitted data can be altered and cannot be trusted. perform any such calculation on the server using data that is on the server. the redirect you perform upon successful completion of the post method form processing code needs to be the exact same URL of the current page to cause a get request for that page. this will prevent the browser from trying to resubmit the form data should that page get browsed back to or reloaded. you need to validate the resulting web pages at validator.w3.org ids in the markup must be unique. you should NOT include the id attributes in the addRow markup. if you are not using the id attributes, simply leave them out of all the code. the <label></label> tags are incomplete and not associated with the corresponding form field. the simplest way of correcting this is to put the closing </label> tag after the form field the label corresponds to.

your dynamic addRow javascript only adds a row to the current html table, but the form processing code assumes that all the array form fields have the same number of elements. since your example, using name-number elements, provides no context upon which to help you, you need to decide if you should change the form to dynamically add a row to every html table at the same time or if your form processing code should handle the data from each html table separately, possibly even storing related data in separate database tables. if you care to provide some real world context to this data, we would be better able to help.

Services Offered has been a place for people to offer their services for hire. Over time, it's "evolved" to support companies to announce themselves as well (provided their services are on-topic), and today it primarily functions as a pseudo-sanctioned forum for spam. There's a slight moderation burden in monitoring it for off-topic spam and removing replies (which are against rules but the forum software isn't able to enforce this adequately). Job Offerings has been the other side of the coin, where people and companies could post about jobs they have available. It doesn't see much activity these days - 5 threads in the last two years. Given that Services Offered is more of a burden than a benefit and that Job Offerings isn't much of an offering anymore, we're looking to close them down within the next week or so. Thoughts?

One of my co-workers swears by regex101, and it's very good - I think I just met regexr.com first and got used to it. Highly recommend checking out both.

It can be solved by hosting provider. You can contact then to ask about MySQL and firewall problems.

If you joined the discord and had an issue getting access to the channels, PM me here, or any of Zane, requinix or myself in Discord and we can get your status fixed.

in the mysql documentation, where the year() and curdate() functions can be found, there's a date_format() function that has a way of doing what you are asking - https://dev.mysql.com/doc/refman/8.4/en/date-and-time-functions.html#function_date-format didn't everyone learn from the y2k problem not to store years as 2 digits?

That procedure is wacky. Why is it trying to make a simple INSERT be so complicated? And so prone to not working? The error is telling you, in a weird way that doesn't seem very obvious, that the value you used is not valid. Which it clearly isn't.