Google analytics is brilliant, of that there is no doubt, and it has replaced website stats for many people these days, however applying it  to your entire site can be a pain if you have a large site and do not have a modern CMS system that allows you to easily insert scripts onto every page.

This can create a dilemma if you want to do away with website stats entirely and encourage customers to use Google analytics instead, but many customers have old legacy sites and do not have the required skills (or inclination) to do the required work, so I started looking for a way that Google analytics could be easily and automatically added to a customers site without making code changes.
Being a windows/IIS guy I first looked into using the URL rewrite engine, which allows you to create OUTGOING rules to rewrite content before it is delivered to the client, and it turned out this did the job nicely, although with the caveat that you cannot just insert raw JavaScript as some characters break the URL rewriting engine, so you have to do a bit of manipulation to get things working.

Basically you have to remove all newline characters and encode any {curly braces} as these have special meaning in url rewriting.
I actually solved this back in 2012, but it has sat unused until now as I still needed an easy way for non technical customers to do this and apply it to their websites. Well today I was having my first play with JSFiddle.net (as some have suggested I do something similar for cflive.net) and decided to do something constructive and throw together a quick script to generate the required rewrite rule to do the above, and here it is.
It is very small and very simple, but I hope useful script that will convert your analytics code into the required format and also generate the rewrite rule for you to insert into your web.config file. Just click the Result tab below to actually use the script.

Whether you are using a CMS or blogging app such as WordPress, Joomla, Drupal, or even a custom built app, then you likely have an admin system to manage your website and its content.

The problem is that hackers know this too, and they know that in most cases your admin will reside in www.yoursite.com/admin and they regularly try to hack this URL with brute force password attacks or a bit of SQL injection, and unless you have any logs you regularly monitor or a failed login notification system, then you will be completely oblivious to this, many people get hacked and do not realise until months later that malware has been inserted into their site and is trying to infect all their website visitors, and worse that their site has been blacklisted/blocked as a malware site or that all their customer data has also been stolen.

Now at least with off the shelf open source apps like Wordpress et al you have the advantage that you can easily update to the latest version and thus plug any known security issues or vulnerabilities that arise, but with a custom built app you do not have this luxury and you will remain oblivious of any security holes in your app until it is too late.

The best solution is to add IP address restrictions to your admin folder so that only authorised people can access it.

With Apache

How to do this with apache is pretty common knowledge, you simply use your .htaccess file, so I wont bother covering that here, for those that do not know here are a couple of links showing you how to get it done.

• How to deny visitors by IP address using Apache : http://www.htaccess-guide.com/deny-visitors-by-ip-address/
• .htaccess generator : http://www.toshop.com/htaccess-generator.cfm

With Microsoft IIS

However doing this with Microsoft IIS is less common knowledge and if you are on shared hosting you likely have no idea how to do it at all and probably do not have access either.

By default on IIS, IP Address restrictions must be done via the IIS Management interface, and you need to install the "IP Security" feature, instructions on how to do that can be found HERE, if you are on a shared host you may need to ask them if they have this installed, and if not ask them to install it.
But even with this installed you are still restricted to doing the IP Address restrictions via the MMC (see previous link), which means you need direct access to the server, and one thing this lacks is the ability to add comments to specify who the IP address belongs to, which is very important if you want to allow an IP address temporarily or want to keep track what who each IP belongs to.

What you really want to do is be able to add these IP restrictions in your web.config, so you can also add comments next to each entry and so that you do not have to login to the server and use the MMC, ala apache .htaccess style.
The good news is that you can do this, all you have to do is enable IPSecurity override in your ApplicationHost.config. For those that do not know, ApplicationHost.config is where IIS stores its global settings (such as default documents and handlers) and those which are not managed via the web.config by default.

To edit this file go to C:\Windows\System32\inetsrv\config and open applicationhost.config in your favourite text editor.

NOTE:

You need to be using a 64bit text editor on a 64bit OS otherwise it will not be able to open the 64bit version of this file, and instead opens an alternate version of this file, which is not the one in use. I discovered this after many hours of head scratching as I always used Notepad++ by default, which is only a 32bit editor.

Now find the following section:-

<section name="ipSecurity" overrideModeDefault="Deny" />

And change the "Deny" to "Allow". If you are on a shared host, you will need to ask them to make this change, there is really no reason for them to not allow this.

You can now use your web.config file to manage IP address restrictions.

How it's done
Example IP address restrictions. Comments are enclosed in <!-- --> and are not required, but I suggest you use them to record what IP is there for what reason.

• Allow all, but block specific IPs or networks
  

  <security>
     <ipSecurity allowUnlisted="true">    <!-- this line allows everybody, except those listed below -->            
         <clear/>     <!—removes all parent restrictions -->                
         <add ipAddress="83.116.19.53"/>     <!-- blocks the specific IP of 83.116.19.53  -->                
         <add ipAddress="83.116.119.0" subnetMask="255.255.255.0"/>     <!--blocks network 83.116.119.0 to 83.116.119.255-->                
         <add ipAddress="83.116.0.0" subnetMask="255.255.0.0"/>     <!--blocks network 83.116.0.0 to 83.116.255.255-->                
         <add ipAddress="83.0.0.0" subnetMask="255.0.0.0"/>     <!--blocks entire /8 network of 83.0.0.0 to 83.255.255.255-->                
     </ipSecurity>
  </security>

• Deny all, but allow specific IPs or networks

  <security>
      <ipSecurity allowUnlisted="false">    <!-- this line blocks everybody, except those listed below -->                
          <clear/> <!—removes all parent restrictions -->
          <add ipAddress="127.0.0.1" allowed="true"/>    <!-- allow requests from the local machine -->
          <add ipAddress="83.116.19.53" allowed="true"/>   <!-- allow the specific IP of 83.116.19.53  -->                
          <add ipAddress="83.116.119.0" subnetMask="255.255.255.0" allowed="true"/>   <!--allow network 83.116.119.0 to 83.116.119.255-->                
          <add ipAddress="83.116.0.0" subnetMask="255.255.0.0" allowed="true"/>   <!--allow network 83.116.0.0 to 83.116.255.255-->                
          <add ipAddress="83.0.0.0" subnetMask="255.0.0.0" allowed="true"/>   <!--allow entire /8 network of 83.0.0.0 to 83.255.255.255-->                
      </ipSecurity>
  </security>

• Use a text editor to create a file named web.config
• Save the web.config file with the appropriate content
• Place the web.config file in the directory that you wish to protect

• If there isn't an existing web.config in the directory, your new web.config should look something like this

  <?xml version="1.0"?>
  <configuration>
     <system.webServer>
        <security>
          <ipSecurity allowUnlisted="true">    <!-- this line blocks everybody, except those listed below -->                
             <clear/> <!—removes all parent restrictions -->
             <add ipAddress="83.116.19.53"/>   <!-- block one IP  -->                
             <add ipAddress="83.116.119.0" subnetMask="255.255.255.0"/>   <!--block network 83.116.119.0 to 83.116.119.255-->               
          </ipSecurity>
        </security>
     </system.webServer>
  </configuration>

• If there is an existing web config, without a <system.webServer> section... Your new web.config should look like this

  <?xml version="1.0"?>
  <configuration>
     <system.web>
       .. existing text ..
       .. existing text ..
     </system.web>
     <system.webServer>
        <security>
          <ipSecurity allowUnlisted="true">    <!-- this line blocks everybody, except those listed below -->                
             <clear/> <!—removes all parent restrictions -->
             <add ipAddress="83.116.19.53"/>   <!-- block one IP  -->                
             <add ipAddress="83.116.119.0" subnetMask="255.255.255.0"/>   <!--block network 83.116.119.0 to 83.116.119.255-->               
          </ipSecurity>
        </security>
     </system.webServer>
  </configuration>

• If your existing web.config already has a <system.webServer> section, just add the <security><ipSecurity> section

  <?xml version="1.0"?>
  <configuration>
     <system.web>
       .. existing text ..
       .. existing text ..
     </system.web>
     <system.webServer>
        <security>
          <ipSecurity allowUnlisted="true">    <!-- this line blocks everybody, except those listed below -->                
             <clear/> <!—removes all parent restrictions -->
             <add ipAddress="83.116.19.53"/>   <!-- block one IP  -->                
             <add ipAddress="83.116.119.0" subnetMask="255.255.255.0"/>   <!--block network 83.116.119.0 to 83.116.119.255-->               
          </ipSecurity>
        </security>
     </system.webServer>
  </configuration>

By default when you install MySQL it stores databases on the C drive, you can change this during installation but perhaps you forgot to change the data files path during installation or completely missed the option to do this, or perhaps you used the Web Platform Installer which doesn't give you any option to change the data files path.

On windows 2008 the datadir is “C:\ProgramData\MySQL\MySQL Server 5.5\data”

This is generally not the best idea as your c drive should be only for the OS and installed programs, you should put all your data on a different drive and keep it separate from the OS. So if you find yourself needing to change this after installation, here is how.

Open your my.ini file

On windows 2008 this is in C:\ProgramData\MySQL\MySQL Server 5.5\”

On other windows version just look at the mysql service properties to find out where the defaults-file is.

now find the “datadir” parameter and change it to where you want to store your databases.

E.G.
datadir="D:\MySQL\data\"

Now STOP the MySQL service.

Now you must copy the original data directory to the new location.

E.G.
copy “C:\ProgramData\MySQL\MySQL Server 5.5\data” to “D:\mysql\data”

now restart MySQL.

If the service fails to start, double check that you have entered the path correctly in my.ini and that the path exists, and that all the data files have copied across properly.

Check your new data folder permissions and make sure it has “NETWORK SERVICE” with full permissions. On Windows 2008 these permissions may not exist by default.

If you are running windows 2008 server with IIS 7 then you may have noticed a problem with your PHP apps such as Wordpress or Joomla when you try to perform updates.

The problem occurs when the old files are deleted, the delete fails to complete leaving the files/folders in a locked state and you are then unable to do anything with them at all.

this problem has been plaguing me fore a few months and solution has been to use a file unlocker tool to release the lock.

I have recently found the cause for this to be the Wincache extension for PHP, you can find more details and a fix HERE.

I run numerous blogs, one of which is Wordpress, and I prefer to post to them using Windows Live Writer.

However after a recent update to Wordpress I found I could no longer post with Live Writer or even connect at all in any way, I would get the following error.

the response to the blogger.getUsersBlogs method received from the blog server was invalid

I spent ages Googling for a solution to no avail, but the general consensus is that the problem is caused by an extraneous space or newline in one of the PHP files outside of the <?PHP> tags. I searched all of the suggested files to no avail. So I decided to try and work out the cause myself.

I use a tool called Fiddler to monitor HTTP traffic to and from my computer, so I used this to look at the request and response going from Live Writer to Wordpress.

So with fiddler running I tried to update my account settings, this returns the entire HTML of the entire blog, so is not helpful in determining the cause of the problem, next I tried making a post instead, this returned something more useful and showed me the cause of the problem. To do this yourself, try to post to your blog and then check the result in fiddler in the Inspectors/TextView tabs.

Here is the response that came back from wordpress.

<?xml version="1.0"?>

<methodResponse>

  <params>

    <param>

      <value>

      <array><data>

        <value><struct>

          <member><name>isAdmin</name><value><boolean>1</boolean></value></member>

          <member><name>url</name><value><string>http://blog.bluethunder.co/</string></value></member>

          <member><name>blogid</name><value><string>1</string></value></member>

          <member><name>blogName</name><value><string>BlueThunder Blog</string></value></member>

         <member><name>xmlrpc</name><value><string>http://blog.bluethunder.co/xmlrpc.php</string></value></member>

       </struct></value>

      </data></array>

      </value>

    </param>

  </params>

</methodRespons
 

As you can see the final tag is not closed properly, it is missing 2 characters "e>".

So it would appear that indeed some extraneous characters are indeed being added somewhere which means that the content is not matching the content length, so I decided to see if there was anyway I hack a fix for this as finding these extraneous characters was clearly impossible.

After a lot of searching I finally found a solution.

In the wp-includes folder there is a file called class-IXR.php, and around line 472 you will find the following code which sets the content length.

now as the content is 2 characters shorter than it should be, we want to add 2 to this by changing the highlighted line like so.

header('Content-Length: '.$length+2);

If your content is missing more than 2 characters then add the appropriate value.

Voila, my Live Writer is now able to post to Wordpress again.