Im not a php developer per se, but I know enough to get by.
Ive been tasked with upgrading a basic php v7 website to php v8. I know the shorthand tags wont work, are there any other stumbling blocks that I may come across? I know this is a very very nebulous question. Perhaps theres a cheat sheet of things that have changed between php v7 to v8?
Depends on the functions that website uses really. If that website is well up to date with standards then upgrading from PHP 7 to PHP 8 will be a breeze.
Become familiar with php.ini which is updated with every PHP Version and also note the location varies depending on the operating system. Please note that php.ini contents are compiled and any syntax errors results in the default php.ini file being used without any notification!
When developing locally find the relevant php.ini location and ensure the following are set by removing preceding ;
error_reporting = E_ALL # or -1 which is maximum error reporting
display_errors = On # show on screen
display_startup_errors = On # prevent blank screen on syntax errors
search for <span and </span and modify to your requirements.
With item #4 I have the following modifications:
a. copy and paste the lines
b. remove leading ;
c. change span to pre
d. add style=âwidth:88%; margin: 1rem auto; background: AQUA, color: #000:, etcâ
The above modifications make errors and warnings far more readable otherwise a vast amount of errors and warnings are shown without linefeeds, etc. Donât forget to compile the modifications by calling the following Command Line:
systemctl reload apache2
Edit:
Add the following command to the start of every PHP file because unlike error_reporting, display_errors, etc the declaration only applies to that file and is not inherited.
<?php declare(strict_types=1);
Test the above by setting the following:
ini_set(âdisplay_errorsâ, 1);
Php has an excellent online manual, learn how to search and use the manual
Thanks guys. This is all very useful! Ill be doing a lot of bedtime reading!
Regards the short tags no longer being supported in v8, my colleague mentioned to me yesterday that this had actually been rescinded, and will continue to be supported until v9. Is that the case?
magic_quotes was removed a very long time ago. After that point there was no need to test for the gpc setting being on and apply stripslashes() to any external value, because php was no longer altering the value. The get_magic_quotes_gpc() function always returned false after that point, so the stripslashes() code was always skipped. Now that get_magic_quotes_gpc() function has finally been removed, you just use the $value as is.
Thatâs an incorrect assumption. Read the setcookie() documentation. The default value for the 2nd parameter is an empty string, if you donât supply that parameter.
The problem is the 1st parameter. session_id(), when called with no input parameter, returns the current session id, if there is one (requires session_start() to be called first), or returns an empty string. If sessiont_id() is called with an input parameter, before session_start() is called, that parameter value is used as the id when the session is started. This whole line of code never did anything useful, but didnât fail with a fatal error before. What has probably changed is the error level/handling for the 1st, required, setcookie() parameter.
The session can hold information other then the login value, so destroying the whole session can cause data in a more complicated application to disappear. The only piece of data that the login/logout code is responsible for is $_SESSION[âlogged_inâ], and thatâs the only thing this code should be affecting.
This is telling you the value of $conn is null.
Iâm guessing $conn is supposed to be a database connection, if it is there is likely to be bigger problems happening before you close it.
So it will be a case of checking your connection to find at which point it is failing.
Since php destroys all variables/resources when your script ends, thereâs generally no good reason to try to close a database connection in your code. Just let php close it for you.
Iâve never prefixed a function name with & and must try when on the desktop.
I would prefer using curly braces with the if statements or at least add a blank line to make the function more readable⌠which also makes modifications less likely to have errors.
Gone are the days of saving bytes, except in special cases. Making script readable at a glance certainly reduces time spent debugging.