Coding in PHP 7.4 and Deploying to 7.1 via Rector and GitHub Actions

Coding in PHP 7.4 and Deploying to 7.1 via Rector and GitHub Actions

Coding in PHP 7.4 and Deploying to 7.1 via Rector and GitHub Actions .We’ll explore how to develop a WordPress plugin using PHP 7.4 code and release it containing code from PHP 7.1 and below via Rector and GitHub Actions.

PHP developers want to have access to the latest features of the language, but for various reasons, they may not be able to. It could be that the client’s server runs on an older version and can’t be upgraded, or the CMS must support legacy code, or the user base would shrink significantly, or others.

But there is a solution: we can use a transpiler to transform the code using the new syntax to the legacy one. Transpilers deliver the best of both worlds; developers can code using the latest features and generate an asset for production that works with previous versions of the language.

In my previous article, I introduced Rector, a reconstructor tool for PHP. Now let’s put it into practice. In this article, we’ll explore how to develop a WordPress plugin using PHP 7.4 code and release it containing code from PHP 7.1 and below via Rector and GitHub Actions.

Why PHP 7.1

I started transpiling my WordPress plugin as a consequence of WordPress deciding not to bump the minimum PHP version, which is currently 5.6. You may then wonder, why am I transpiling to PHP 7.1 and not to PHP 5.6?

There are two reasons for this. Firstly, Rector performs transformations based on rules, such as ArrowFunctionToAnonymousFunctionRector, which downgrades code from an arrow function from PHP 7.4 to an anonymous function from PHP 7.3 and below:

class SomeClass
     public function run()
         $delimiter = ",";
-        $callable = fn($matches) => $delimiter . strtolower($matches[1]);
+        $callable = function ($matches) use ($delimiter) {
+            return $delimiter . strtolower($matches[1]);
+        };

From the roughly 20 downgrade rules implemented to date, only a handful are from PHP 7.1 to 7.0, and none from 7.0 to 5.6. So there is limited support for reaching 7.0, and no support yet for targeting 5.6.

That doesn’t mean that Rector cannot support PHP 5.6, but the work must be done. If the rules are eventually implemented (before WordPress bumps its minimum version to 7.1, otherwise they won’t be needed anymore), I could then target a lower PHP version.

The second reason concerns third-party PHP dependencies. These must be transpiled, too, alongside our application code, and doing so may involve significant effort.

For instance, if a dependency requires PHP 7.1, and I target PHP 7.1 for my application, then the dependency is directly supported and I do not need to transpile its code. But if I target PHP 7.0 or 5.6, then I do need to transpile it.

Transpiling third-party dependencies can become challenging because they are not under my control. Just browsing its code is not enough; I would need to do thorough research to make sure that all PHP 7.1 code in the dependency can be transpiled. A single feature that escapes my attention could well make the application fail on runtime.

In my case, my application has one dependency requiring PHP 7.2 and a few dozen requiring PHP 7.1 (more about this later on). Since I do not have unlimited resources, I chose to target PHP 7.1 and transpile one dependency than to target 7.0 and transpile dozens.

As a result, my WordPress plugin won’t be available to users running WordPress 5.6 and 7.0, but that’s a trade-off I’m happy with.

Supported PHP features

When stating that an application can now use PHP 7.4 code, that doesn’t necessarily mean it can use every single feature introduced to PHP 7.4. Rather, it can use only those features for which there is a Rector rule to downgrade them.

Moreover, not all features can be transpiled, and some features won’t be transpiled because of some reason or another.

For instance, among the new constants introduced in PHP 7.4, constants SO_LABEL, SO_PEERLABEL, and others are FreeBSD-specific socket options. That seems too specific, so I don’t expect anyone to implement a Rector rule for them.

As a result, the application will not fully support PHP 7.4 (if anyone does need constant SO_LABEL, it won’t be there); instead, it can fully support PHP 7.1 and be enhanced with a set of features from among PHP 7.2, 7.3, and 7.4.

php wordpress web-development programming developer

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

PHP Web Application Development Company

As a top **PHP Web Application Development Company in USA**[]( ""), we at Data EximIT have...

PHP Website Development

Skenix Infotech is a leading PHP Web Development Company that helps companies get results with industry best practices. Get affordable PHP Development Services.

Hire Dedicated PHP Developer

Looking to hire affordable yet experienced PHP developers? **[Hire Dedicated PHP Developer]( "Hire Dedicated PHP Developer")**, who can convert your idea to reality, within the stipulated...

Hire WordPress Developer

Whether you want to develop a blog or you want a feature-rich, interactive WordPress website? **[]( "")** is a distinguished leader in the WordPress development market. **[Hire...

Best WordPress Development Services in India

Skenix Infotech is a top WordPress Website Development Company in India & USA with expert WordPress Developers. Get affordable WordPress Development Services.