Having to host, upgrade and manage WordPress is not really my main job. The various posts over the years will provide a small clue that other things take up most of my time and are my day job. Life was certainly easier when TechNet was still around as a dedicated team ran the MSDN and TechNet blog platforms and provided all of the infrastructure support. All I had to do was write the posts.
Alas TechNet was made to go the way of the dinosaurs and was forced into extinction. The blogs and forums met a similar fate since they were all branded with those monikers. As noted previously either the blog would be moved to a rather useless archive or I had the option of exporting the content to host it myself elsewhere. I went for option #2.
This resulted in a few different hosting iterations over the years. If we include the intial TechNet days:
- TechNet blog on Community Server
- Technet blog on WordPress
- WordPress running in Azure Windows Container
-
WordPress running in Azure Linux Container
-
WordPress running on Ubuntu Linux VM
TechNet Blog on Community Server
This was a Windows based hosting offering which explains why the original permalinks had the .aspx file extension. There were actually a few different iterations of this platform, with one migration adding the horrid "/b" element to the URL.
TechNet Blog on WordPress
The content was moved over by the TechNet support team and this flavour of the blog went live in March 2016 on the new platform.
Despite this brand new infrastructure, the whole platform was soon slated for retirement. Many blogs were moved to the read only archive, with some official ones moving to TechCommunities.
WordPress running in Azure Windows Container
The initial export of the TechNet content was imported into this instance. The configuration was updated and DNS was updated to the new instance, going live in March 2020.
Performance was OK due to the container's ability to cache file system content. PHP was running on Windows which is not ideal, but due to only moderate load it performed well.
However, Azure will stop supporting PHP on Windows containers. That meant a migration. Yay!
If you are currently targeting Windows for PHP development, we advise to plan for migrating development to target Linux. After November 28 2022, Linux will be the only OS supported by future versions of PHP and continued feature, quality and security updates.
WordPress Running in Azure Linux Container
So I moved to an Azure Linux container.
There is where the problems started. The initial migration and content import went as planned due to WordPress being very flexible, no issues there.
The regular WordPress app service was selected.
Performance from day 1 was terrible. Page load times dramatically increased. The time taken to edit posts and update content was very painful. Some of the regular WordPress admin pages would take 30 – 45 seconds to load just that one page.
Many, Many, Many things were tried and changes made with little to no improvement. There are some good articles to help with performance, but fundamentally it did not remediate the underlying performance issue. The most visible change was using a cache plugin to help mask some of the underlying performance issues. That helped slightly with serving pages, but when logged in the same 30 – 45 seconds page load in the admin portal issue was still present. But when one of the suggestions is to use REDIS DB cache for a site of this nature, that makes you go hmmmmm. The cost of that service is flat out rediculous for what this blog really needs.
CHMOD Denied
The final issue was being blocked from managing permissions due to the Linux container. The below error was noted in FileZilla when trying to change the permissions – note that the error says that the CHMOD command is not understood. This is NOT an issue with FileZilla, this is due to the Linux container architecture.
The error text for benefit of the search engines.
Command: SITE CHMOD 754 tmp
Response: 500 'SITE': command not understood
The full error text:
rename(/home/site/wwwroot/wp-content/wflogs/config.tmp.kAAFED,/home/site/wwwroot/wp-content/wflogs/config-synced.php): Permission denied File: /home/site/wwwroot/wp-content/plugins/wordfence/vendor/wordfence/wf-waf/src/lib/storage/file.php Line: 70
Why was I trying to change the permissions? For the issue noted below.
Wordfence WAF Denied
Other issues were noted with some of the more advanced WordPress plugins. For example WordFence. This is an amazing security tool that provides Web Application Firewall (WAF), MFA and application security insight.
Wordfence was unable to update itself inside the Linux container and would report errors such as these in the Wordfence log:
Sep 21 09:31:43:1663767103.755881:1:error] rename(/home/site/wwwroot/wp-content/wflogs/config.tmp.JhcBJC,/home/site/wwwroot/wp-content/wflogs/config-synced.php): Permission denied (2) File: /home/site/wwwroot/wp-content/plugins/wordfence/vendor/wordfence/wf-waf/src/lib/storage/file.php Line: 70
[Sep 21 09:31:43:1663767103.737508:1:error] rename(/home/site/wwwroot/wp-content/wflogs/config-synced.php,/home/site/wwwroot/wp-content/wflogs/config.bak.NgpHHK): No such file or directory (2) File: /home/site/wwwroot/wp-content/plugins/wordfence/vendor/wordfence/wf-waf/src/lib/storage/file.php Line: 69
[Sep 21 09:31:43:1663767103.720429:1:error] rename(/home/site/wwwroot/wp-content/wflogs/config.tmp.JhcBJC,/home/site/wwwroot/wp-content/wflogs/config-synced.php): Permission denied (2) File: /home/site/wwwroot/wp-content/plugins/wordfence/vendor/wordfence/wf-waf/src/lib/storage/file.php Line: 55
In the WordPress admin site WordFence also reported that the WAF could not run as it could not access the configuration files. This is the error reported:
The Wordfence Web Application Firewall cannot run. The configuration files are corrupt or inaccessible by the web server, which is preventing the WAF from functioning. Please verify the web server has permission to access the configuration files. You may also try to rebuild the configuration file by clicking here. It will automatically resume normal operation when it is fixed. (opens in new tab):
Link goes to: Troubleshooting – Wordfence.
There are a handful of related posts, but no real resolution due to the underlying architecture. Take a look at the links below for some reading on how the Linux container operates and generates the file system that is visible to WordPress.
Understanding the Azure App Service file system
Maybe most importantly, this note:
We are done here. No more Windows Containers due to end of support. No more Linux containers due to terrible performance.
Time to go native.
WordPress running on Linux VM
Since Windows Containers will no longer support PHP, and the poor performance on the Linux Container the blog was moved to a regular Ubuntu VM. Nothing fancy. Just a small B series VM with no bells and whistles.
WordPress yet again made the migration of the database and content easy. Performance on the new VM is excellent, and the issues with Wordfence are fully resolved as it is able to function as designed.
Page load times are heavily monitored by search engines, and the previous decreased performance had impacted the page ranking. The indexes are slowing ranking back up and will hopefully improve over time.
Cheers,
Rhoderick
