Moving to PHP 8 without pain for PHP 7 users #766
Replies: 5 comments
-
|
Beta Was this translation helpful? Give feedback.
-
What is in PHP 8 that's such an advantage? I like the idea of using libs like Guzzle in theory. In practice, I've had broken WPs due to having two plugins with slightly different versions of Guzzle. As in, their dependency specs were exactly equivalent but |
Beta Was this translation helpful? Give feedback.
-
It's probably just some bright and shininess for me, but some better typing/reflection support. So, I won't be abandoning 7 support anytime soon, just want to get started on 8. I'll look into the Guzzle issue, I thought Composer namespacing solved some of that, but seems not. I think there's a way to force it under our own namespace, else, I can do some rewriting into a new namespace to solve that.... |
Beta Was this translation helpful? Give feedback.
-
Sweet, as above, there are things out there to make this easier now, no suprise, from the great minds @ Delicious Brains |
Beta Was this translation helpful? Give feedback.
-
Reading through this was a useful refresh on the issue. I'll add some more thoughts specific to WP2Static. This is core's current prod depenencies:
I'm quite happy to keep Guzzle in, as we're doing so much requesty stuff and having rewritten it a few times to try cURL/Guzzle/wp_remote's, I'd rather commit to Guzzle for less lines of own code and more confidence.
public function __construct( string $url, string $parent_page_url = null ) {
$url = new \Wa72\Url\Url( $url );
if ( $parent_page_url ) {
$this->parent_page_url = new \Wa72\Url\Url( $parent_page_url );
$this->url = $url->makeAbsolute( $this->parent_page_url );
} else {
// test absolute URL
if ( ! $url->getHost() ) {
throw new WP2StaticException(
'Trying to create unsupported URL'
);
}
$this->url = $url;
}
}
/**
* Return the URL as a string
*/
public function get() : string {
return $this->url;
}
/**
* Rewrite host and scheme to destination URL's
* - mutates URL object in place
*
* @param string $destination_url URL rewrite rules
*/
public function rewriteHostAndProtocol( string $destination_url ) : void {
$destination_url = new \Wa72\Url\Url( $destination_url );
$this->url->setHost( $destination_url->getHost() );
$this->url->setScheme( $destination_url->getScheme() );
} So, my leaning today is to:
It sounds like a lot of effort, but shouldn't be - once the script to rename the namespace is written, it behaves like any other dependency with custom VCS in our At most, it should need a comment or more descriptive name for the wrapped Guzzle library to inform developers why/what is is. like // our own namespaced fork of Guzzle
use WP2StaticGuzzle\Client; or use WP2StaticsSafelyNamespacedGuzzle\Client; |
Beta Was this translation helpful? Give feedback.
-
I'm keen to get started on PHP 8-ifying WP2Static and friends. I can do this fairly safely, as long as I don't drop updates/bug fixes for PHP 7.x users, who will be around for a while. With no auto-updates in WP2Static now and Lokl being an isolated environment, my main concern is how to manage the 2 codebases (as per this Py2/3 article, I don't want to compromise by only having a 7/8 compatible codebase, as there's so many nice features in PHP-8).
Some options:
This complicates development/requires more instructions/cognitive load. Scripts expecting things at certain paths may not work. Requires users wanting to run from source code to do more. For Packagist users, requires extra syntax to target 8. Users downloading pre-built zips don't have any issues - just choose the 7 or 8 version.
Keeps development much simpler, issues are neatly dropped into right repo. 8 users would be minority initially, so could call repo
wp2static-php8
. I don't want to change namespaces within code, so for Packagist, would require using the new repo if you want the 8 version. Eventually, 7 would be EOL'd and 8 codebase merged back into mainwp2static
repo.Leaning towards this option. @john-shaffer that shouldn't cause any disruption to StaticWeb's current implementation, but do you envision any issues if we start to offer 7/8 environments when spinning up? Seems this would be simple enough to allow that to work - just a new AMI / provisioning scripts?
Preparing PHP 7 versions to be 8 compatible
I've seen some breakage already in trying to run current plugins in an 8 environment. ie, not being able to use non-static methods as callables in static way; I'm also seeing 0 files being crawled, which may be around the
is_resource()
/CurlHandle
changes.Beta Was this translation helpful? Give feedback.
All reactions