Pages

Thursday 28 July 2011

PHP 5.2 ISAPI to PHP 5.3 FastCGI

If like me it took you a little while to move from ISAPI with IIS to using FastCGI then fear not, you aren't alone.  Being honest, ISAPI with IIS went very well together as it was fast and very easy to setup.  Future versions of PHP no longer support ISAPI as of version 5.3, so you may as well make the move sooner rather than later.

So what do you need to do?  Well, firstly, download the latest build of PHP for your system (download the NTS version, which is the non-thread safe version).  Extract it somewhere on your system i.e. c:\PHP or wherever you mostly feel comfortable.  Next, assuming that you are using either Windows Server 2008 or 2008 r2, go to your Server Manager console, and then click 'Roles' on the right.  Next, click the link on the left named 'Add role services' under the Web Server (IIS) heading. This is assuming that you have IIS already setup on your server, otherwise you will need to add this as a role to your server. Drop down the 'Application Development' box and check the 'CGI' box as shown below.

As you can see, I still have my ISAPI extensions still in there but we can remove those later as we won't be needing them.  Click 'Next' and then let Windows go off and do its own thing.

Ok, your PHP config.  Do what you would normally do here.  In addition to your normal PHP config which can mostly be copied from your old PHP 5.2 config you will need to change the following:
  • cgi.fix_pathinfo=1
  • fastcgi.impersonate = 1
  • cgi.force_redirect = 0
  • extension_dir = 'c:\PHP\ext' *or where you have your PHP extension folder*
  • open_basedir = *location of your wwwroot folder typically*
Don't forget to change those asterisk comments to real values!  Ok, next back over to IIS, so open your IIS Manager.

Click on your server on the left hand side.  In the central pane will be an icon called 'Handler Mappings'.  Click on that, and then go to 'Add module mapping' in the right hand pane.  Fill in the following details and click 'OK', and then 'Yes' in the popup box when you are finished:
  • Request path: *.php
  • Module: FastCgiModule
  • Executable: *Link this to your PHP folder and then your php-cgi.exe file*
  • Name: PHP FastCGI
Next, you will need to do is go back to your server on the left hand side and then click 'FastCGI settings'.  When you get there, click the PHP entry in the middle, and then click 'Edit...' on the right.  Change the InstanceMaxRequests to 10000, and then click on the '...' button under 'EnvironmentVariables'.  Add an entry of PHP_FCGI_MAX_REQUESTS with a value of 10000, and then click 'OK'.  If you don't do these steps, IIS uses its default settings of 200 instanceMaxRequests and 500 PHP_FCGI_MAX_REQUESTS.

Nearly there now.  Make yourself that old PHP test file with the following information: <?php phpinfo(); ?> and see if it runs.  Chances are if you are on a 64 bit system this will have failed unless you tell IIS to use 32-bit applications.  To change this, go to the Application Pools, and then go to your website in the central pane.  Click 'Advanced settings' and then a popup box will appear.  Change the 'Enable 32-bit applications' entry to 'True'.

Assuming that you have set up the rest of your php.ini correctly, it's a case of job done for now!

Tuesday 26 July 2011

Mobile Firefox on the Way

Following on nicely from my post a few moments ago, Mozilla have just announced that they are starting working on a mobile version of its popular desktop browser.

You have to feel for Mozilla at the moment as things aren't exactly going brilliantly.  When I say this, I mean it with a pinch of salt.  You will always have those people out there who love Firefox and those who swear that it is the best thing since sliced bread but, and this is a big but, they really must be feeling that they are out in the ocean on their own at the moment.

Microsoft have Internet Explorer, Apple have Safari and Google have Chrome.  So that's desktop and mobile covered for three major platforms at the moment, with only the various Linux flavours not covered.  So...my question is, is there any point to this?  I'm thinking probably not.  In the early days of iOS, rumours were rife about a mobile version of Firefox, but the rumours were denied and they never turned into anything more than gentle whispers in the wind.  I think that they've missed the train and are now playing catch up.  They should stick with what they are good at, or innovate with a new niche product that nobody else has.

I still need you Firefox for development, so don't go anywhere anytime soon!

Google Abandons Google Toolbar for Firefox

In what can only be said is a predictable event, Google this week has announced that it is halting development of its Firefox Toolbar.  With Mozilla releasing Firefox 5, there is no in-place upgrade for those who want to continue to use the toolbar.  Has Google shot itself in the foot though with this one?  After reading many Twitter comments over the past few days, this is a sincere possibility.

Let me get one thing clear, I hate the Google Toolbar.  In fact, I hate all search toolbars.  They clutter your screen, they spy on what you are viewing, they slow your browser down and also they take up valuable screen space.  Ok, so you've lost the translate features.  Oh wait, no you haven't.  Google still have that little 'translate' link on each of their search results so really it is still there, but you will have to go the long way around to get to where you want to be.

The problem how I see it though, is that we are in this stupid IE6 situation again, where people will be reluctant to upgrade to Firefox 5 and they will want to stay with their 'working' Firefox 4.  Oh dear.  Step back though, as the real reasons are more transparent than you might believe.  Chrome is making leaps and bounds at the moment.  Google are even pushing it though billboard and TV advertising at the moment which means that they are playing hardball.  Why would they want to support other browsers when they have their own product?  Development costs are another factor.  Google Labs has also this week been shut down, so some innovation and development has been lost there, but all that really is is cost cutting and putting all of their chips into more profitable products.

Clearly Google sees its future at the moment with products such as the lovely new Google +, which I think is a refreshing change to Facebook.  And why wouldn't they?  Take a look at Facebook right now and you can see why Google wants to get to the party.  I don't really blame Google to be honest, but you have to admit that it is definitely more of a discrete way of dictating browsing habits and testing loyalties.  Time will tell to see if this was actually a masterstroke or actually, they will reverse this decision and carry on with the toolbar or not.  Given enough pressure and demand, I don't see why they wouldn't carry on with it.

Speed up Your Website - Top Tips

Speeding up your site can often be the key to an enjoyable web browsing experience.  There is nothing more frustrating than waiting for your page elements to load.  This is really one of my pet hates.

What can you do about it?  The elements that basically slow your pages down are as follows:
  • Http requests within your page, i.e. loading an image;
  • Poor or invalid HTML markup;
  • Large images sizes;
  • Too many images;
  • Lots of DNS lookups;
  • Uncompressed JavaScript and CSS;
Having lots of http requests on your page is a real performance killer.  Having lots of external JavaScript files, images and CSS files will kill the performance of your site dead.  But what can you do about it?  Well actually the answers are more simple than you might think.

Your JavaScript and CSS can be easily compressed by removing much of the unnecessary whitespace within your code.  What I personally do, is keep a copy of the uncompressed original and when I want to make a change, I do so to that document and then compress it, making another new smaller file.  A great site that will compress your JavaScript for you is jcompress.com.  Simply paste your code into a text box and it will spit your compressed code back out.

Images can also be combined into CSS sprites, which is essentially one image that can be used to style multiple elements from with your stylesheet.  For example, on my site I have one image that serves as a background for all of my h3 headings, main div headings and for the footer of my site.  This then only counts as just one http request, therefore massively decreasing the loading time for my site.  Have a quick Google around for this as there are many good sites that will give you some great examples.

Ok, so now you are left with a few things to do.  You are wondering how to make those big images smaller without having to sacrifice either the quality or the actual size of the image.  You've got several options.  One of them is to fiddle with the image format.  Personally, I prefer PNGs or JPGs for my images as they keep most of the quality.  Removing colours from the image is one way to also reduce your size.  Ok, now that you've done that, I bet that you are still wondering why your image size is large.  Next, have a go at using Smush.it which is a little tool available from the Yahoo Developer Network.  The tool will compress your images for you, removing extra details such as the Meta information which really isn't important for your site.  Smush.it claims that it is a "lossless" tool, which means that it optimises the images without changing their visual quality.  Once the process has finished, the tool reports how many bytes that it has saved you, along with a zipped your shiny new smaller file.

Lastly, poor or invalid HTML markup is also a performance killer.  If you validate your code according to the HTML spec that you outline in your header, your site will load much more smoothly and quickly as your browser won't be trying to make assumptions as to what your code really should be doing.

Don't panic now.  There are a few tools out there that can help you.  I personally develop for Internet Explorer as that is where the market is.  I then test in other browsers such as Firefox, Opera, Chrome and Safari, and more importantly no longer for IE6.  But, when I'm in the process of quality testing and validation, I use Firefox along with the FirebugWeb Developer, HTML Validator and the YSlow plugins.  For me, these are the best tools available for you to test your site.  I advise anybody who is even vaguely interested in performance to check these out.  YSlow and Web Developer are both brilliant tools as you can fully inspect your markup, and YSlow will even grade your site based on your components.

As you can see from the image above, there are several options available to you in YSlow (also a Yahoo Developer Network tool).  Using the components tab, you can see every element in your site.  One minor point to note, Firebug needs to be installed to use YSlow.

Good luck!

Thursday 21 July 2011

Two Useful Moodle Modules and Blocks

Wow, two posts in a day! Aren't you all lucky!

I've been looking through some of the best Moodle modules out there recently to add to our portfolio.  One area where I've always felt that we have lacked is on the video side of things.  Yes, the filters in Moodle can sort YouTube out no problem, but there isn't an easy way for you to add video in.

Step forward Media Player. The description mentions that it is the successor to the old FLV Player for deploying video within Moodle courses.  To be honest, there is enough of the necessary and basic functionality in there that you would expect, and it ticks all of the boxes.  It runs well, and I've not yet spotted any bugs with it.  I should imagine that the only stumbling blocks with this that users will encounter will be trying to work out whether or not they will be allowed to use the video as per the license terms and conditions, and also making sure that the video uploaded is less than the current max upload setting of 128mb that I impose.  I might consider upping this to 256mb, but I still don't see the broadband in this country being ready to handle large streams of data.

Then there is the other issue of our Internet connection to our site.  We currently have a 100mbit synchronous connection which will more than happily handle several streams outbound at any one time, as well as our normal web traffic.  Is this sustainable though?  I'm going to wait and see!  I might just throttle the site through IIS so that it doesn't impact on other services.

The other module is the Poll block.  Very simple, very effective and easy to use.  This is what I feel is the kind of thing that staff want to use to deliver a course.  It's also interactive, which generally translated means that students will also like it.


As you can see from the image above, it makes a nice little bar graph to help show the responses instantly.  I would recommend these two highly.

Network Level Control Through Your Website (and a Bit More)

Ok, network level control through your website.  Interested?  Good.

Last summer, a project of mine was to build a micro site which runs within the VLE that would give ordinary staff users access to network level functions that would normally be reserved for IT staff.  This project would be purpose built for our new student help desk, so that students could have a 'one stop shop' experience as we continuously dubbed it.  The key to this project would of course be ease of use.  We needed a solution that everybody could just pick up and run with from day one, and something that we would need to give very little support to.

The first hurdle would be to determine which services our students would need.  The new site would have to integrate with the following systems: -
  • Active Directory for network level and user management;
  • MIS system for course management, timetabling, exams and attendance;
  • Connect VLE (Moodle) for course management and job logging;
  • PaperCut print management for printing credit;

Next, we looked at the interface, and how we could make it as easy as possible for our staff to use the system.  A quick conclusion was that big, easy to use buttons, with minimal keyboard input and touch input would be the way forward.


The first screen that the user would need to see would be some sort of search facility.  This is just one big text box with some JavaScript on it to constantly give it some focus.  Users can input into this box into a variety of ways, including the traditional typing of random strings such as the username, first name, surname or a combination of these.  Once the search results are returned, a list is given back with possible results.  Each result shows the full name, username and picture of the student in question.  The user then clicks on the tab to take the user into the possible functions. The other method of input would be from the barcode scanner attached to the desk that would quickly scan the back of the student card that we give out at the start of each year that contains the username in barcode format.

Just so that we can confirm the user, the picture is printed on the card, and the same picture will appear on screen once the card has been scanned which points at a network share.


The user is then presented with four departmental options that are displayed as tiles, as well as a quick overview of the status of the student underneath.  This overview can quickly establish any problems, such as disabled accounts (and who disabled it), printing credit balance, and user data quota.  Clicking on any of the department tiles then gives another set of tiles that are specific to that particular department, i.e. in IT Services are functions such as 'enable / disable account', 'reset password' etc.  When clicking on any of these options, you can see instantly the status of the option, so say you've clicked on the 'enable / disable account', the tile will then show 'disable account' because the account is already enabled.  This is not too dissimilar to how Microsoft use the 'Live Tiles' implemented on Windows Phone 7, although I did it first for the record!

The next step was to make all of these functions.  The functions that we decided on were: -
  • Enable / disable account;
  • Unlock account;
  • Add to Moodle course;
  • Reset password;
  • Log new IT job (e.g. scanner not working);
  • Print student timetable;
  • Print exam timetable;
  • Attendance queries;
  • Order replacement student / bus cards;
  • Add printing credits via PaperCut API;
The network level functionality was achieved using both LDAP and SLDAP (for password reset) commands as well as network shares to link to student photographs.  Interaction with the PaperCut APIs made changing printing balances very easy with just one short command, and the other functionalities listed consisted of ODBC transactions to a set of different servers.

The site was locked down and would only be given to certain users based on permissions, as well as only being accessible internally to stop network intrusion.  The hardware that we ended up purchasing was a Dell Inspiron One machine with an attached barcode scanner to read in the student cards.  This has worked well, however we have found that most users have still preferred to use the traditional mouse and keyboard.

I hope that this will help somebody in some way, and I am happy to share any details on how certain parts of this were achieved.