Jump to content


Staff Alumni
  • Content Count

  • Joined

  • Days Won


mac_gyver last won the day on November 6

mac_gyver had the most liked content!

Community Reputation

457 Excellent


About mac_gyver

  • Rank
    Staff Alumni

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

147,304 profile views
  1. the only user information you should store in a session variable is the user id. you should query on each page request to get any other user related data, which you would store in a general program variable/object, named as to the meaning of the data. the reason for doing this is so that any changes to the values will take place immediately (on the next page request.) by storing the values in session variables, they will only reflect any changes when someone logs in again. once you retrieve the user related data from wherever it is persistently stored, you would use it for determining both what the user can do and what the user can see on each page. what makes you think that? do you have code on your site that allows users to create or edit php program variables?
  2. Yes. It provided a better user experience, since you can directly display any validation errors when you re-display the form and you can re-populate the form fields with the previously submitted data so that the user doesn't need to keep re-entering the same values over and over. It also takes less code over doing these things on two separate pages since you don't need to pass error information and field values between pages. The only things that are needed to accomplish this are 1) put the form processing code above the start of the html document and 2) put the form processing code inside of a conditional statement that detects if a post method form has been submitted so that it only runs if the form has been submitted.
  3. does the activation link contain a run-once unique token? this would let you know if something is just submitting email addresses or actually has access to the content in the emails.
  4. if a business rule of the application is that that booking/busy times start/end on 30 minute intervals, you would need to provide a method of picking values that follow that rule and you would need to validate submitted data to insure that it meets that rule. if you have existing data that doesn't follow that rule, you can normalize the values, either where they are stored or when pre-processing the array of data, to round start times down to the previous interval time and round end times up to the next interval time.
  5. here's an outline of what the logic would look like - $interval = 30; // booking/busy interval in minutes // based on conditional logic in the code, 0 = mon through 6 = sun define('MON',0); // use defined constants to make code/data self-documenting // working hours $hours = []; $hours[MON] = ["morning_from" => "closed", "morning_to" => "closed", "afternoon_from" => "13:00", "afternoon_to" => "19:00"]; // note: if you define the above array as an array of arrays, with the from/to values, a label (Morning/Afternoon), and a 'closed' or time entry, you can just loop over this to produce the output without needing to have specific code for each possible segment in a day // busy times - the example data is for a monday $busy = []; $busy[] = ["title"=> "Test", "start_date" => "2019-11-25 13:00:00", "end_date" => "2019-11-25 14:00:00"]; // pre-process the booked/busy data $data = []; foreach($busy as $arr) { $date = $arr['start_date']; $end_date = $arr['end_date']; while (strtotime($date) <= strtotime($end_date)) { $data[$date] = $arr['title']; $date = date("Y-m-d H:i:s", strtotime("$date +$interval min")); } } // examine the pre-processed booked/busy data echo '<pre>'; print_r($data); $current_date = '2019-11-25'; // determine the current date being displayed using whatever logic the code has now $book_day_int = date('N') - 1; // get the integer day of week number - 1 $current_day = $hours[$book_day_int]; // get the from/to data for the current day // morning output (see the note above by the $hours array to simplify and make the code general-purpose) $start = $current_day['morning_from']; $end = $current_day['morning_to']; if( $start != 'closed') { echo 'Morning<br>'; $start = "$current_date $start:00"; $end = "$current_date $end:00"; $date = $start; $end_date = $end; while (strtotime($date) <= strtotime($end_date)) { echo $date; // test if this date-time is busy if(isset($data[$date])) { echo ' ' . $data[$date]; } echo '<br>'; $date = date("Y-m-d H:i:s", strtotime("$date +$interval min")); } } // afternoon output $start = $current_day['afternoon_from']; $end = $current_day['afternoon_to']; if( $start != 'closed') { echo 'Afternoon<br>'; $start = "$current_date $start:00"; $end = "$current_date $end:00"; $date = $start; $end_date = $end; while (strtotime($date) <= strtotime($end_date)) { echo $date; // test if this date-time is busy if(isset($data[$date])) { echo ' ' . $data[$date]; } echo '<br>'; $date = date("Y-m-d H:i:s", strtotime("$date +$interval min")); } }
  6. here’s how you should do this - pre-process/expand the booked/busy array of data so that it has entries for each 30 minute interval of the appointment, using the date-time value Y-m-d H:i:s as the array index. for the example data, you would end up with three entries - 2019-11-25 13:00:00, 2019-11-25 13:30:00, and 2019-11-25 14:00:00, all with the same title as the array value (if the data for each appointment is actually more than this, store it as a sub-array under each index.) get the day of week number from the current date you are displaying, then get the morning/afternoon start and end times for that day, loop over the 30 minute intervals, from the start time to the end time, produce the date-time value for each interval - Y-m-d H:i:s, then test (isset() will work) if there’s an entry in the pre-processed booked/busy data array for the current interval.
  7. chrisj, what is the overall reason you have been beating on this script (and the previous phpmotion script) for so long? is this for a collage course assignment? is this for self-learning? do you think that having a video sharing script will help you to make money? some other reason? the main reason i ask is, most of your posts seem like you just want someone else to think/write code for you, and your only involvement is to be a 'proxy typist' pushing keys on a keyboard. this is not how programming help works, doesn't result in any learning, and doesn't result in much progress. you need to be able to define for yourself what the code/data should do, then through learning enough php/sql/html/css/javascript, be able to design, write, test, and debug the code needed to produce an application or make changes to an existing application. you need to sit down with paper/pencil or an open text document, and list out the top-level work-flow (steps) that need to occur, from the point where someone first visits your site through to the point where they watch a purchased video. you would then define what the user interface (UI) looks like for each step. you would then define what input data, what processing, and what result or output is needed to accomplish each step. the part of the process where you are at in this thread is when the user has hit the submit button during the 'checkout' step. regardless of this being for physical or digital items or using real money or credits, the processing is the same/similar. you would store/convert the cart items in to a 'pending' (unpaid) order. when payment is confirmed, you would update the order status to 'paid' and either trigger the shipment of physical items or make digital items available for downloading/viewing. since you are using credits that are being managed on your site, as far as the order status, you would determine if the user has enough credits in their account, update the order status to 'paid', deduct the amount from the user's account, add the earned amount to the video owner's account, and add the reminder to the system's account. all the database queries that modify data as part of this step, must be part of the same database transaction, so that if any of them fail, they all fail and roll-back. to manage the amounts, each video (which can have its own price, resulting in a different earned amount, and a different remainder for the system) that's purchased should have a separate set of records inserted into the account table. here is the starting definition for the account table - since the time when i wrote that, i think it would be a good idea to add the video purchase id (auto-increment integer primary index from the paid_videos table) so that the account records are related to the video purchase record they correspond to. so, what would be inserted into the account table foreach(){} video that is purchased - a row with the purchaser's id (id_user), the negative of the video purchase price, a transaction type id (for a purchase), the last insert id from the row that was inserted into the paid_videos table, and the current datetime. a row with the video owner's id (user_id_uploaded), the positive earned amount for the video, a transaction type id (for an earned amount from a purchase), the last insert id from the row that was inserted into the paid_videos table, and the current datetime. a row with the system's id, the positive remainder between the video purchase price and the earned amount, a transaction type id (for a system share of a purchase), the last insert id from the row that was inserted into the paid_videos table, and the current datetime. the transaction_type_id in the above means that you need a 'transaction type' table, with an id column and a name column. to get the account total for any user id, you would just SUM() the total column, and group by the user_id column, for any single, list, or all users (depending on the WHERE clause used.) to get the account total for any/each transaction type, you would additionally group by the transaction type id column.
  8. what output do you get and if it's a blank page, what does the 'view source' of the page in your browser show? either the output is hidden in the 'view source' or the code isn't being executed. since you apparently are getting the data inserted, it's possible you are 'seeing' the result of a double page request, especially since you are using a get request to do this rather than a post method form.
  9. to do this, you need to produce an array that defines the permitted choices and also contains entries that control which tables/columns to use in the query. you would then dynamically produce the base query by having general-purpose code that makes use of the data in the array. short-answer: you are trying to produce a data driven design, rather than to hard-code logic for every possible choice. some comments about the existing code - use domain relative urls, this will eliminate the need for the $page_url value. trimming input data after you have tested if the data is empty is backwards. use http_build_query() to produce links in your code from any existing get parameters and any new values. this will eliminate the need for the preg_repalce() statement near the start of the code. put the 'get method' business logic before the start of your html document. the base query, with any table, join, where, and having clauses must be the same for both the COUNT(*) query and the data retrieval query. build this part of the query and any bound input parameters, in this part of the query, in dedicated php variables, then use these variables when building and executing the two queries. put literal, constant values directly into queries, such as the publish = 1 value. use implicate binding, by supplying an array of the input values to the execute call. don't copy variables to other variables without a good reason. just use the original variables.
  10. how much total code/files is/are there? if you post your code (less any database/api credentials) somewhere (in the forum or on github) you would get more specific help about what you do need to change. since your code works under php5.6, you don't have to deal with register_globals, and the only things to update would be those that have been removed, are backward incompatible, or are deprecated (to future-proof) in going from 5.6 to 7.x.
  11. if your code is not making any shell/system/passthru calls, it doesn't matter what operating system you use for a development system. all that matters is you have the same set of extensions and php.ini settings between the development system and the live server. you can use one of the all-in-one development packages. the mysql extension became deprecated as of PHP 5.5 (released in 2013) and would have been throwing errors in your code if not for the @ error suppressors. don't ever use @ error suppressors in any code. on a live/public server, your php error related settings should be set to log all errors. if you are faced with updating old code that uses the mysql extension, do yourself a favor and 1) jump directly to use the very simple and future-proof PDO extension, 2) use prepared queries when supplying external/unknown data to an sql query statement (this actually simplifies the sql query syntax), 3) using implicate binding (supply an array of values to the execute call) for prepared queries, and 4) use exceptions for 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 'automatically' get displayed/logged the same as php errors.) doing these four things greatly simplifies the implantation of your database specific code, which will let you eliminate, rather than convert code, shortening the task.
  12. if you use exceptions for database statement errors and in most cases let php catch and handle the exception, php will use its error related settings to control what happens with the actual error information (database errors will 'automatically' get displayed/logged the same as php errors.) you will be able eliminate the existing error handling, rather than to convert it. to enable exceptions for errors for the mysqli extension, add the following line of code before the point where you make the database connection - mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); now the bad news, it is not enough to just update statements in old code, as one of the things that was removed in php5.4, magic_quotes, eliminated some protection that php provided against sql special characters in external string data from breaking the sql query syntax (which is how sql injection is accomplished.) if your code does not have specific protection for all external/unknown data, and for all the different data types, being put into sql queries, you will need to add it. the simplest, universal way of doing this is to use prepared queries, provided that you switch to use the simpler PDO extension. the prepared query interface for the mysqli extension is overly complicated and inconsistent
  13. if you use the simple session cart definition that has been given on a different forum, using the item id as the array index, and storing the quantity as the array value under the index, doing what you are asking only takes a couple of lines of code.
  14. detect that a post method form was submitted. trim all input data at once, so that you can detect if all white-space characters were entered (this is the only alteration you should make to the input data.) if more more than one form will submit to the same page, add logic, using your favorite method, to detect a unique field/value from the form, to control which form processing code to execute. validate all input data, storing unique and helpful validation error messages in an array. this array is also an error flag. if the array is empty, there are no errors. if the array is not empty, there are errors. if there are no validation errors, use the submitted form data. afaik, the form name is not submitted, as the form tag is not an input field. the submit button may or may not be set, depending on how the form gets submitted and/or which browser is being used, so, don't bother testing it. if you need to distinguish between multiple forms on one page, add a unique key/value as a hidden form field, and detect this in your code. except for un-checked check boxes and radio buttons, once the form has been submitted, all other form field types will be set, even if they are empty, so there's no point in cluttering up code with isset() statements for these types of fields. you would want to see (during development)/log (on a live/public server) php errors if expected-set form fields are not set, as this indicates either a programming mistake or someone/something submitting their own set of fields. as an advanced programming subject, dynamically validate and process the submitted form data, by defining an array, with the field names as the array indexes, and an array of elements under each index controlling the validation steps and the type of processing for each field. none of this has anything to do with security. security is achieved by using data properly in whatever context it is being used in. if used in an sql context, use a prepared query. if used in a html context, apply htmlentities() to the data. if uploading files, store them in a location that is not directly accessible through a http request.
  15. this is due to floating point conversion errors. see this link on how to do this math using binary coded decimal numbers, i.e. like a hand-held calculator does - https://www.php.net/manual/en/book.bc.php
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.