mac_gyver

yes, but that's the message you or someone else is unconditionally echoing inside the form processing code. it means that the form processing code executed. echo "Check Required Fields";

it would be helpful if you posted exactly what output you get in this case. next, there's two immediate problems in the posted code - 1) if (isset($_POST)) { --- post is always set, so, all the form processing code runs every time it gets requested. if that code gets requested without any post data, it will list all the 'required' form fields as being missing. that line of code should be using if (!empty($_POST)) { 2. mysql_escape_string($_POST['AboutSelf']), mysql_escape_string($_POST['WhyJoined']) --- since the mysql_ extension has been removed from php, either you will be getting a fatal runtime error and execution will halt, or you are still running this on a php5 version and when it gets used under php7 it will produce a fatal runtime error and halt execution. so, two problems, the mysql_escape_string() calls must be removed, and the code must do something for all the external/unknown data to protect against sql injection. lastly, there's several implementation problems in the code, resulting in a large amount of unnecessary variables and logic, and without knowing what the database layer is doing, it is likely open to sql injection. just getting this code to 'function' my leave you with a site that will end up getting taken over and used for phishing sites, sending spam, ... code/queries must be secured against sql injection, email header injection, and cross site scripting.

from one of your previous threads on this forum - if (IS_LOGGED == false) { header("Location: " . PT_Link('login')); exit(); } or more simply - if (!IS_LOGGED) { header("Location: " . PT_Link('login')); exit(); } this of course assumes that the code producing the IS_LOGGED defined constant is consistently being used and exists before the code you have posted. a feature like controlling who can view a certain page, like the profiles, should be part of the user permission system. does this code have a general purpose user permission system in it?

here's another problem with the posted code. the $username value is being used in both an sql and a html/url context. the way to provide protection in each of those contexts is different, so the function could just 'look' like it works for expected values, but could be ineffective with the unexpected kind of values hackers would use.

define: ordinary motor? the motor and power supply voltage must be within the 5 to 35 Volt range, with a MAXIMUM motor current of 2Amps. the limiting factor is the power dissipation of the controller, which i think i saw is 25Watts, but for which the heat-sink being used probably isn't big enough to dissipate, but there is over temperature protection built in. of note too, if the supply voltage is greater than 16V, you must separately supply 5V to the controller.

these un-commented, out of context, snippets of code, are almost useless to us. we don't know how they fit into the grand scheme of what the application is doing. if the author of the code, who does have knowledge of and access to the whole script, cannot solve this, what makes you think we can based on seeing a small part of the script? is this a free script that is available for download on the web? if someone can download this to examine or test changes on, you will get quicker and more accurate solutions to your threads. i did get a couple of LOLs out of the above code. it has hard-code logic testing permitted page values, that would have to be found and edited, probably in several locations, anytime a new choice is added and even though the application is using pretty urls, it is building one with a ?page=... parameter in it. the way to build urls is to produce an associative array, usually starting with a copy of the existing $_GET array, adding, removing, or modifying elements in the array, and than call a user written function that knows the rules on how to produce the actual url from the entries in this array. dynamic values being put into the url must be urlencoded so as to not accidentally break the url. either on this forum or elsewhere, i helped you a number of times with the previous phpmotion script you were trying to use. it was written and organized very badly, making each change difficult and repetitive. while it looks like this current script is using some better implementation practices, it still appears to be just a brute-force built, hard-coded, un-commented, massive wall of code, that is difficult to make changes to. i hope you didn't spend any money on this. edit: and here is a problem with storing the username in a session variable to indicate who is logged in. it makes it harder to allow usernames to be edited by the user and impossible if a username needs to be edited by a moderator/administrator. only the user's id (auto-increment integer primary index) should be stored in a session variable to identify who a user is. any other user information should be retrieved on each page request.

the php error you got is a result of the nonworking error handling, but is being caused by the error--prone concatenation used to build the sql query statement. you are missing needed white-space between the 0 and the following ORDER BY... term, that quoting the number satisfied.

some implementation points for the code - you have semicolons ; on the end of your while(...) {; lines, so if your loops are not doing what you expect, this is the reason. 'require' isn't a function, so the () around the filename are not needed and are just cluttering up your code. you have inconsistent, nonworking, and nonexistent error handling for the database statements. you should also not unconditionally output database errors onto a live site (and you shouldn't spend your time editing code when moving it between development and a live site), as this will just give hackers useful information about your connection username and server path when they intentionally trigger errors. instead, use exceptions to handle database statement errors and in most cases let php catch and handle the exceptions, where it will use its error related settings (error_reporting, display_errors, and log_errors) to control what happens with the actual error information (database errors will get displayed or logged the same as php errors.) this will let you remove all the error handling logic you have now, simplifying the code. to use exceptions for errors for the mysqli extension, add the following line of code before the point where you make the connection - mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); you have unused variables and unused columns being SEELCTed in the queries. you should only write code/query syntax that gets used. this is more important if someone other than you is expected to read and figure out what the code/queries are doing, such as forum members where you are asking for help. you have another race/timing problem in the code. by using the highest unixtime from the invoice table to detect new closed bids, you can miss bids if this code runs right before a new close time and takes longer than a second to run. the new unixtime that gets inserted into the invoice table can be greater than a close time that was never processed. (i know of some forum software (VB) that has/had a similar problem where remembering the last visited time and querying for records greater than that time and misses information that does exist but wasn't processed.) the correct way of handling this is to use the id of the highest bid that was processed. you would then query for bid ids that are greater than the highest bid id that was processed. you can put white-space (space, tab, new-lines) in an sql query statement to format it, so all the error-prone concatenation is not needed and is just more clutter in your code. copying variables to other variables is just more error-prone typing and clutter. just use the original variables. don't put quotes around values that are numbers. for what you are doing, inserting invoice record(s) and corresponding item record(s), you should just SELECT the item and bid information (the first JOIN query in your code), fetch the data from that query into an array of sub-arrays of rows, indexed by a composite buyer/seller value for the main array index, and an array of rows for each buyer/seller, then loop over this array of data in the rest of the code. for the rest of the code, all you will need is two nested foreach(){} loops. the first loop would get the composite buyer/seller value and the sub-array of corresponding rows. you would execute the insert query for the invoice table as part of this loop and get the last insert id from this query. the second loop would loop over the sub-array of rows and execute the insert query for the invoice_items table. speaking of looping and executing queries. you should use prepped queries, with place-holders for each value, then supply the values when the query gets executed. this will provide a performance gain (about 5% for INSERT queries) and will also prevent sql injection (any bid or item information that came from an external source could contain sql special characters that will break the sql query syntax, which is how sql injection is accomplished.) you would prepare each query once, before the start of any looping, then just supply the data values when you execute the query inside of the loops. unfortunately, the mysqli extension is overly complicated and inconsistent when dealing with prepared queries, and you should switch to the much simpler and more consistent PDO extension.

the above won't work correctly if there are concurrent instances of your script running, unless you lock the table for the duration of this part of the process, which is undesirable. each occurrence of your script will get the same starting value, attempt to modify and use it, resulting in duplicate values, which should produce query errors, if your table is defined correctly with that column being a unique index, or will mess up your stored data if not. what you should do is have the invoice number column be an auto-increment integer primary key. you would just insert a new row of data, then get the last insert id from that query to use when inserting the item data in the next table.

a couple of implementation points - if you set the fetch mode to assoc when you make the database connection, you won't have to specify it in each fetch statement. you seem to be creating class properties regardless of if they are being used. this is just wasting your time typing things. only create properties, variables, ... if they are needed. for what you are doing, you only need a property for the database connection.

in addition to not using a prepared query correctly, your code should be able to reuse an already prepared query, which it can simply by using implicate binding and calling the execute() method on the returned PDOStatment object with an array parameter consisting of the input data. next, you have two logic problems, where code isn't doing what you think. the first one - $result is normally a PDOStatment object. It will be a true value if the prepare() statement succeeded. It will be a false value if the prepare() statement failed due to an error. it doesn't have anything to do with data from a query. you should be using exceptions to handle database errors (connection, query, prepare, and execute) and in most cases let php catch and handle the exception, where it will use its error related settings to control what happens with the actual error information (database errors will get displayed or logged the same as php errors.) to detect if there is data from a query, just fetch the data and test the fetched result. the second one - you are calling the buildTree(...) function with a row of data from a query, which is an array of the elements in a row. it is not an array of rows or an array of parent ids (which is what you should be doing), so looping over the elements in the supplied value doesn't make any sense. before writing code to do something, it would help if you first wrote a comment that defined what the input(s) are, what processing is going to be done, and what result is returned. next, you should ALMOST never run queries in loops. it is extremely inefficient, mainly due to the communications involved between php and the database server (for most simple queries, the time it takes to execute the query is several times less then the communication time, so you should perform a tasks using the fewest number of queries.) what you should do - execute the first query to get all the first level parent data. (i'm not sure why you have a separate table for the first level parent data, all the data should be in a single table.) get all the first level parent ids into an array. call a recursive function, with the array of parent id as its input, to get all the corresponding child data. if there is no further child data, return from the function. if there is child data, store it in a data structure using the current level's parent id as the array index at the current data level. get all the parent ids from the current level data into an array and call the recursive function again. note: you can use FIND_IN_SET(some_column,?) in a prepared query, then supply a comma delimited string of values via a prepared query place-holder, to let you (re)use a single prepared query inside the recursive function.

that's usually because your code is fetching and discarding the first row. you would need to post your code to get specific help with what is wrong with it.

doing this was a waste of time, since you never defined/set the variable that causes it to 'function', and the undefined variable error you got from it has nothing to do with with any sql query problem. your code needs to ALWAYS have error handling for statements that can fail. the easiest, simplest way of adding error handling for database statements is to use exceptions for errors and in most cases let php catch and handle the exception where it will use its error related settings (error_reporting, display_errors, log_errors) to control what happens with the actual error information (database errors will get displayed or logged the same as php errors.) when learning, developing, and debugging code/queries, you should display all errors, which will now include database errors. when on a live/public server, you should log all errors, which will now include database errors. to use exceptions for errors with the mysqli extension, add the following line of code before the point where you make the connection, and then remove any error handling logic you have in your code now - mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); the above will tell you if a query error is occurring, where in the code it occurred at, and what the error information is. if you are not getting any errors and you are not getting the expected result, you will need to troubleshoot your query/code to find out why.

web servers are stateless. they don't know or care what happens outside of the current request. to do what you are trying, a quote/proposal/shopping cart, you will need to provide a means of propagating the selected item information between page requests. one method of doing this, that is straightforward to implement, is to store the cart information in a session based array variable. the work-flow would be - display products with a means of adding them to the cart. when the 'add to cart' form is submitted, add the item id(s) and quantity(ies) to the session based cart. if you use the item id as the cart's array index and the quantity as the array value, you will end up with the simplest code. to display the contents of the cart, retrieve the item ids from the session based cart (see the array_keys() function), query the database table holding the item information to get the name, description, price, ... of the items in the cart, loop over the result from the query to produce the output, getting the corresponding quantity from the session based cart to calculate the sub total for each item, add the item sub total to a running total variable, then finally display the total price. when the quote/proposal/shopping cart is finalized and converted into an order, you will need to store the contents of the session based cart in a database. you would need (at least) two tables to store the information. the 1st table - 'orders', would hold the unique/one-time order information. this will produce an order_id (auto-increment integer primary index). the 2nd table - 'order_items', would hold rows containing the item id and quantity information making up the order, related back to the order they belong to through the order_id value.

the following is an sql query and the pdo based code needed to retrieve a user's membership status once it has been stored with the information needed to manage and track the data - $sql = "SELECT type, start_date, end_date FROM membership WHERE user_id = ? AND ? BETWEEN start_date AND end_date"; $stmt = $pdo->prepare($sql); $stmt->execute([$user_id,$date]); $user_membership = $stmt->fetch(); the membership table would have columns for - id (integer auto-increment primary index), user_id (integer user/bowler id) , type (integer membership type id that is mapped elsewhere to the membership status names), start_date (date), and end_date (date). the above query is SELECTing the start and end dates, in case you want to display them. remove them from the query if this information is not needed. example code allowing the selection of a made up user and selecting a date to demonstrate how the above query could be used - <?php // retrieve and display a selected user's membership status on any date (default is current date) // define mapping of membership id values to labels/names $membership_map = [3=>'Full Member', 2=>'Social Member', 1=>'Non-member']; require 'pdo_connection.php'; // condition inputs $date = $_GET['date'] ?? date('Y-m-d'); $user_id = $_GET['user_id'] ?? 0; // if a user has been selected, retrieve membership status if($user_id) { $sql = "SELECT type, start_date, end_date FROM membership WHERE user_id = ? AND ? BETWEEN start_date AND end_date"; $stmt = $pdo->prepare($sql); $stmt->execute([$user_id,$date]); $user_membership = $stmt->fetch(); } // make up sample users data - you would query your database table instead $users = []; $users[1] = ['first_name'=>'fn1', 'last_name'=>'ln1']; $users[2] = ['first_name'=>'fn2', 'last_name'=>'ln2']; $users[3] = ['first_name'=>'fn3', 'last_name'=>'ln3']; // display date selection input ?> <form> <input type='date' name='date' value='<?php echo $date;?>'><br> <?php // display user selection input ?> <select name='user_id'> <option value=''>Select a User</option> <?php foreach($users as $id=>$arr) { $sel = $user_id == $id ? ' selected' : ''; echo "<option value='$id'$sel>{$arr['first_name']} {$arr['last_name']}</option>"; } ?> </select><br> <input type='submit'></form> <?php // display the membership status if($user_id) { $user = $users[$user_id]; // 'retrieve' the specific user data from the made up sample data - you would query your database table instead echo "The user - {$user['first_name']} {$user['last_name']},"; if(empty($user_membership)) { //there was no matching row in the membership table echo " has no active membership matching the date - $date, and is therefore a $membership_map[1] on that date."; } else { // there was a matching row in the membership table echo " has an active membership, from: {$user_membership['start_date']}, to: {$user_membership['end_date']}, matching the date - $date, and has a membership type of - {$membership_map[$user_membership['type']]}"; } }

i reviewed your code. i notice there's an event table. if you are going to allow members to participate in events, your design needs to be able to determine the membership status on any date, past/present/future, such as the date(s) of an event. by only storing the current status in a column and updating it to manage the membership expire and renewal, you will not be able to do anything like this. also, to 'update' the values, you will need to actually execute a query with great enough frequency to keep the values in all the rows up to date, so that someone visiting the site doesn't ever see wrong information. if you do what i posted in my reply above in this thread, you will have a simple solution that can determine the membership status on any date, doesn't require any update queries at all, and will always return current, correct and accurate membership status information.

if you mean named place-holders, no, the order doesn't matter. they are matched via their names.

that's a good introduction that can be boiled down to the following for select, insert, update, and delete queries - 1) when you make the connection, set the character set to match your database tables, set the error mode to exceptions, set emulated prepared queries to false, and set the default fetch mode to assoc. 2) if there are no external/unknown values being put into the sql query statement, just use the PDO query() method. this returns a PDOStatement object for accessing the result from the query. 3) if there are external/unknown values being put into the sql query statement, use a ? place-holder for each value in the sql query syntax (without single-quotes around it/them) and add each value to an array. call the PDO prepare() method, which returns a PDOStatement object, same as for the above item, and then call the PDOStatement execute() method, with the array of input values as a parameter. Items #2 and #3 can be combined into a single user written method, so that you can have a common single-point call to use throughout your code.

the code you are currently producing is where we were back when using the mysql_ extension. it took a lot of code to securely handle each different type of data being put into the sql query statement and a lot of code to provide error handling for all the statements that can fail. by using prepared queries, the simple and consistent PDO extension, and exceptions to handle errors, most of the implementation detail code disappears. you only have to validate that data meets the needs of the application, which in most cases is just to make sure it is not an empty value or that is has an expected format, form the sql query statement, with place-holders for any external/unknown data values and array of input data values, then either call the prepare/execute methods or the query() method (which you can combine by extending the PDO class with a general purpose query method that accepts an optional 2nd array parameter of input values) to run the query. letting php handle the exception/error will give you all the file name, line number, and sql error information, that will either get displayed or logged based on the php error settings, without requiring any conditional logic in your code or ever touching the code after it is written. this just takes one line of code to set the error mode to exceptions when you make the connection. (lol i just noticed that you are using the connection error statements in your insert query error handling.)

nope. you should validate input only, not alter it. for any sanitation you can come up with, there are libraries of things hackers use that can get past it. the only fool-proof way of preventing anything in data from being treated as sql syntax is to use a true prepared query (PDO has emulated prepared queries that should be avoided.) prepared queries also eliminate all the single-quotes around values and all the concatenation, extra quotes for concentration, and any {} that people have used to get values into the sql query statement. don't waste your time writing and then changing code just because the context changes. write code once and leave it alone.

since you should be using a prepared query with external/unknown data values, your current code is not general purpose and will need to be redone to make it secure. you will want to switch to the much simpler php PDO extension, since it requires fewer statements to accomplish any task and the result from prepared and non-prepared queries can be treated in the same way. also, you should be using exceptions to handle connection, query, prepare, and execute errors and in most cases let php catch and handle the exception, where it will use its error related settings to control what happens with the actual error information (database errors will get displayed or logged the same as php errors.) by unconditionally outputting the raw error information on a live/public server, you will only be helping hackers who intentionally trigger errors, since connection errors contain the db username, and all the errors contain server path information. next, to dynamically produce sql statements, use arrays to hold the column/value terms and implode() the results. this will eliminate all the extra commas and substr() statements. lastly, you apparently didn't look very closely at the echoed sql query statement. you are putting back-ticks ` around the values. do you know what using back-ticks in an sql context means?

in the most general purpose and simple implementation, the membership status value for a user is derived data and should not specifically be updated/reset, just queried for when needed. you would query to get the membership status value by querying to find if there is an 'active' (the current date or date in question is between the start and end dates) membership record for the user in question. if there is a matching record, retrieve the membership status value. if not, use the default Non Member value.

the action='...' attribute in a form tag is the URL to which the form will submit. it is not the name of a php function, since the browser has absolutely no idea what the server side code is. since you should be submitting the form to the same page it is on, you can just leave the whole action='...' attribute out of the form tag. when the form is submitted, your form processing code needs to detect that a post method form was submitted, validate the submitted data, then safely supply that data to the INSERT query. to safely supply the data to a query, you will want to use a prepared query, with a place-holder in the sql query statement for each value, the supply the actual data when the query gets executed.

no. $map is an array, with an element/line for each input/output mapping. starting what what i posted, to avoid making even more changes, add a line for each of your new role names and tax classes - $map['wholesale_silvia_silver'] = 'WholesalePSTGST'; $map['wholesale_silvia_gold'] = 'WholesalePSTGST'; ...

yes. that is the ideal way of implementing this. but before you start making changes like this, make sure this is within your programming skill level. currently, the mapping of role (name) to tax class is hard-coded in the program logic you have shown in this thread, and it would appear that in an earlier version there were 5 different functions to do this, one for each possible input/output combination. the use of the $map array that i suggested, simplifies the current method, so that you are not writing out and fixing program logic for each possible combination. you just have an array that defines the input/output combinations. to change to having the tax class defined with the role, would require that you add a column to the database table (or perhaps just add a new key/value if the table is using the wordpress metadata style of storage), write a new ->getUserWholesaleClass() method to retrieve the value, then change the code you have posted in this thread so that it just gets and returns the tax class for the user.