Transition from Alpine Linux to Debian for WordPress on App Service

Hi there, 
nice to see this one evolving further. Although hosting Wordpress on Azure is quite expensive compared to standard Webhosting (especially in regards to FrontDoor/CDN aspects); availability and scalability are still among the best options out there. 

I am currently playing around with it and doing some test migrations, everything looks really nice and neat so far.
Two things that I have run across, which could be optimized:

Using W3TC for storage integration - this stores uploads on Azure Blob Storage and makes them publicly available, which is not optimal for every scenario. If I want WordPress to be able to fully control access, I either need to use Azure Files (crazy expensive for large content like video) but it would allow native read/write access and therefor should work with each and every Wordpress plugin. Or have a part of /wp-content/uploads linked as read-only Azure Storage and manage its content manually by moving files in/out of Azure Storage and manually adjusting database links.

I am running into some font-loading issues with one of my favorite plugins, not sure yet if that one is a CORS issue or maybe a mime type one - and a default caching of 365 days on standard setup OOBE makes troubleshooting that a nightmare. A good 'troubleshooting' guidance would be nice - where to enable which logs, which log contains which service's errors, some common issues etc.

When I got my font issue resolved, I will start moving some small projects over 🙂

Well done and thanks again for the great job

Thank you for this post.

I think a link was missed here:

You can find more details here: Using custom startup commands with Web App for Containers

As you know, the startup script for the Alpine image ignores the 'Startup Command' configuration in the Azure Portal and simply executes the script found at /home/dev/startup.sh. Does the Debian image work the same, or us 'Startup Command' used from the Azure portal now?

Hello mpetz1495 ,

Thank you for your comment! It's encouraging for us. We prioritize performance and security and continuously work on optimizing costs. We appreciate your suggestions regarding storage integration and logging and will definitely look into them.

mpetz1495 There are some notes on debugging here: https://github.com/Azure/wordpress-linux-appservice/blob/ecef1644222e59d0d76c008c538d20e3a8b2c8e2/WordPress/enabling_debug_logs_for_wordpress.md

SamRueby awesome, I tried multiple times to use the startup command to manipulate the container and it never worked like on the Azure Container Instances - thanks for the info

I am still running into a font loading issue as soon as I install the BuddyBoss theme (which is working on all systems I used before without any issue), so I expect an issue in the underlying default configuration of either nginx or php-fpm. Tried to debug, spot and fix it with MIME types, extensions and NGINX content security policy via SSH - but was unable to get it working so far. There's a lot of javascript used in that theme, but the CSS files and the fonts itself are hosted locally - so it is no CORS issue. I already opened a ticket with their support, and they were suspecting a CSS issue, but the CSS files itself are loading according to browser developer tools. As I am on a Visual Studio subscription here right now, I cannot open a ticket to Microsoft directly. In case someone who is more skilled would like to take a look at it with dev tools in the browser: https://blackrhinoteam.azurewebsites.net/wp-login.php should show icons based out of fonts from a CSS on the left inside the Email Address and the Password field. Any pointers to what could be the issue are welcome.

mpetz1495  It's failing because there's no reference to the font bb-icons. It's not even attempted to be loaded (as-opposed to trying and failing).

SamRueby That would mean that the issue is at least one level below with the CSS system - but why is it working on Apache and Caddy then without a problem? I cannot believe that this is a generic nginx-incompatibility.
I did a site migration of the site first and had that same issue with WPiA, so I retried with installing from scratch which lead to the same result. It is exactly the same theme on the same version. And I also got this issue with the BuddyBoss plugin and all icons showing up there on front end and back end (so it is not a pure theme issue and has for sure nothing to do with theme or plugin itself) - I have got that issue only when running Wordpress in Azure, again: also the plugin is working on Apache and Caddy for me without any issue. Besides a warning about a non-matching return type, which is could be suppressed with an attribute, the php-fpm.www.log does not contain anything, which matches my assumption that this problem is not php-interpreter related itself (Apache and Caddy were running with PHP 8.3 before, too).

Is there anything special on the WPiA security configuration that could prevent that? Maybe in NGINX?

I am seeing something different at step 2/3.  I don't see any of the detail under Stack settings you show above.