Jump to content

mac_gyver

Staff Alumni
  • Posts

    5,362
  • Joined

  • Days Won

    173

Everything posted by mac_gyver

  1. my 2ยข. your offer table should hold the unique/one-time information about each offer. once you have inserted a row of data into that table it should only be updated in the case of a mistake in a value or its status changes, such as being marked as deleted. you need all the raw offer data to be stored in that table, giving you an audit trail, so that you can detect if a programming mistake, multiple form submission, or nefarious activity has inserted an incorrect offer. if a new offer supersedes or modifies an existing offer, that should be handled when the data is queried for or in the processing when it is fetched.
  2. you have actually been give the answer - don't put function definitions inside of other function definitions.
  3. some other possibilities - it's conditionally defined - inside another function definition that hasn't been called yet or inside some conditional logic that didn't execute it's not within php tags at all it's using a short opening tag that's not enabled it's within a comment the OP needs to post the complete contents (including the opening php tag in the file) of redirect.php in order to either confirm or eliminate the various possibilities as the cause.
  4. @Ehsan_collboywhatever you are using to translate our replies into your native language is not working. 'defined at' in this means location, i.e. what file name is it in? this means how are you getting the function definition into the login.php code? typically, you would 'require' the file containing a function definition into any code that needs to call the function.
  5. no one stated that was a solution. just as a test it caused one small part of the problem to no longer produce a php syntax error. if the ?'.'> exists throughout the templates, there's probably a reason for it, regardless of how bad of a reason it is. unless you actually find what's causing the problem and correct it, you will end up wasting a lot of time for nothing. given that you haven't read, translating as necessary into your native language, and followed all the instructions given or answered all the questions asked, i don't think we can help you.
  6. your snippets of code do not show us the necessary context that would allow anyone here to help. where exactly is the function defined at and how is it being made available to the code where it is being called?
  7. the complete instructions you were given included - doing this will tell you, and us, what the actual run-time value is, which can be different from the php.ini setting. what is the current version you are trying this on? (guessing 8.0 based on the last php.ini path). if/when you down-grade to php7, repeat the phpinfo exercise and actually find the short_open_tag line in the resulting output to see what it is. back to the error and the code in question - that the application gets to the point of trying to operate on the php in a template file means that it has values for those php variables and constant, and the application is not completely broken. the php syntax error for eval'ed code usually states that it is from eval'ed code (don't know if this has changed), so this code is probably being required. php syntax errors in requeued code does run the main code up to the point of the require statement. assuming that nothing has been altered in any code up to this point, in an attempt to 'fix' the current problem, the only way this code could have ever 'worked' is if every instance of the ?'.'> (found in all the short-print tags with a php variable, but not in the short-print tag with a php constant) gets replaced with ?> before it is passed to the php language engine. my guess as to the reason for the ?','> would be that someone passed the template code through a validator and this kluge made it pass validation. the current problem could be simply due to some character matching difference, even the character encoding of quotes inside a string in a file, that is no longer matching the ?','> exactly and is leaving it as is. as a test, i manually changing all the ?'.'> to ?>, there is no php syntax error and the code runs. where exactly are you seeing that error message? is it output on a web page, and if so, what if anything else is output on the page, including in the 'view source' in the browser? OR are you seeing it in an error log file and the web page is blank? is this a public-facing web site that you can post a link to?
  8. it apparently is a Chinese developed forum - https://en.wikipedia.org/wiki/Discuz!
  9. to check what value php is using for the setting, create a .php script with a phpinfo(); statement in it and see what the line in the output shows for the short_open_tag setting.
  10. there is apparently a โ€œfull_opening_tagโ€ fixer as part of this tool - https://cs.symfony.com/ as always, make sure you have a complete, verified backup before making any changes to your code.
  11. not to the core php language. up to date php5 code, that doesn't use any now removed features, has a good chance of working as is.
  12. the most likely cause are the short opening <? tags, on lines 1 and 15 in the posted code and everywhere else they are used, being disabled. you can attempt to make this 'work' by enabling them in your php.ini the ideal way to fix this would be to do a search/replace to change all the <? tags, which must be followed by at least one white-space character (which isn't shown on line 15, but then again you didn't follow my instructions for posting the code), but not the <?= tags, into full <?php tags.
  13. php syntax errors are reported on the line where php encounters something it cannot understand within the current context. the actual problem is usually prior to the line where the syntax error is reported. post lines 1-19 exactly as they are in the file, using this forum's <> menu button. also, since this is a template system of some type, there's no telling what exactly the meaning is of any of the characters we can see in that snippet of code, if the initial/final double-quotes are part of the code or added by the OP, or even if we are seeing all the characters because the code wasn't posted here as code.
  14. please post the actual code and output in the forum, using the <> menu button. pictures are impossible to use as input for testing.
  15. first in a question and $time1 = ... $time2 =... values buried in a picture of code in this post - then in a non-picture example in this post - the $time1 and $time2 are the start/end of one rental instance. the date-time ranges the OP listed in those examples are between those $time1 and $time2 values, with a break at midnight, so the resulting ranges are per day, pre rate on each day, for that specific rental period.
  16. it appears that the OP is asking for any single rental instance to be automatically broken down by amount per day, per rate. his later examples aren't for x different rentals, but for one rental broken down into those date-time parts.
  17. do you actually care if the breakdown lists the specific time part or would something that looks like the following, which is simpler to code, tell you what you want to know - Array ( [2022-04-08] => Array ( [Norm] => 528 [Peak] => 708 ) [2022-04-09] => Array ( [Peak] => 256 [Norm] => 1568 ) )
  18. this is a commonly used method. if your code doesn't work and you cannot determine why, you will need to post all the relevant code needed to preproduce the problem.
  19. just posting a snippet of your code doesn't help, because it doesn't show how you are using that code. for all we know, you aren't actually calling that function, aren't calling it with any input value, aren't using the return value at all, or could be assigning a value in a comparison, rather than making a comparison. when you have code that doesn't work, and you cannot determine why, you need to post all the relevant code needed to reproduce the problem.
  20. you always need error handling for statements that can fail. you should also insure that you have php's error_reporting set to E_ALL and display_errors set to ON, in the php.ini on your development system, so that php will help you by reporting and displaying all the errors it detects. if you run this code on a live/public server, you would instead set display_errors to OFF and set log_errors to ON. the mail() function returns either a true or a false value. for a false value, php will either display or log the actual error information, so that you will have an indication of the call failing. however, in your code for a false value, you should log your own information consisting of the datetime, the php error that occurred, and the parameter values that were supplied to the mail() call. this will let you debug problems that are occurring due to things like email addresses that cause an error. for a true value, because email can be unreliable, you should actually log or insert rows in a database table with the same information, so that you can check if you are receiving all the emails that are being sent. once you do the above you will probably get errors about an invalid mail header, a missing From: header, and/or errors about relaying restrictions. the mail headers must contain a From: email address. the syntax is From: email address \r\n this email address is NOT the address that was entered in your form. these emails are not being sent from the user's email address (except perhaps during testing that you may have done using an email address that does correspond to your web hosting.) they are being sent from the mail server at your web hosting. the email address in the From: header must correspond to your web hosting. you can put the entered email address into a Reply-to: mail header. the are a number of issues with the posted code. the most immediate problems are - the code is not indented properly, so you cannot see what exactly it is or is not doing. the current code will attempt to sent the email, even if the entered email address is not valid. you should actually store the user/validation errors in an array, using the field name as the array index. then, after the end of all the validation logic, if the array is empty, use the submitted data. this will simplify all the nested conditional logic. to display the errors, at the appropriate location in the html document, you would test if the array is not empty, then either loop over or implode the contents of the array to display the error messages. the $body variable is being reassigned on each pass through the foreach(){} loop. this leaves you with only the last checkbox message as part of the body. since there could be any number of checkbox messages, i recommend that you add each one to an array, inside of the loop, then after the end of the loop, implode them with whatever markup you want between them, then append this to the end of the main message body. don't write out code for each possible value. if you had 10 checkboxes, would writing out all that conditional logic 10X make sense? you should use a data-driven design, where you have a data structure (array or database table) that holds the definition of the data. for the checkboxes, you would have an entry in the defining array for each checkbox. the main array index would be the values (1,2,...) each entry in the main array would be an array with elements for the label, and the mail body text. you would use this defining data structure when dynamically building the checkbox markup, when validating the submitted checkbox values, and when adding the text to the mail body.
  21. that error is due to the above line of code, which is something that you changed in the code. when you got that error message, did you even look at the code to try and find out what's causing the problem? at this point, you are making changes to the code that are introducing errors that didn't exist before and are not even attempting to find and fix your own problems. this error, if you read it and notice where the output is occurring at, happens to be the line where the previous warning about the $email variable is being output. the previous warning being output to the browser is the output that's preventing the header() from working.
  22. wouldn't those Warnings indicate that the variables don't exist at the time they are being echoed? i recommend using php's Null Coalescing Operator to prevent those errors - https://www.php.net/manual/en/language.operators.comparison.php#language.operators.comparison.coalesce <?php echo $var ?? ''; // echo the variable if it exists, or an empty string ?> next, one of the points made was to apply htmlentities to external, unknown, dynamic values when used in a html context - <?php echo htmlentities($var ?? '',ENT_QUOTES); ?> lastly, if you look at what the code is doing, especially the part that you know works, i.e. the email specific code, you will see what the variable names actually are.
  23. there's not really any point in using a post method form to pick which page to go to using a header() redirect (which causes a get request for those pages, the post data won't exist after the redirect anyway.) if you are doing this so that you can have 'buttons' to click on, just use a link that is a button.
  24. this is random nonsense. that line is the syntax you would use if putting the setting into a php.ini file. it's not the syntax for putting the setting into a php file and if it was the correct syntax (which your first post in this thread contains), it would be php code and would go after the opening php tag. the current error you are getting, which you apparently didn't even read to determine that the output that's preventing the header() from working, is occurring on line 1 of your file. that's the random line you added before the opening php tag. if your dynamic pages are being cached in the browser, you need to setup your web server's configuration, so that it tells the browser to never cache .php files.
  25. the original posted code has an unset() statement for the specific session variable, that works as expected for me.
×
×
  • 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.