PHP on Linux WordPress image is almost out of support

Question

I currently run WordPress on a Bitnami Linux VM with PHP 7.2.16. Support for PHP 7.2 ends in 18 days on 30 Nov 2020 (https://www.php.net/supported-versions.php), so I thought I would try a WordPress Linux WebApp on Azure. However I have discovered that its PHP is even older, at 7.2.13.

Multiple articles and posts say you can control the PHP version from Settings > Configuration > Platform, but there is no such UI element.

This article says you can show the PHP version:

https://learn.microsoft.com/en-us/azure/app-service/configure-language-php?pivots=platform-linux

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion  

But that returns "DOCKER|appsvcorg/wordpress-alpine-php:0.72", which says nothing about PHP.

The same article suggests setting the PHP version as follows:

az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "PHP|7.3"  

That returned "UnrecognizedArgumentError: unrecognized arguments: -linuxFxVersion PHP|7.3".

So how do I bump the PHP major version? I hope I don't need a custom container to implement a supported platform?

Mark Berry

Answer 1

Thanks to RoderickBant74 for pointing the typo and sharing the correct cmdlet.

Just adding additional information on this for clarity:

To control the runtime version (for apps which doesn't support built-in images) you can deploy it with a custom container.

You may use this "az webapp list-runtimes --linux | grep PHP" - To show the supported PHP version.

Just to highlight, the "--linux-fx-version"- shows the runtime stack used for your linux-based webapp, e.g., "RUBY|2.5.5", "NODE|10.14", "PHP|7.2", "DOTNETCORE|2.1".

As a side note, App Service upgrades the underlying PHP runtime of your application as part of the regular platform updates. As a result of this regular update process, your application will be automatically updated to the latest patch version of PHP available in the platform.

As examples:
When you use this template the docker image which has WordPress already configured is run for the created App Service. By default, the image is - appsvcorg/wordpress-alpine-php:0.72 (source).
https://hub.docker.com/r/appsvcorg/wordpress-alpine-php

Now, since this creates a Web App for Container (not using specifically a blessed image), we do not show the stacks in the Configuration blade. Note that you can set the linuxFxVersion to PHP|7.3 but that would pull a docker image which would not have WordPress configured as default.

The image mentioned above (appsvcorg/wordpress-alpine-php:0.72) for WordPress uses PHP v7.2. If you wish to run on PHP v7.3, then you could try using the following imagee which can be set in the Container settings blade:
appsvcorg/wordpress-alpine-php:0.8

So, if you wish to see the stack specific configuration dropdown in the Configuration blade with PHP application (for the WordPress as well) on App Service, then you can create a Web App service without using the ‘WordPress on Linux’ template ( just as an example). That way he would be able to see the available stacks in the Configuration.

Hope this helps!

---

To benefit the community, find the right answers, please do mark the post which was helpful by clicking on ‘Accept Answer’ & ‘Up-Vote’.

Answer 2

Holy cow, I think that did it. Thank you! Now I get a multi-page JSON string with the PHP version buried inside. My container now returns PHP 7.3.21. If I set "PHP|7.4", I get 7.4.9.

In other news, the show query is now working as well:

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

now returns "PHP|74". Wish I'd known how to do a full show before (just omit the --query parameter) to see if linuxFxVersion was originally set to "DOCKER|appsvcorg/wordpress-alpine-php:0.72",

I'm used to PowerShell where the get and set parameters use the same syntax. This disconnect between query (linuxFxVersion) and set (linux-fx-version) is confusing!

Thanks again for your help.

Answer 3

Did you also notice the - dashes between linux, fx and version in the --linux-fx-version example? All in lowercase letters.