Error in URL Rewrite Rules for WordPress 4.6.1 Multi-site Configuration

Yesterday, one of our customers asked for help troubleshooting a 404 error he was getting every time he tried to access the dashboard (admin interface) of any sub-site he created and wondered if there was anything that needed to be changed server side to get it to work.   I informed him that if he followed the instructions on WordPress’ Official Site, it should work without additional intervention from us.  I was partially correct.  Since I’ve never configured a WordPress Multi-site before, I spent more than a couple of hours going through the steps myself and indeed ran into the same problem that our customer experienced.  I then scoured the web for a solution and knew it had something to do with the URL Rewrite rules but was unable to figure out a solution.  Fortunately, our customer was able to find the solution himself which I will now share with you.

On line 24 (WordPress Rule 4) of the web.config markup that WordPress gives you when you click on the Network Setup link under Settings, it reads:

<action type=”Rewrite” url=”{R:1}” />

It needs to be changed to:

<action type=”Rewrite” url=”{R:2}” />

Many thanks to Lucas Nieboer for pointing out the solution!

The .htaccess File is Useful in a Windows Hosting Environment

There is a misconception about the .htacces file and its usefulness in a Windows hosting environment.  Normally, this is the file that controls the configuration settings for Linux/UNIX/Apache hosting environments, and its Window’s equivalent is the web.config file.  I finally found a use for it the other day, and it’s with WordPress itself.  Unfortunately, I didn’t have time to blog about it when I found the fix, and it seems that I am unable to reproduce the problem.  But I wanted to at least write about the events that led up to the problem and what I did to fix it to hopefully help reduce the frustration for someone else encountering the same issue.  This site is about troubleshooting computer problems after all.  And who knows?  That someone might be me again after a few months as it’s getting harder to remember things as I age.

The problem was created when I tried to transfer WordPress from one Windows hosting provider to another.  Of course, I know each hosting provider is configured differently, and I was running into errors during the move.  I finally isolated it to a problem with URL Rewrite.  Apparently, the other hosting provider disabled delegation for URL Rewrite, so it broke a lot of my WordPress links.  After scouring the Internet, I found the solution, and WordPress will actually tell you the solution.  You just need to click on Settings and Permalinks.  WordPress will throw some PHP errors, but I never noticed that way at the bottom, it tells you that you need to include some code in the .htaccess file.  Basically, it’s to include the mod_rewrite (Linux/UNIX/Apache’s equivalent for IIS’ URL Rewrite) rules.  Normally, WordPress will look at the web.config file for rewrite rules in a WIndows environment, but since the hosting provider disabled delegation for it, IIS would error out.  This means I couldn’t use them.  But once I created an .htaccess file with the mod_rewrite rules and uploaded it, my links started working again.  It’s good to know that WordPress will look at the .htaccess file for configuration information if it cannot find it in the web.config file.  And I believe here’s the code that you need to add to the .htaccess file to get everything working again:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

My Two Cents on Where to Add Google Analytics in WordPress Part II

In my previous article, I gave my two cents on where you should add the Google Analytics code in WordPress. After fiddling around trying to optimize another site of mine’s, I discovered that this will probably do little to help improve page speed. It does delay the parsing of JavaScript since the client browser reads the HTTP GET request line by line, and it’s at the end, but the effect is probably minimal. I did discover that I could use the script defer attribute to delay the processing, and it had a greater impact. Even though the HTML5 specifications indicate that it should not be used without the src attribute, I tried it, and it appeared to have a greater effect, at least in Chrome. (I know that it may not work with all browsers because each browser will implement it differently.) I can at least say it did solve some problem with my webpages rendering correctly after I redesigned them using Responsive Design, so you might want to consider giving it a try.