Why It’s Time to Move On

Elevating Security Measures

The foremost incentive for migrating to PHP 8 is to guarantee that your WordPress platform runs on a version that regularly receives updates and security patches. Unsupported versions of PHP lack these critical updates, leaving your web applications vulnerable to security risks. Thus, it’s wise to confirm whether your hosting provider offers the most recent PHP versions before deploying a web application.

Ensuring Compatibility

Another compelling reason to embrace the latest PHP version is to avoid the pitfalls of incompatibility. Operating on outdated versions could jeopardize the functionality of your website—a major concern for any web developer. Supported versions of PHP are continually refined and monitored to fix any issues or vulnerabilities, making it imperative to stay abreast of the latest updates.

Boosting Performance Metrics

PHP 8 brings a notable increase in performance. For instance, PHP 7.4 enabled systems to execute thrice as many REST API requests per second compared to PHP 5.6. PHP 8 takes this a step further, offering performance that is almost four times better. Refer to the table below for detailed speed scores and REST API performance metrics.

How To Do The Update To PHP8

Upgrading PHP: A How-to Guide

Upgrading to a newer PHP version can be a smooth process if you’re prepared. However, potential challenges such as bugs or failed upgrades can occur.

Pre-Upgrade Checks

First, make sure that your website is compatible with the latest PHP version. You can check this information through your web hosting control panel. If an upgrade is available, you can usually complete it in a few simple steps. Switching to a supported PHP version through the control panel is generally straightforward.

PHP Version Lifespan

Note that a PHP version typically has a lifespan of three years, after which it’s advisable to move on to a newer version.

Step 1: Make a backup. Backup your entire site and keep that copy safe.

Use a Backup Plugin

1. Backup your WordPress site using a plugin like “Duplicator”.
2. Navigate to your WordPress dashboard, then go to wp-admin > plugins > add new.
3. Search for “Duplicator.” Side note: Our clients get the use of the Duplicator Pro license. Also, we would do this for our clients.
4. After activation, follow the on-screen instructions to back up your site.

With a backup in hand, you can confidently upgrade your PHP version.

Alternatively, some service providers allow the backup and generation of a staging site. If that’s available, try it out.

Step 2: Make a staging site. Use the backup to make a staging copy of the website.

Create an identical copy of your website in a staging environment to test the PHP upgrade. Benefits of using a staging site include:

• Risk Mitigation: Testing on a staging site helps prevent revenue loss or user decline if something goes wrong. It’s also security through obscurity: if a staging site is hard to find, it’s hard to hack.
• Thorough Testing: Staging allows for extended testing, reducing the likelihood of overlooking bugs or bugs that only come up from outlier situations.
• No Downtime or Glitches: Any issues can be fixed on the staging site first, ensuring your reputation remains intact.

Step 3: Let ‘er rip.

Update the staging site to PHP 8.1 or 8.2 and then see what breaks. Current code will be ready for PHP8 in most cases. You may see very few issues. If the result is a disaster, make note of all of the errors that came up, then downgrade back to your previous PHP version and proceed cautiously.

Step 4: Meticulous re-coding.

If things go wrong with the “Let ‘er rip” approach, you need to do some detective work.

• Make sure your PHP8 has all of the correct extensions active. Some service providers offer PHP8 but leave many of the extensions inactive.
• Make sure WordPress code is current. It will be PHP8 compatible.
• Make sure your theme is current. If it isn’t, contact the developer who made the theme and ask them for a PHP8 compatible version.
• Make sure the plugins are current. Again: if they cause issues, take those issues to the respective plugin developers.
• Make sure your custom code works. If it doesn’t bring in a developer. (we’re developers, FYI).

PHP.net list of Changes

This list of changes and issues comes from PHP.net:

Additionally, care should be taken that error messages are not displayed in production environments, which can result in information leaks. Please ensure that display_errors=Off is used in conjunction with error logging.

• #[ is no longer interpreted as the start of a comment, as this syntax is now used for attributes.

• Inheritance errors due to incompatible method signatures (LSP violations) will now always generate a fatal error. Previously a warning was generated in some cases.

• The precedence of the concatenation operator has changed relative to bitshifts and addition as well as subtraction.

  <?php
echo "Sum: " . $a + $b;
// was previously interpreted as:
echo ("Sum: " . $a) + $b;
// is now interpreted as:
echo "Sum:" . ($a + $b);
?>

• Arguments with a default value that resolves to null at runtime will no longer implicitly mark the argument type as nullable. Either an explicit nullable type, or an explicit null default value has to be used instead.

  <?php
// Replace
function test(int $arg = CONST_RESOLVING_TO_NULL) {}
// With
function test(?int $arg = CONST_RESOLVING_TO_NULL) {}
// Or
function test(int $arg = null) {}
?>

• A number of warnings have been converted into Error exceptions:

  • Attempting to write to a property of a non-object. Previously this implicitly created an stdClass object for null, false and empty strings.
  • Attempting to append an element to an array for which the PHP_INT_MAX key is already used.
  • Attempting to use an invalid type (array or object) as an array key or string offset.
  • Attempting to write to an array index of a scalar value.
  • Attempting to unpack a non-array/Traversable.
  • Attempting to access unqualified constants which are undefined. Previously, unqualified constant accesses resulted in a warning and were interpreted as strings.
  • Passing the wrong number of arguments to a non-variadic built-in function will throw an ArgumentCountError.

  A number of notices have been converted into warnings:

  • Attempting to read an undefined variable.
  • Attempting to read an undefined property.
  • Attempting to read an undefined array key.
  • Attempting to read a property of a non-object.
  • Attempting to access an array index of a non-array.
  • Attempting to convert an array to string.
  • Attempting to use a resource as an array key.
  • Attempting to use null, a boolean, or a float as a string offset.
  • Attempting to read an out-of-bounds string offset.
  • Attempting to assign an empty string to a string offset.

• Attempting to assign multiple bytes to a string offset will now emit a warning.

• Unexpected characters in source files (such as NUL bytes outside of strings) will now result in a ParseError exception instead of a compile warning.

• Uncaught exceptions now go through “clean shutdown”, which means that destructors will be called after an uncaught exception.

• The compile time fatal error “Only variables can be passed by reference” has been delayed until runtime, and converted into an “Argument cannot be passed by reference” Error exception.

• Some “Only variables should be passed by reference” notices have been converted to “Argument cannot be passed by reference” exception.

• The generated name for anonymous classes has changed. It will now include the name of the first parent or interface:

  <?php
new class extends ParentClass {};
// -> ParentClass@anonymous
new class implements FirstInterface, SecondInterface {};
// -> FirstInterface@anonymous
new class {};
// -> class@anonymous
?>

  The name shown above is still followed by a NUL byte and a unique suffix.

• Non-absolute trait method references in trait alias adaptations are now required to be unambiguous:

  <?php
class X {
use T1, T2 {
func as otherFunc;
}
function func() {}
}
?>

  If both T1::func() and T2::func() exist, this code was previously silently accepted, and func was assumed to refer to T1::func. Now it will generate a fatal error instead, and either T1::func or T2::func needs to be written explicitly.

• The signature of abstract methods defined in traits is now checked against the implementing class method:

  <?php
trait MyTrait {
abstract private function neededByTrait(): string;
}

  class MyClass {
  use MyTrait;

  // Error, because of return type mismatch.
  private function neededByTrait(): int { return 42; }
  }
  ?>

• Disabled functions are now treated exactly like non-existent functions. Calling a disabled function will report it as unknown, and redefining a disabled function is now possible.

• data:// stream wrappers are no longer writable, which matches the documented behavior.

• The arithmetic and bitwise operators +, -, *, /, **, %, <<, >>, &, |, ^, ~, ++, -- will now consistently throw a TypeError when one of the operands is an array, resource or non-overloaded object. The only exception to this is the array + array merge operation, which remains supported.

• Float to string casting will now always behave locale-independently.

  <?php
setlocale(LC_ALL, "de_DE");
$f = 3.14;
echo $f, "\n";
// Previously: 3,14
// Now: 3.14
?>

  See printf(), number_format() and NumberFormatter() for ways to customize number formatting.

• Support for deprecated curly braces for offset access has been removed.

  <?php
// Instead of:
$array{0};
$array{"key"};
// Write:
$array[0];
$array["key"];
?>

• Applying the final modifier on a private method will now produce a warning unless that method is the constructor.

• If an object constructor exit()s, the object destructor will no longer be called. This matches the behavior when the constructor throws.

• Namespaced names can no longer contain whitespace: While Foo\Bar will be recognized as a namespaced name, Foo \ Bar will not. Conversely, reserved keywords are now permitted as namespace segments, which may also change the interpretation of code: new\x is now the same as constant('new\x'), not new \x().

• Nested ternaries now require explicit parentheses.

• debug_backtrace() and Exception::getTrace() will no longer provide references to arguments. It will not be possible to change function arguments through the backtrace.

• Numeric string handling has been altered to be more intuitive and less error-prone. Trailing whitespace is now allowed in numeric strings for consistency with how leading whitespace is treated. This mostly affects:

  • The is_numeric() function
  • String-to-string comparisons
  • Type declarations
  • Increment and decrement operations

  The concept of a “leading-numeric string” has been mostly dropped; the cases where this remains exist in order to ease migration. Strings which emitted an E_NOTICE “A non well-formed numeric value encountered” will now emit an E_WARNING “A non-numeric value encountered” and all strings which emitted an E_WARNING “A non-numeric value encountered” will now throw a TypeError. This mostly affects:

  • Arithmetic operations
  • Bitwise operations

  This E_WARNING to TypeError change also affects the E_WARNING “Illegal string offset ‘string'” for illegal string offsets. The behavior of explicit casts to int/float from strings has not been changed.

• Magic Methods will now have their arguments and return types checked if they have them declared. The signatures should match the following list:

  • __call(string $name, array $arguments): mixed
  • __callStatic(string $name, array $arguments): mixed
  • __clone(): void
  • __debugInfo(): ?array
  • __get(string $name): mixed
  • __invoke(mixed $arguments): mixed
  • __isset(string $name): bool
  • __serialize(): array
  • __set(string $name, mixed $value): void
  • __set_state(array $properties): object
  • __sleep(): array
  • __unserialize(array $data): void
  • __unset(string $name): void
  • __wakeup(): void

• call_user_func_array() array keys will now be interpreted as parameter names, instead of being silently ignored.

• Declaring a function called assert() inside a namespace is no longer allowed, and issues E_COMPILE_ERROR. The assert() function is subject to special handling by the engine, which may lead to inconsistent behavior when defining a namespaced function with the same name.

The post Upgrading to PHP8: Why You Should Upgrade Your WordPress Server appeared first on Web321: Your Best WordPress Support.