Jump to content

mac_gyver

Staff Alumni
  • Posts

    4,641
  • Joined

  • Days Won

    133

mac_gyver last won the day on January 20

mac_gyver had the most liked content!

About mac_gyver

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

149,676 profile views

mac_gyver's Achievements

Prolific Member

Prolific Member (5/5)

514

Reputation

75

Community Answers

  1. What's your fee to rewrite my code for me? Re:

     

  2. that date format is not directly sortable. where is this data coming from/stored at? you should store dates in a YYYY-MM-DD format, which will allow easy sorting by the date, then output the date in the format that you want when you display it. if this data is coming from a database, sort it in the sql query. if this data must be sorted in php, you would use php's usort() function, with a call-back function to sort on the date field. if that incoming date format cannot be corrected at the source, i would first convert the format, all at once, to be YYYY-MM-DD, then sort the data, then format the date back to that format when you display it.
  3. change the code to use arrays for the sets of data under each major category, rather than processing each list/site separately. write two new functions (keeping the old code as is.) the new add_all_subscribers_lists_array() function would build arrays of parameters inside the inner foreach() loop, then call a new add_subscriber_list_array() function once, after the end of the inner foreach() loop. the code in the new add_subscriber_list_array() function would loop over the arrays of input parameters, query for the data and build each .csv file, then call the wp_mail() function once, supplying an array of the attachments. of some concern is that the code is creating a new database connection for each list/site. are all these databases on the same database server, with the only difference being which database is selected? if so, the code only needs to select the database before each query, rather than create an entirely new connection for each list/site query. for the 7warriors .csv, the posted code only outputs three headings, but there are four columns of data. to fix this, you would define a specific $column_names array inside the 7warriors conditional logic.
  4. if the order of the posted code is actually what exists, your validation logic is after the point where you are inserting the data. how do you expect this to prevent the insert query from executing? you would need to validate the data first, then execute the insert query if there are no validation errors. the simple way to do this is add any validation errors to an array, using the field name as the array index, then after all the validation logic, test if the array holding the validation errors is empty. if the array is empty, you would build, prepare, and execute the insert query. to display the validation errors, when you re-display the form, you would test and display the non-empty content of the array. next, validating each different input is not dependent on the result of the previous validation step. you should validate all the inputs at once, so that the visitor can correct all the validation errors at one time. you should also not use isset() for inputs that will always be set when the form has been submitted. only un-checked checkbox and radio buttons won't be set. by using isset() for the always set form fields, you are hiding programming/typo mistakes and cluttering up your code with unnecessary typing. you should trim all inputs at once, then use the trimmed values throughout the rest of your code. if your current code was in the proper order, you are validating the trimmed values, but using the original untrimmed values in the query. the simple way of correcting this is to keep the input data as an array, use array_map() to make a trimmed copy into a different, working variable (you want to leave the original $_POST data as is), then operate on elements in this working array variable throughout the rest of the code. finally, the header() redirect in your post method form processing code should be to 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 if the user reloads that page or browses away from and back to that page. the header() redirect also needs an exit; statement after it to stop php code execution. if you want the user to be able to go to a different page, provide navigation link(s.)
  5. the most immediate problem is that the query didn't match any data (or possibly didn't execute at all, but there would have been another php error at the mysqli_fetch_array statement.) see the php.net documentation for mysqli_fetch_array's return value - https://www.php.net/manual/en/mysqli-result.fetch-array.php code should ALWAYS test if data was fetched from a query before trying to use the data, and setup a user message if there was no data. // at the point of using the data if(!$fetch) { echo 'no data was found.'; } else { // use the data here... } the most likely reason for no matching data is either because $_GET['id'] doesn't contain any value or the value it does contain doesn't match any data in the table. you should ALWAYS validate inputs to your code before using them. if $_GET['id'] isn't set, is empty, or doesn't contain an integer value > 0, that's an error. you should setup a user message in this case and not attempt to run the sql query. you should ALWAYS have error handling for statements that can fail. for database statements that can fail - connection, query, prepare, and execute, the easiest way of adding error handling, without adding logic at each statement, is to use exceptions for errors and in most cases let php catch and handle the exception, where php will use its error related settings to control what happens with the actual error information, via and uncaught exception error (database statement errors will 'automatically' get displayed/logged the same as php errors.) next, don't put external, unknown, dynamic values directly into an sql query statement. use a prepared query instead. lastly, don't copy variables to other variables for nothing. this is just a waste of typing. just use the original variables.
  6. it appears that php is not seeing or using the php.ini. there are a couple of common possibilities - the php.ini is actually named php.ini.txt, due to editing by a MS program, such as notepad.exe. have the file extensions been 'exposed' (a web search should show how to do this) on the computer, so that you actually see the whole filename.ext? when you browse to folders, do you see extensions like .exe, .txt. .dll? AFAIK, right-clicking on the php.ini and selecting 'properties' should show the actual full filename? if the php.ini is actually php.ini.txt, rename it to be just php.ini php doesn't report when there are syntax errors in .ini files, i.e. there is not a parse/syntax/reporting phase, just run-time errors for statements that fail when executed. how was php obtained and installed on the computer, i.e. has anyone else been editing the php.ini and could have introduced syntax errors in it?
  7. are there any other extensions enabled in the php.ini that DO show up in the phpinfo output? check the web server's error log for any recent lines mentioning problems with loading the mysqli library/dll. also, delete and retype the mysqli in your line of php code in case it contains some non-printing or non-ascii characters, the result of copy/pasting, that are causing it to not be recognized by php.
  8. you must find and set those three php error settings in the php.ini on your system, because - your main code file never runs upon a php syntax error, so putting the settings in your code won't do anything for this type of error. the display_startup_errors setting does nothing when in your php code because php has already started. while you are changing settings in the php.ini, find the output_buffering setting and set it to OFF. php's output buffering should only be used when you want to buffer output and it being on hides non-fatal php errors and any output from your code when you have header statements in your code. by putting these in the php.ini, you have one location where you can change them and you don't need to edit any code when you move your project to a live/public server. stop and start your web server to get any changes made to the php.ini to take effect and then use a phpinfo() statement in a .php script that you open as a web page to conform that the settings actually got changed in case the php.ini that you are changing is not the one that php is using.
  9. did you stop and start your web server to get any changes made to the php.ini to take effect? also, is the php.ini that you are changing the one that php is using (there's a loaded configuration... line in the phpinfo() output that states what file is being used.) the phpinfo() output will also list if/when the mysqli extension is being successfully loaded.
  10. the sample data, which was probably defined to demonstrate this issue, ran out of users that could perform role id 7 before reaching the role id 7 evaluation. when this occurs, you need to be willing to accept a less than ideal solution, by introducing a random element into the process. a general method would be to take the top n (n = 1, 2, 3, ...) initial entries in the $roles_array, shuffle it/them, and produce a 'current' array consisting with those shuffled entries and the remaining unshuffled entries and try to produce a solution using that data that satisfies all the roles that have required importance. repeat the shuffling for each n value at least n squared times to give the shuffling a chance to produce unique results (computers are not very good at doing things randomly.) after each shuffle, check if the key order has already been tried, by remembering the composite key sequences, that have been evaluated, in an array, by imploding the keys with some unique character, e.g. a | or similar. if the key order has already been tried, skip the current evaluation loop.
  11. of topic, but please use var_export() when posting sample data.
  12. this issue has nothing to do with any php version/change. it appears that the checkInput() function definition was just thrown around some main code, based on the number of undefined/uninitialized variables and on the result of the function processing not being returned to the calling code. the main problem causing the error is here - $serial->sendMessage("$senddata\r"); checkInput($senddata); what does supplying $senddata, which contains a string, i.e. the data that was defined to be sent by calling sendMessage(), have to do with calling checkInput? hint: checkInput($serial);
  13. the error means that $serial contains a string, rather than an instance of a class. you would need to determine how a string got assigned to the variable.
  14. php functions have (proper) black-box model local variable scope, so that you can freely write code for a function definition without needing to know what every variable is throughout the rest of the code base (wordpress has thousands of functions) in order to avoid conflicts and improper operation. the $pega variable inside the get_future_conferences function doesn't exist. if you had php's error_reporting set to E_ALL and display_errors set to ON, you would be getting an undefined variable error at the 'value'=>$pega line that would alert you to the problem. the $pega variable should be an optional (there are undoubtedly existing calls) call-time input to the get_future_conferences function, telling it what date to use to match future conferences. apparently the filtering code used by get_posts() uses the current date when no value is supplied.
  15. this is a set of data where you will be operating on each element in the set in the same/similar way. arrays are for sets of data. you should be using arrays for the form fields and loop over the submitted arrays of data.
×
×
  • 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.