When upgrading WordPress core, theme, language or plugin – the update downloads successfully but leaves a blank upgrade screen, the page stops loading, you may be stuck in maintenance mode (requiring manual removal of .maintenance) and overall the upgrade never completes.
- Using WordPress version 4.x
- Accessing the WordPress site via HTTP (not HTTPS)
- When upgrading, I saw WordPress downloaded the zip file via HTTPS
- Using WordPress.com Jetpack (not sure if related or not)
- Google returns very few results describing the problem well.
I’ve tested this against four WordPress sites now and it appears to have successfully worked around the problem.
I installed a self-signed SSL certificate against the WordPress site using Server Name Indicator (SNI). Remember no dedicated IP is required when using SNI but it need a compatible server. For convenience I’ve used SSL certificates from tinycert.org.
Now when I access the site over HTTPS:
- Login again – note SSO with untrusted certificate will not work, you must use local site login credentials
- Perform the upgrade – it completes successfully and does not result in a blank or stalled upgraded screen.
Do you see another pattern? Isolated it to a version, Jetpack or another update? Please let me know!
Other Possible Causes
The above resolved my issue, but similar issues include:
Most sysadmins by now have experienced “the cloud” and all the cost cutting fun that comes with it. My colleagues and I primarily work with Microsoft Azure.
While the Azure portal has improved, we’ve found numerous circumstances where improvement is still needed.
One example, when dealing with a handful of subscriptions attached to the same login account, packed with large number of items – everything slows down on first load. I’m not sure if it’s related, but usually the category you need to get access to immediately is the last to load.
The return times on actions like creating a new storage account can vary from 10 seconds to 3 minutes – not just via the portal but when using Powershell and the Management API.
These and some other painfully slow circumstances, have resulted in a common phrase emerging around the office: “I’m waiting for Azure”. While waiting for Azure, a colleague and good friend of mine had the time to create the following diagram for laughs. Enjoy.
Time spent waiting for Azure
I got a request to look into the question, how do I delete temporary ASP.NET files on a shared Windows hosting server and I’ve decided to take a look into it.
Unless you have access to the global temp used by the server – which any good sysadmin will not allow – you can’t clear the global temp. However what you can do is change the temporary directory path used by your application.
The web.config file allows you to make application specific configuration changes, including the .NET temp file path. You can instead change the path to a location you do control.
How? Using the compilation Element, but more specifically the tempDirectory attribute. This attribute has existed since .NET 1.1, so it will work on all .NET version from 1.1 through to at least .NET 4.
<compilation tempDirectory=”D:\userdata\client224\temp” />
This is important! Remember to correctly set NTFS and/or share permissions on the new tempDirectory location else your application will not compile. You’ll need to apply read/write (modify) permissions to the folder using the application pool identity. This identity may be a system user like NETWORKSERVICE, IIS AppPool\AppPoolNameHere or another custom identity. For more on application pool identities, check the official documentation.
It’s reasonable for Windows shared hosting providers to want to disable this ability – I would – but I’ve not read any instances of it happening yet.
Best of luck!