Category Archives: Clients

New website for G2 Legal

I am delighted to announce the launch of a new website for legal recruitment agency G2 Legal.

Screenshot of a recruitment website showing their main branding and some legal jobs

The G2 Legal website from 2017-2024

Screenshot of a new recruitment website showing their main branding including a woman and their tagline Passionate about matching talent

The new G2 Legal website (click for larger)

I have a very long relationship with G2 Legal, this is the seventh complete website I’ve helped build for them and it was very much a group effort.

The Team

Amy Walker – Head of Marketing at G2 Legal – acted as primary contact and driver of the project. She handled researching and collating all of the company needs, boiling them down to the necessities and messages that can fit on a website, writing all of the content, and a huge amount of project management. This website does a great job of representing the company, and that is down to her and the work she put in both with Nick and the whole project.

Nick CarterStudio Gallant – design and UX. Nick is a fantastic designer and I’ve collaborated with him on several websites for clients. As usual, he did a fantastic job of taking the client brief and making a design that is contemporary, professional, and will stay fresh for many years. He worked closely with Amy to make sure G2 Legal got what they needed from this project and I think he did a very, very good job.

Jim LesterZero1Zero – front end build. Jim came highly recommended by Nick and I can see why. He made a great translation of Nick’s designs into working templates with clean, understandable HTML, CSS and Javascript in short order and was more than helpful when we had some late additions to the project. He was a delight to work with and I hope I get a chance to again in the near future.

Paul SilverSilver Web Services – back end build, integration of front and back ends. More on my part below, but in brief I handled moving the website from one set of back end code to another, took Jim’s templates and turned them into a working site which can be edited by the staff at G2 Legal, and handled various search engine optimisation tasks.

The site became a much larger project than planned and I am delighted with the way it has come out. Thank you to everyone who was involved with the project, I hope you’re as proud of the outcome as I am.

My part of the project

Laravel to WordPress

Being a programmer, most of my work is hidden away. Previous versions of the website were editable by the staff at G2 Legal, but the content management features were little used and had therefore not had much in the way of updates for over ten years. Now, the company has an active marketing department headed by Amy and the website needed to change. Their main requirement from the tech was to have a site they could easily edit and preview changes so they could see the pages as they would be published, not just parts of them.

The previous site was based on Laravel and various custom code written by myself and Laura Tyler. I assessed various Laravel based Content Management Systems (CMS) to see what we could add to the existing code base to do what was required, but I found them all rather lacking from a user experience viewpoint. The people updating the website are not techies and should not need to become ones in order to get their job done. I looked further afield for better tech.

WordPress for a modern editing experience

A solution came thanks to Hazlitt Eastman, who showed me a project he was making in WordPress using their latest editor with helpful additions from Advanced Custom Fields. It gives the site owner a very good editing system and preview and allowed me to get very close to the perfect experience for the client within their budget. Hazlitt kindly gave me a training session in how to set up the “blocks and patterns” involved in making the editing system pleasant to use and extra technical support across the project. Big thanks to Hazlitt for this, he got me out of several technical holes.

A lot to port

Originally I was thinking I’d use Laravel to run an API which the WordPress site would make requests to. For most of the site, that turned out not to be the right choice when I looked at the long term maintainability of the code, and considering at some point they may want another developer to work on the project. So, most of the backend code moved from Laravel to WordPress style PHP. The site may look simple, but there are a lot of hidden depths to it, including a very advanced job search both on the backend and with a new experience on the frontend which meant writing new APIs, which WordPress easily handled, and a lot of Javascript.

The intricacies of moving all of the code was a much larger task than I expected, but I think gives us advantages over the short and long term: the speed of response of the website wouldn’t have been as fast if I had stuck with my original plan, and changes over time would have been more convoluted as we’d be working with two quite different styles of codebase rather than just one within WordPress.

Looking at the long term

The previous website was live for a little over six years and went through many changes as company needs changed. It ended up as a bit of a patchwork of the original and new looks and features. I’m confident this site is flexible enough to work with changes G2 Legal needs over the coming years and will still look good at the end of it.

Hear’s to Amy, Nick and Jim for all the help getting it there with me.

Google Jobs Indexing API Setup Problem

I’ve recently worked with Laura to set up three recruitment sites to automatically notify Google Jobs of new and changed vacancies showing on the sites.

The documentation is relatively good, but when setting up the second I made a mistake that I don’t think is easy to spot, so I’m writing it up here in case it helps someone else, or indeed myself in the future.

The problem was: we had everything set up – new set of keys and JSON for the site from the Indexing API dashboard for the site, had added the special email address you have to set up to Google Search Console, copied the reusable code from the first project, which was working fine and… it wouldn’t work. Sending URLs in through the Indexing API got the error:

Permission denied. Failed to verify the URL ownership.
reason: forbidden

Now, neither of us are daft, we could see there was a permissions problem, but couldn’t track down where it was. After much re-tracing of steps and faff, I compared everything about the existing, working project and the second one we were setting up. In Google Search Console (AKA Webmaster Tools), you have to add a special email address from the Indexing API dashboard. I’d done this incorrectly.

I had set up the Indexing API user for the site via the “New user” button in Google Search Console, then given it Full permissions. This was wrong. I should have used the “Manage property owners” link and the “Add new owner” button.

Google Search Console manage property owners link

I deleted the user I’d added with the “New user” button, added one with the “Manage property owners” link and ended up with a list like this:

List of owners in a site in Google Search Console

The Indexing API then started to work, no problem at all.

The first time I’d set up a project with the Indexing API I’d followed the instructions very closely and had got this step right, the second time I’d got ahead of myself and thought I remembered all the steps, and this bit within Search Console caught me out.

I can understand why Search Console has two different categories of user, allowing multiple owners gives a layer of management in an account which lets anyone shift in and out of ownership. But, it’d be nice if the interface was more clear for a case like this, or that they had a category for API users – maybe this will come in the future as Search Console is developed further.

So, if you’re getting a permission error when using the Indexing API, check how you have the API user set up within Search Console, it could be where your problem lies.

Secure certificate registration – ensure you choose ‘www’ or not

I’ve been helping a client move their website from their existing host to a new one, as their old host is closing down.

This was quite straightforward once they’d decided to only move the site I had written the code for, not another which was a complicated unknown entity.

The only wrinkle was they have a secure certificate to give them an https connection and we had to register a new certificate as part of the move. I did this through their host at their request, but hadn’t realised that most SSL certificates are specific to the domain, including the sub-domain. This was a mistake as they used the ‘www’ version of their address for their website, and I registered the new certificate for the non-www version.

To stop this being a problem, I put a redirect in to the .htaccess file to redirect all traffic to the non-www version on the secure connection:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.(.*)
RewriteRule ^.*$ https://%1/$1 [R=301,L]

The only further foible was as this was an existing site, Google had indexed the site, and shows the https version in the search results, even though the home page is not explicitly https. Now, because it points people to the https://www version of the site, it shows an unsecure error before showing the site, because the certificate isn’t valid for that on the new site.


  • Used Google Search Console (AKA Webmaster Tools) to update the preference to the non-www name
  • Updated the DNS of the www. version to point to the old server while it is still working
  • Added the above .htaccess redirect on the old server to point everyone across to the secure version of the non-www address
  • Created a new XML sitemap of the site at the secure, non-www address and re-submitted it to Google Search Console
  • Wrote an apologetic e-mail to the client explaining the mistake
  • Wrote this blog post and linked to the new site address to help the non-www address get indexed

All this means – searchers go to the old host so no security warning, then get forwarded to the new host while we wait for Google to respond to the preference change. I hope it comes through quickly.

And now I’ll go back to my scheduled work a wiser, if more tired, man.

Sending a push notification to your browser or mobile with ColdFusion and Push Engage

Push Engage is a service which lets you easily send push notifications to a browser or mobile phone, using a little code on your website. It’s very easy to set up and they currently have a very generous free account, allowing you to send a notification to up to 2,500 browsers/devices.

I’m using it as part of some alerts in the background of a client’s website. They’re using ColdFusion, so I needed to work out the code to send the alert from them, the API documentation on Push Engage has an example in PHP, but it’s very simple to convert. Here’s a CFHTTP call that will send a notification:

<cfset api_key = “(your API key here)”>

<cfhttp method=”Post”

<cfhttpparam type=”header”

<cfhttpparam type=”Formfield”
value=”The text for the alert title”>

<cfhttpparam type=”Formfield”
value=”The smaller text of the message of the notification”>

<cfhttpparam type=”Formfield”

I’ve already followed their steps for adding Javascript to a page on the website, visiting it using a browser on my computer and my phone and accepting notifications from the site. Now, when I trigger the page with this on, I get a notification a few moments later. Lovely!

Thanks to Dave Child for introducing me to Post Engage.


My first Stripe integration, using PHP

Recently I carried out my first integration to the new (to the UK) payment processing provider Stripe. My client Jasper Goodall was looking at moving to Paypal for taking payments and having integrated with Paypal in the past, I suggested Stripe as a more developer and client friendly alternative. He liked the look of Stripe and signed up.

I was moving the site from using Sagepay over to Stripe and as all the basket and post-payment logic was written, dropping in Stripe was very straightforward. Their documentation is very clear, testing is simple, and taking a payment is a doddle. I hit a few minor issues, which were:

PHP needs ‘mbstring’ turned on

My local PHP 5.2.4 install didn’t have mbstring on by default, so I had to install it. This was on my Windows PC so I had to move the mbstring DLL in to the main ‘php’ directory and edit the httpd.conf file to include the DLL as one that needed to be loaded. I then restarted Apache and it was working fine.

My host did have mbstring turned on, so I didn’t need to change anything there.

Secure certificate required

My client didn’t have a certificate to allow his to use SSL. However his host, Claranet, had a shared secure area that all of their customers could use without requiring their own certificate. This was good, but I had to re-code parts of his site so things like the stylesheets would load properly when using this area.

If you or your client are on shared hosting with one of the larger providers, it’s worth checking to see if they have a secure area you can use before investing in your own certificate. This can save you some money, but has the disadvantage that the URL of your secure pages won’t show your domain in that part of the website address, which may make some customers suspicious. It will be worth adding some text to your pages explaining how they are secured if you think that is going to be a problem.

Coding up receipts

Previously, we were using Sagepay which takes various information about the products in the customer’s basket and builds an e-mail notification of the sale for you. Stripe just take the amount of money you are charging, so I had to update the website to create a notification for the customer, and one to tell the client a sale had been made. These were very simple additions to the post-sale process.

Overall, Stripe was a delight to integrate with. I’ve set up shops using several payment gateways – Sagepay (was Protx), Worldpay, Secure Trading, Paypal, and Paypoint. Stripe was by far the easiest, taking only a few hours to integrate with including the bug fixing of my setup and the re-coding of the existing shop to send the right information through and use the extra secure area of their hosting. If you were starting from a cleaner base, you’d probably be looking at an hour or two including reading the documentation. Really nice.