Tag Archives: IIS

UrlRewrite: SSL for Free Manual Verification Rule

Leave a Reply

2017 has really been the year when SSL implementation on websites has taken off. Google’s near requirement of them for SEO has forced many websites to implement some form of SSL certificate. For small personal or business, the biggest blocker for SSL hasn’t been the actual installation but the cost. Although prices have fallen, some website owners still resist forking out £30 for an SSL certificate especially if their site doesn’t actually process sensitive data.

Thankfully, SSL For Free has stepped into the fray providing free SSL certificates from the LetsEncrypt Certificate Authority.

To obtain a certificate from SSL for Free, it is necessary to verify your domain. You can do this either via FTP, DNS or manual verification. I often go the manual verification route as I find it to be faster and simpler to accomplish.

With manual verification, it necessary to download a small file to your website which SSLforFree looks for. If your site is already running in SSL and/or only accepts SSL requests, manual verification will fail as it would appear that SSLForFree only checks for the file via HTTP.

To avoid messing with IIS configuration, the simplest away around this is to use a UrlRewrite rule that acts as a pass through for verification requests:

[cc lang=”xml”]







[/cc]

If you are using this rule in conjunction with an HTTP to HTTPS rule (see earlier post), it should be placed before any such rule as manual verification is done through a HTTP request.

Automated Implemention
As side note, users of the SolidCP hosting control panel – as Calzada Media are – can install LetsEncrypt certificates through the hosting control panel. Once issued, SolidCP should automatically renew the certificates every 2 months. A short step-by-step guide on how to install the certificate can be found here.

URLRewrite : HTTP to HTTPS Rule

1 Reply

A quick rule to use with IIS UrlRewrite to redirect all HTTP requests to their HTTPS equivalent.

[cc lang=”xml”]








[/cc]

This rule only does a straight redirect i.e. http://mydomain.com to https://mydomain.com

Update 28 Nov 2017
Rule updated to fix some occasional issues experienced with live sites. The revised rule has been used successfully with a number of sites for a couple of weeks now.

Uploading files in WordPress on IIS – WTF moment.

Leave a Reply

There are whole slew of blog posts and technical articles on configuring IIS and windows permissions to enable file uploads in WordPress sites. I’ve read them before and had cause to re-visit them over the last couple of days as I struggled to get uploads working on this site. Whenever I attempt to upload a file, the site would just site their until an HTTP timeout message appeared. No HTTP 500, just a PHP timeout error.

My IIS and folder permissions were correct as were all the paths in php.ini. As I was testing tweaks or configuration changes, I could see the temporary files being written in the PHP temp folder. In other words, the actual PHP upload was working. Something was blocking the copying of these files to the WordPress site. Was it WordPress itself or a Windows permission?

To compound my confusion, WordPress’ own update functionality was working without a hitch, so this meant the site had the correct write permissions at least on the wp-content folder.

After several hours of fustration I found the problem and it wasn’t with IIS, PHP or Windows. It was with a WordPress setting. I eventually wandered over to WordPress’ Settings > Media and the uploads folder path contained a reference to a W drive. I have absolutely no idea where this has come from. This site has never been on a server with a W drive. However, once set back to the default of wp-content/uploads, file uploads worked again.

IIS FastCGI Fatal Error: Allocated memory size exhausted

Leave a Reply

Traditionally IIS and PHP have not mixed particularly well.  Things have gotten a lot better since the arrival of FastCGI and the Web Platform Installer, but there are still occasions when something occurs which flummoxes an ASP.Net guy like myself.

I recently moved this blog onto a Windows 2008 R2 server running IIS 7.5.  I’ll admit that I wasn’t really expecting any problems as I had already moved a MyBB forum onto the same server without any problems.  My normal level of IT paranoia had taken a leave of absence as I made the assumption that MyBB would be a far more demanding PHP application than WordPress, so there shouldn’t be any issues.

You know what they say about assumptions?  After all the data and files had been migrated I fired up my browser and initially got a blank page in return.  By default, FastCGI PHP does not return error messages – it is after all running on a production server.  So I dropped the following code into the top of the wp-config.php to manually enable errors.

ini_set('display_errors',true);

This duly returned the following error message:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 261904 bytes) in C:\inetpub\HostingSpaces\alexanderjohn\alexanderjohn.co.uk\wwwroot\wp-includes\functions.php on line 2109

Now, any quick Google search on this will immediately return a series of results all recommending the solution being to increase the memory_limit value in the php.ini from 128MB as the likely source is probably memory leaks in PHP.  This did seem a little counter intuitive – does WordPress really need that much memory?  I duly increase it several times, and each time I got a variation on the above error – all that changed was the Allowed memory size value increased to match the memory_limit value.

My next step was to check the various application pool settings.  They were all fine, and the site still refused to work with a new, dedicated pool.

Realistically, this only left WordPress as the culprit.  I duly downloaded the latest version and performed a manual upgrade.  Still no luck.

I then stripped out all the additional plugins and themes that were installed, and Hey Presto!, there was life.

I don’t know which plugin caused the problem as I have taken this opportunity to re-evaluate every plugin I was using.  This is something that I hadn’t done in a while, and to be honest, was well overdue.

As for the root core cause.  I would suspect that this down to some form of infinite loop.  If it is so, I am amazed that some developers are still adding iterations without some form of safety net.  At Calzada, it is actually part of our coding practice that any loop that has the potential of going infinite has some form of safety net.  At the end of the day, it is very hard to look professional to a customer when a product fails because of a very simple coding error.