Define PHP version support policy

[felixarntz]

With this being a PHP ecosystem project not tied to WordPress, we should discuss which PHP versions we want to support.

I think a reasonable starting point for the discussion is:

• We could decide to always back-support until the minimum required PHP version that WordPress Core uses, in alignment with that project. Currently that's PHP 7.2.
• That said, that minimum requirement is vastly out of date and not aligned with the majority of the PHP ecosystem. At the same time, one might argue that the official PHP version support policy is so fast in marking PHP versions as stale that it's unrealistic for a project that is built with WordPress usage in mind to follow suit. Only PHP 8.4 and 8.3 are actively supported.

I think we should review individual PHP versions and the potential benefits that using paradigms only introduced in them would have on this project. Then we can have a nuanced discussion on whether these benefits are worth not supporting older PHP versions.

Most likely, the biggest jump in new language features happened between PHP 7.4 and PHP 8.0.

Let's discuss.

[aaronjorbin]

The biggest benefit of having the same version policy as Core is that if there is a feature that comes from here that is proposed for merging with Core, it can get merged without needing to be rewritten. Additionally, by having the same requirements as Core, users aren't stuck wondering why they can't enable the official way to use what is suspected to be a popular feature set.

If there was a core piece of functionality that was only available in more recent versions of PHP, I could see the case for using that as the requirement. If my memory is correct, this is how timezones worked with php4 and 5. ( See the history/usage of wp_timezone_supported ). But the bar should be high here, not just that there is syntactic sugar that developers want to use.

[felixarntz]

I largely agree with your take @aaronjorbin. If we want to have a higher version requirement, it needs to be based on very clear benefits it would have over 7.2.

I want to clarify though that that bar needs to be higher or lower depending on which minimum PHP version requirement we're talking about. Reason being, that there are no immediate or even near-term goals to merge this into WordPress Core. Just to make an example: If we're thinking about merging this in a year from now, and WordPress Core in a year from now required at least PHP 8.0, and PHP 8.0 had a feature we would notably benefit from here, it would not have been a smart choice to go with 7.2.

Now, of course we don't know if WordPress Core in a year from now will require PHP 8.0, or 7.4, or still 7.2 as today. But this is just an example to explain my rationale: For example requiring something like PHP 8.3 is probably completely out of the question. If we go with a version higher than 7.2, the lower it is, the easier it might be to justify given that WordPress Core will, eventually, also bump its requirement.

[desrosj]

While I mostly agree with @aaronjorbin (all official projects should follow the same support policy as Core), I'd like to play devil's advocate a bit.

One other angle to think about is how this is adopted in plugins and other projects. Say as an example, this repository uses PHP 8.0 as the requirement. If a plugin wants to use this SDK in their code, they would also need to declare their plugin's minimum PHP version as 8.0. While this would (under today's numbers) effectively exclude a large percentage of WordPress sites from being able install these plugins (not the desired outcome), being calculated about choosing a minimum version could be a way to encourage users to upgrade their sites. "Look at this cool AI feature in this plugin. Oh I can't use it because of my PHP version. Let me upgrade."

That said, unless there are compelling reasons why (features in more recent versions of PHP are required by this plugin to accomplish its goals), I agree with matching Core's support policy.

[JasonTheAdams]

Great thoughts so far! I think supporting core's policy is the safest move in terms of adoption. That said, I'm going to attempt to pitch for 7.4, here's my thinking:

I'm pretty convinced that there are going to be two audiences that will adopt and use AI in WP as users:

1. Power users that are excited about AI and want to use it in WordPress
2. New users getting it through hosting

I emphasize new users actually because of business reasons. I believe that the majority of the market will be introduced to AI in WP by purchasing WP hosting from somewhere and AI tokens are included in that plan. The reason being: they don't totally understand AI and even less so how to set it up (i.e. get an account somewhere and get an API key). For these users, they'll simply assume that these features are a part of the WP site they just purchased, associating it with WP itself.

Ok, so the business reason: I don't think hosts are going to simply add AI tokens to their existing plans with no increase in cost, simply because AI cost is not insignificant. As such, it will be new users purchasing plans that include AI tokens.

Here's how this connects back to PHP: Taking GiveWP as an example, of the new users in the past year, < 1% are on PHP 7.3-, 25% are using PHP 7.4, and 74% are on 8.x. If hosts offer PHP 7.x in their plan, it seems to always be 7.4. Most hosts are using 8.x in new plans, and strongly encouraging folks in 7.x to upgrade.

So there you go. Hahah! In short, I think the actual market of users to ultimately adopt this will very likely be on 7.4 and greater, or be a power user that probably already has updated their version of PHP or knows how.

[felixarntz]

@JasonTheAdams Thank you for sharing these insights here.

While the usage of PHP versions today is an important considerations, I personally would reiterate the previous point that the PHP version should primarily be decided based on substantial practical developer needs. In other words: Does PHP 7.4 offer substantial practical benefits for developers over PHP 7.2 (other than obviously that it's newer, likely faster and more secure)? If not, I'm not convinced about requiring 7.4. On the flipside, if something higher like PHP 8.0 had such benefits, I think that would be worth considering despite being even higher of a minimum requirement.

At the end of the day, it also depends a bit on the ecosystem we're integrating with. Especially if our path forward is to use existing PHP client SDKs for the individual providers, we would need to consider their version requirements. Looking at some examples:

• https://github.com/google-gemini-php/client requires PHP 8.1+.
• https://github.com/openai-php/client requires PHP 8.2+.
• https://github.com/Alle-AI/anthropic-api-php requires PHP 7.4+ (but this SDK is also wildly out of date, so questionable to rely on).

This makes the PHP version policy question tricky. Two options:

1. We define the main SDK version independently of specific provider SDKs, but then if a provider SDK requires a higher PHP version, it simply means sites on an older PHP version won't be able to use that provider.
2. We don't use any provider SDKs, but build those connections entirely ourselves.

Based on my experience with the AI Services plugin, where I went with option 2, I need to emphasize that option 2 would be a ton of work, with questionable ROI. While it in principle has benefits like us controlling the entire stack throughout the SDK and provider implementations, some of the provider specific API nuances are extremely complex, and relying on a well-maintained SDK for the specific provider (where such one exists) would certainly be a more effective choice, not reinventing the wheel.

I acknowledge that I'm diverging a bit into another question here: Build the full stack connection to each provider ourselves, or use established provider-specific SDKs under the hood for that. But I believe this is partially relevant to the discussion about PHP version requirement, which is why I'm raising it here.

[felixarntz]

After reviewing the key PHP features that versions newer than PHP 7.2 introduced, I'm leaning towards requiring PHP 7.4+, so I am now in agreement with @JasonTheAdams's proposal above, for the following reasons:

• PHP 7.4 introduced parameter and return type covariance, which is a huge win for API design. It also introduced typed class properties, which is neat (although that alone would probably have not been sufficient to argue for 7.4).
  • See https://www.php.net/manual/en/migration74.new-features.php.
• As of today, PHP 7.4+ is used by 91.2% of WordPress sites. PHP 7.2+ is used by 95.8% of WordPress sites, so this will only "lose" 4.6% of sites.
• While that is still a large number of sites in absolutes, it does not block these sites from using WordPress in a safe way. It will only be a blocker to using the canonical AI implementation, and I don't think it's worth holding back the remaining 90+% for <5%.
• The next PHP version that would bring substantial benefits would be 8.1, but the usage of PHP 8.1+ is far too low (barely over 50%) to require it.

For these reasons, I second @JasonTheAdams's above proposal. His points about version usage are reasonable, and coupled with the noteworthy language features added in PHP 7.4, I think it makes most sense as a trade-off between forward-thinking and backward-compatibility.

[JasonTheAdams]

I agree with your agreement. 😆

But yeah, covariance is a big deal as a feature, and typed properties a good follow. The main features I'll miss here from 8.x that I think would otherwise be useful to this project are:

• Enums in 8.1
• Union types in 8.0

But we can live without those. Not having covariance, on the other hand, forces one to rethink the architecture.

[jeffpaul]

I would be mostly in favor of setting 7.4 as the minimum as that's likely where WP core is headed in the near future. That's a relatively weakly held opinion and if someone was STRONGLY in favor of 7.2 to match WP core then that would be fine (and we could update alongside core whenever it does formally raise its minimum). Similarly if someone felt particularly STRONGLY about 8.x for "reasons", I could get on-board with that as well. But all things being equal, my vote lands in the 7.4 bucket.

[swissspidy]

7.4 also sounds good to me given core‘s move towards that.

[felixarntz]

Thank you all for the feedback.

Based on the discussion, let's go with PHP 7.4+. It looks like @borkweb already opened relevant initial PRs #16 and #17 🎉

[felixarntz]

Since we made the decision to go with PHP 7.4+, I'd like to raise some additional thoughts that we didn't fully consider so far (although I mentioned something related in #3 (comment)):

• In order to implement support for different providers, we can either use an existing SDK (under the hood, the developer using WordPress/php-ai-client wouldn't need to know) or implement the provider connection manually.
• I did the latter when implementing AI Services, but it's a real pain.
  • First of all, it's extremely complex work, especially when it comes to handling streaming and all the different nuances between how providers handle it. These streaming nuances aren't documented - I haven't found a single provider that covers it. Most providers focus heavily on using their APIs via SDKs. While they usually have some kind of REST API reference, it's very high-level and doesn't cover things like how to process streaming responses.
  • It also means we have to stay on top of any provider API changes ourselves, which is a questionable objective, and it'll be difficult to do that reliably. Relying on a provider-specific SDK, which as the sole purpose has to support that provider, is a lot more effective that way.
• For that reason, I think using provider-specific SDKs under the hood is the only effective solution. Not doing that will create significant overhead for questionable value, not just in the initial implementation, but in long-term maintenance. The more providers we support, the worse that would become, and in the interest of provider neutrality, that wouldn't be a great precedent.
• Why does this relate to PHP version? Because, naturally, almost all existing provider-specific SDKs require newer PHP versions than 7.4.

There are two options to consider here, if we implement provider support via existing SDKs:

• Either we implement each provider in its own package. In that case, we could keep the root package require PHP 7.4+, but individual providers would have their own (likely higher) PHP version requirements, depending on the SDK in use.
  • Benefit: The root package remains backward compatible with PHP 7.4.
  • Downside: Sites on those older PHP versions may realistically not be able to use any popular provider, or possibly no provider at all.
• Or we consistently require a PHP version that allows us to keep it consistent, including possibly bundling providers that fulfill certain requirements, which makes consumption of the package more straightforward. This would likely mean having to require PHP 8.2+.

Now, I acknowledge that requiring PHP 8.2+ would mean that only ~40% of today's WordPress sites would be able to use this package. That said, I am not sure how much of a problem this is. Unlike when we discuss PHP version support for e.g. WordPress Core, here there is no security component at play. If your site cannot use AI, well, you cannot use AI. You can still use WordPress in a safe way. Not using this package does not have any adverse impact on a site's security. There's obviously also the point of nudging sites to bump their site's PHP version. Given the demand for AI capabilities, that may end up being a positive side effect of this package for the health of the WordPress and PHP ecosystem.

I'm opening this up for additional discussion of these considerations.