Author: benadams

How To: Installing WordPress for IIS7

So you fancy doing some blogging? How do you install WordPress for II7 and above? This should show you how to install WordPress in Internet Information Services 7.

First, fire up the Web Platform Installer as this is the easiest way to start. Choose the Applications tab and click “Add” next to WordPress:

Choosing WordPress in the Web Platform Installer
Choose WordPress in the Web Platform Installer

The click “Install”. If you are asked whether to install any extra needed components (e.g. PHP, MySQL etc.) – confirm this.

Choose to install MySQL locally

At the next screen choose to install MySQL locally; unless you are going to run it across multiple servers or have an install of MySQL you can use elsewhere.

Confirm install, with required components (e.g. PHP)

Confirm the install at the next screen. The little crosses threw me a bit, ticks might have been better…

Choose admin password for MySQL

At the next screen you need to create an Admin password for MySQL. Remember what you enter as this password as you will need it later – click continue.

Wait for install to complete

The install of all the various components, and any service packs etc. can take a little while so be patient…

You may have to restart a couple times

You may be asked to restart a couple times, depending on what bits needed to be installed. After a reboot, if the installation doesn’t continue straight away – just fire up the Web Platform Installer again and it will continue.

You may receive installation errors

If you receive any installation errors; check the logs, however this is likely to be from restarting at inappropriate times. Just reselect WordPress to install – your list of extra extensions should be shorter – and hopefully the install will now complete without errors.

Choose IIS website setup details (click for larger)

At the next screen you choose how your new WordPress site will be accessed from the internet (click to see larger version):

  • Website: Either Choose a “New Website” if you want it to go from the root of a domain or subdomain; or choose an existing site if you want it off a subdriectory.
  • ‘WordPress’ application name: Use / if you are creating a new website and want it in the root, else choose the subdirectory you want it accessed from the Internet at.
  • Web Site Name: This is the both the Application pool and the name of the Site in IIS Manager, unless you are creating a subdirectory – when it is just the name of the App Pool.
  • Physical path: This is the actual physical directory on disk where your WordPress files will be held.
  • IP Address: Unless you want WordPress to only respond on a particular IP address – just leave this as “All Unassigned”
  • Host Name: This is the actual domain that WordPress will respond to, so set it to the subdomain or domain you want to use e.g. blog.yoursite.com or www.myblog.com etc.

After filling in the details you want to use, click continue.

Enter the database login credentials you provided earlier (click for larger)

At the next screen you need to use the database password you entered earlier for the Database Administrator Password. Scrolling further down:

Enter details for a new user WordPress will use (click for larger)

Choose a database User Name and password for the install to create. Note: this is not the user name you will be using, but the user WordPress will use to connect to the database. If you installed the database locally, put localhost in for the Database Server.

Scrolling further down:

Add some strengthening phrases (click for larger)

Enter a database name to use, this could be the name of the blog or the website name you used earlier. Next you need to enter a set of Unique Key phrases. These are to strengthen the encryption for passwords and authentication. Go wild, you don’t need to remember these.

Click continue:

Installation complete, click launch WordPress

You’ve now installed WordPress and just need to do a final configuration step, so click the “Launch WordPress” link on this page.

Configure WordPress and setup new user (click for larger)

Now you just need to fill in a few more details on you new WordPress website.

  • Site Title: This is the title of you blog “My blog” or whatever you want it to be known as.
  • Username: This is the Username you will use to actually login to your WordPress site.
  • Password: Choose a password
  • Your E-mail: And enter your email address

Click install WordPress…

Congratulations! You should now how WordPress successfully installed and ready to use. Just log in at the next screen providing the login credentials you just supplied:

JavaScript: Don’t spam your server, Debounce and Throttle

If you make server call-backs or update the browser GUI based on user interaction you can end up doing far more updates than necessary…

In fact on one occasion, during Illyriad-beta testing, we started tripping our server’s dynamic IP request rate throttling and banning our own IP address – D’oh!

Common situations where over responding to events are mousemove, keypress, resize and scroll; but there are a whole host of situations where this applies.

We update our pages dynamically via ajax, based on user clicks around the user interface. In this situation if the user makes several page navigation requests in quick succession – the only important one to be made is the last, as for all the previous ones the data will be thrown away. So why make the requests in the first place? It’s just unnecessary server load.

Equally, if a user is moving an mouse around a map and you are updating UI coordinates for every pixel change the mouse makes, it potentially a huge number of DOM updates far beyond the perception of a user; for no real benefit, but it will cause a degradation in performance.

Initially, we controlled the situation using complex setups of setTimeout clearTimeout and setInterval. However, as the various places we made use of this became more varied, with different sets of needs, the code became more and more complex and difficult to maintain.

Luckily, it was around this time we discovered Ben Alman’s jQuery plugins debounce and throttle; which are extremely powerful – yet simple to use of and cover a whole host of permutations.

Throttling

Using his  jQuery $.throttle, you can pass a delay and function to $.throttle to get a new function, that when called repetitively, executes the original function no more than once every delay milliseconds.

Throttling can be especially useful for rate limiting execution of handlers on events like resize and scroll. Check out the example for jQuery throttling.

Debouncing

Using his jQuery $.debounce, you can pass a delay and function to $.debounce to get a new function, that when called repetitively, executes the original function just once per “bunch” of calls, effectively coalescing multiple sequential calls into a single execution at either the beginning or end.

Debouncing can be especially useful for rate limiting execution of handlers on events that will trigger AJAX requests. Check out the example for jQuery debouncing.

In fact its well worth checking out all Ben Alman’s jQuery Projects as they are full of little wonders, that you soon are sure how you did without them!

(Fix) Memory Leaks: Ajax page replacement

Resolving memory issues with HTML replacement and Ajax

In Illyriad we do very large numbers of ajax requests using jQuery over a players session. Some of these are pure data requests, but many of them are navigational HTML page replacements.

A simple replacement seems to leak memory in various browsers:

[code lang=”js”]
$(‘#ElementToReplaceContents’).html(htmlToReplaceWith);
[/code]

Even calling the jQuery function .empty() before the replacement doesn’t seem to help in all cases. To fix this we have created a clean up function which is a common or garden “overkill” variety which seems to do the trick. Usage below:

[code lang=”js”]
function ChangeLocationSucess(data, textStatus, XHR) {
if (XHR.status == 200) {
var div = $(‘#ElementToReplaceContents’);
DoUnload(); // More on this further down
div.RemoveChildrenFromDom(); // Clean up call
div.html(data); // HTML replacement
}
…
[/code]

Clearing the memory from the existing HTML is done with the clean up code below:

[code lang=”js” title=”Added: RemoveChildrenFromDom jQuery plugin”]
(function( $ ){
$.fn.RemoveChildrenFromDom = function (i) {
if (!this) return;
this.find(‘input[type="submit"]’).unbind(); // Unwire submit buttons
this.children()
.empty() // jQuery empty of children
.each(function (index, domEle) {
try { domEle.innerHTML = ""; } catch (e) {} // HTML child element clear
});
this.empty(); // jQuery Empty
try { this.get().innerHTML = ""; } catch (e) {} // HTML element clear
};
})( jQuery );
[/code]

Some pages have extra resources cached and extra elements with wired up events. For these we have introduced a DoUnload function which also gets called before the replacement. This runs through the list of on page clean up functions and calls them one by one:

[code lang=”js” title=”Extra clean up system”]
var unloadFuncs = [];
function DoUnload() {
while (unloadFuncs.length > 0) {
var f = unloadFuncs.pop();
f();
f = null;
}
}
[/code]

We create these unload functions on the page that has any extra clean up to do by using the following code; which adds clean up functions to the unloadFuncs array above. This code looks like the code below:

[code lang=”js” title=”On page clean up registration”]
var unload = function() {
OnPageCachedResources.clear(); // Clear array of cached resources
OnPageCachedResources = null;
$("#OnPageElementWithWiredUpEvents")
.unbind()
.undelegate(); // Remove attached events
}
unloadFuncs.push(unload);
[/code]

Obviously this varies from page to page and most of our pages don’t need it – at which point the DoUnload function just returns with out doing work.

This coupled with the Fix for IE and JQuery 1.4 Ajax deal with most of the regular unexpected leaks.

(As an aside: When replacing HTML with Ajax, do not wire up events using onclick=”” etc in the HTML or this will also leak. Use event binding from script – a third party library like jQuery, Prototype or Dojo will make this very straight forward)

Integration: Chrome Web Store

Publishing your web app on the Chrome Web Store is so straight forward, not doing so almost seems foolish!

Create a zip file containing a folder “chrome_app” and inside that two files:

  1. 128×128 png icon file
  2. manifest.json file
The manifest we use for Illyriad looks similar to this (make sure the icon field matches the name and case of the icon in the zip):

[code lang=”javascript” title=”manifest.json”]
{
"name": "Illyriad Test",
"description": "Real-time massively-multiplayer…",
"version": "1.0",
"app": {
"urls": [
"https://www.illyriad.co.uk/",
"https://uk1.illyriad.co.uk/",
"https://img3.illyriad.co.uk/",
"https://img4.illyriad.co.uk/",
"https://img5.illyriad.co.uk/",
"https://img6.illyriad.co.uk/"
],
"launch": {
"web_url": "https://www.illyriad.co.uk/loginOAuth.asp"
}
},
"icons": {
"128": "Logo-128.png"
},
"permissions": [
"unlimitedStorage",
"notifications"
]
}
[/code]

Your launch web_url should be either your login page, or if not required the main app page. If you do require a login page it’s also advisable to accept Google OpenId, at which point you can bypass the login page for CWS users who have a Google account and have approved you; but more on this in a later post.

To publish your app and access the developer dashboard a one-off developer registration fee of US$5.00 is required to verify your account, and presumably to cut down on spammers.

In the CWS developer dashboard click the Add new item button, which will take you to the upload app page:

Choose the zip file you created earlier and upload it:

Once you have uploaded your zip you will be taken to the Edit item page. First thing to do is upload the Icon you used in the zip file (unless you want a different icon in the Web Store to the one to be displayed in Chrome)

Now you’ll want to marketing materials. You can choose at the bottom of the page “Save draft and return to dashboard” if you don’t have these ready yet, so you can return to editing later. The items you’ll want are:

  1. A detailed description (Focus on explaining what the item does and why users should install it)
  2. Some screenshots (400 x 275 pixels or proportionally larger)
  3. (Optional) A YouTube video
  4. (Optional) A background image to show on your app page
  5. (Optional) 2 promotional images

After adding these on the edit item page, choose a category to publish in and then click “Preview changes” to see what your item will look like. If you like it hit publish, else return to editing. At this point you are published! Easy!

There is lots more you can do, of course, you can publish to test users first, use a verified website,  change your pricing – your apps don’t have to be free, you can change the pricing and also sell apps from the Web Store – it is a store after all! But this should get you on your way…

(Fix) Memory Leaks: IE and JQuery 1.4 Ajax

While testing Illyriad we found that over time the browsers IE7 and IE8 leak memory on Ajax calls using JQuery 1.4.

If you make a lot of ajax calls without changing page this can build up quite quickly and start causing issues. This is caused by the onreadystatechange event not being detached and IE not garbage-collecting the associated memory.

To fix this, locate these lines in the source JQuery file; already kindly annotated with “Stop memory leaks”:

[code lang=”js” firstline=”6019″ title=”Original jquery-1.4.4.js”]
// Stop memory leaks
if ( s.async ) {
xhr = null;
}
[/code]

Add in these extra lines to change them to the following (we detach the abort event also for good measure):

[code lang=”js” firstline=”6019″ title=”Modified jquery-1.4.4.js”]
// Stop memory leaks
if ( s.async ) {
try {
xhr.onreadystatechange = null;
xhr.abort = null;
} catch (ex) { };
xhr = null;
}
[/code]

Don’t forget to minify your jquery file before including it. [We prefer using UglifyJS]

Also rename it slightly so users with cached versions pick up the new file

e.g. jquery-1.4.4a-min.js

(Fix) Javascript: Avoiding “console is undefined”

Testing if a function or object is defined can sometimes cause as many errors as not doing so. What to do?

When developing JavaScript using either Firebug in Firefox or Chrome’s built-in console you will probably at some point be using console.log either for debugging messages or for exception information.

However, when you come to run this code in Internet Explorer, it throws an exception “console is undefined”:

[code lang=”javascript”]
try {
… // code throwing error
} catch (e) {
console.log(e); // throws script error "console is undefined"
}
[/code]

“A-ha” you think; “easily solved will just test if its defined before use”. However things are not so straight forward:

[code lang=”javascript”]
try {
… // code throwing error
} catch (e) {
if (console && console.log) // throws script error "console is undefined"
console.log(e);
}
[/code]

Even though now you are testing to see if it exists before use, you still get:

Console is undefined

While this would normally work for attributes of objects, globally scoped variables work differently. Luckily, all variables in global scope will be declared as attributes on the global window variable. This enables you to test for existence on the window.

Here we’ve wrapped the test up in a LogException function to ease changing of logging methodologies:

[code lang=”javascript”]
function LogException(e) {
if (window.console // check for window.console not console
&& window.console.log) window.console.log(e);
// Other logging here
}

try {
… // code throwing error
} catch (e) {
LogException(e); // works fine
}
[/code]

Note: Its isn’t exclusive to Internet Explorer, it just most visible there; so checking existence of globally scoped functions and variables against window rather than just by name is good practice!