SEO and technical issues we encountered in Drupal 7

Since I joined City A.M., we’ve been gradually migrating away from Drupal 7 to a fully bespoke CMS built on Laravel. We had planned to do this anyway, but we accelerated parts of the migration as we hit issues that we were unable to solve. Here’s a summary of the main ones.

Continue reading “SEO and technical issues we encountered in Drupal 7”

Advertisements

Production code and real-world tech

This week I read a tweet that really resonated with me:

I totally agree.

However, this applies beyond coding. I’d like to see more examples of tech being put to use on real projects. It’s cool to look at what’s new in tech – but to me, it’s even cooler to think of real-life examples where a specific piece of tech has added value that would have been a lot tougher – or impossible – with another tech choice.

Rather than talks or blog posts along the lines of “How we built a website in AngularJS”, how about why you used AngularJS? How about whether a framework has been a huge asset in the early stages of building an application, but it’s caused difficulties later on? How about moving between JS frameworks? How about tales from teams who have inherited bad codebases and gradually improved them? Or tips from developers who stay in jobs for a few years and have consolidated tools or reduced technical debt?

I’m sure there are plenty of these talks and blog posts around. I’d just like to see a little less of “here’s a new tool!” and a little more of “here’s how to get more out of your existing setup”.

How to migrate from one PHP framework to another – gradually

Picture the scene: Your development team is getting more and more frustrated with the framework that a project was built on. Or you’ve taken on a new project, and the code is a mess. You don’t want to be stuck with that codebase forever.

In a large project, you may not have the option or the time (or indeed the desire) to do a big bang migration from one framework to another. The company may not let you do it. Aside from being boring work, it’s also pretty risky – and it could absorb a large chunk of time. Or it’ll never be completed.

The first thing you should do is trial the new framework, either as a dummy project or with a safe copy of your current project. Basically, make sure this is a move you want to make. You don’t want to start another migration before the first one’s done…

Once you’re sure you want to proceed, here’s what to do. (Hopefully it goes without saying this shouldn’t be done directly in production…)

1. Rename the index file to index-old-fw, or whatever the name of the old framework is. For instance, if you wanted to move away from CakePHP (I’m choosing a framework at random here), you might rename index.php to index-cake.php.

This will break everything.

2. Take the index file for the new framework, and name it according to your new framework. Let’s say you’re using Laravel – you might rename index.php to index-laravel.php.

3. Now create a new index.php and write some simple logic that will map to one framework or the other. Something like this:

<?php
$laravelPaths = array('/test-laravel');
if (in_array($_SERVER['REQUEST_URI'], $laravelPaths)) {
  require 'index-laravel.php';
} else {
  require 'index-cake.php';
}

(This is a really simple example; you’ll need to modify it for partial matches to handle things like query parameters later. For now the point is to get one page working on the new framework.)

4. Put the new framework code in a logical folder so it can be loaded in the new index file. This largely depends on how your current framework is set up. You probably won’t want to mix two frameworks in the same folder, as folders may have overlapping names – possibly even files. You’ll have to handle all the paths for the new framework in your new index file. The goal is to keep all your existing pages working fine on the old framework.

5. Set up the new test page in the new framework.

By now you should start to see how it’s possible to mix frameworks in a project. This isn’t a permanent solution; it allows you to start using a new framework and gradually migrate across to it.

The early part of a migration will be tricky. Unless you can reuse API code across both frameworks, you’ll probably need to rebuild a lot of code in the new framework. This is a perfect opportunity to write unit tests if you’re not already using them. Focus on building one page (a good one is a static page, such as your About page or another page that doesn’t do much) – to do this you’ll need to build a lot of the core “scaffolding” code such as getting your site theme to display properly, connecting to the database (less important for static pages but needed later), and then things like logins and so on.

As you progress onto other pages, it will get easier as a lot of the base work can be reused. You’ll need to update the URL list in your index file to map specific URLs to the new framework as pages get moved. You can write code to handle wildcard URLs so you can move entire sections of your site to the new framework, e.g. product landing page. It’s a lot of work but it can also help to rationalise your entire site, especially if there’s a lot of odd standalone pages that nobody really remembers creating!

Once the base code for the new framework is in place, you’ll have a big advantage and a big disadvantage with future work:

  1. Advantage: New functionality can be built entirely on the new framework.
  2. Disadvantage: Repetition/duplication across the two frameworks – especially with theme files.

You can improve the situation by building bridging code that will help you to migrate. Code that is framework-agnostic and can be used by both frameworks.

Keep track of how many URLs you have across the site and how the migration is going. At some stage you’ll reach a “midpoint”, which is when you need to replace your URL array. Instead of sending only specific URLs to the new framework, send everything except the URLs you specify in that direction. This requires good knowledge of your application architecture, but it can be done. Remember you can use wildcards to target entire sections that need to stay on your old framework for the time being.

I won’t claim this to be a particularly clever or elegant way to do things, but it works. So far, I’ve used it for the following migrations:

  • deprecated in-house legacy framework => Zend Framework 1
  • Drupal 7 => Laravel 4.2
  • custom framework => CodeIgniter
  • custom framework => rebuilt custom framework

Hope it’s of use to someone.

Internet Explorer worldwide usage: the state of play

With Windows 10 released today, along with the new Edge browser (that we should assume will ultimately kill off IE – it should already have happened!) it’s a good opportunity for a quick rundown of the status of IE on the web.

Stats

Netmarketshare.com has a good browser market share chart. The IE bits:

  • IE6: 0.52%
  • IE7: 0.26%
  • IE8: 13.58%
  • IE9: 6.76%
  • IE10: 5.55%
  • IE11: 27.22%

Automatic updates

The lack automatic updates in IE doesn’t help to get people onto the latest version. However, that all changes with Windows 10, as the Edge browser will support automatic updates.

However, it’s not a perfect scenario as this article shows.

UX 101: put the cursor in the first field

When loading a page where a form is the focal point of the page, always put the cursor in the first field. This allows the user to start typing immediately.

A good example is when you go to create a new blog post at WordPress.com. Have you noticed how it works?

  1. When the New Post page loads, the cursor goes right into the Title field.
  2. After typing your title, hit the Tab key. Now you’re right in the Body field.

The little details make all the difference.

There’s an exception though. If there’s a search box on a page where the main function isn’t search, don’t put the cursor in the field. If the user scrolls down when the page is still loading, the cursor can make the page jump back up to the top so the search box is visible.

Putting the cursor into the first field is really useful for speeding things up for the user. You’ll notice it the most if you have a lot of repetitive data entry to do. Anything you can do to reduce a mouse click and get the user started much faster will help to make your screens a joy to use.

Change in Technology

I like change.

Actually – I love it. I get bored when nothing changes.

It’s partly why I do what I do. I’ve been coding for years, as I can be in control of what gets done – and how it gets done. More recently, I’ve been managing a team of developers, giving help and direction with what needs to be done.

I enjoy making changes. I feel immense satisfaction from getting things done (it’s also the tagline on my homepage).

I dislike the phrase “if it ain’t broke, don’t fix it” – as it’s sometimes used as blanket opposition to any change at all. I understand that other people don’t always like change. And there’s a line of thinking that if nobody asks for a change, nobody would want it.

Sometimes, you’ve got to take the lead and deliver new and exciting things without waiting for people to ask. It’s not great if a change is unpopular – but sometimes it’s good to take risks.

The best changes are when you get positive feedback. There’s a saying that no news is good news, and that no feedback probably means that people don’t hate your product. Or that nobody’s using it…

But when someone goes out of their way to say they really like a change – it makes all the difference. It doesn’t have to be a big change: I’ve seen incredibly happy users from some of the smallest changes imaginable. The devil’s in the detail. Definitely do sweat the small stuff.