Add a redirect from search to places for failed autocomplete.

[Mike-Heneghan]

At the moment if a user tries to search by place name on the homepage they have the option to click the dropdown or hit enter for the postcode to be swapped in for the search.

If a user adds a space to the place name or the browser is too slow to autocomplete they are redirected to an error page as the 'postcode' is not recognised.

Need to add regex to process the searched input and redirect to the places route.

Also, the places page redirects to a postcode if there is not a landing page but the place name is recognised which could redirect to the page they intended to go to anyway.

[Mike-Heneghan]

Problem:

When a user searches by placename they expect to get the same style of search with the postcode being autocompleted.

If this fails, it could be that the place name they're searching for isn't available or the auto-complete might not have triggered due to JS behaviour or connection speed.

So the normal flow has been interrupted and there is an opportunity to catch problems such as this:

Ideally, if a user searches Glasgow i.e. it doesn't get converted client-side with the autocomplete function they would make it to the desired page anyway.

Option 1:

We could handle it and convert the placename into a postcode anyway?

The user submits Glasgow and somehow we catch it isn't a postcode and find the postcode associated instead.

This could potentially be a fallback on postcode validation or intercepted before that point.

If not postcode is available we display a meaningful error i.e. this town is not searchable please enter your postcode instead.

Option 2:

If a user searches anything but a postcode and there isn't an autocomplete function and we redirect to /places/<inputted_text>.

Currently, if there's an associated landing page that will appear, or as a fallback, we'll try to match the query to a postcode.

It's likely that the user doesn't necessarily want to go to the landing page as that's not where they would have been directed if the search hadn't been interrupted.

It's unlikely there will be more landing pages than matchable placenames to locations. So we would at the end process the placename to a postcode anyway but with more steps?

Also if a place isn't matched to a landing page or a postcode then we get a 404 error. Rather than a meaningful one.

Preferred solution (Option 1):

Although the search GET method is already complex I think we should catch placenames which haven't autocompleted to postcodes there. If a postcode isn't found for the searched placename we can display a better error such as "isn't supported for placename search please use the postcode.

If the form validation finds something in postcode form which doesn't work the current behaviour continues.

If we follow Option 2 the user might be redirected to a page they don't want i.e. landing-page. It's also more likely there are more convertible places names to postcodes so the user is also likely to reach the search with their postcode anyway but with more steps in between? Also option 2 doesn't have better error pages regardless.

[Mike-Heneghan]

Updated the search form validation to add a fallback to check the queried string for a place name that can be matched to a postcode.

If successful the matched postcode is returned and the get request processed as normal.

The only issue is the URL params don't change to reflect the swap of placename to postcode.

I've experimented with updating the request params although it would appear the request is immutable.

[Mike-Heneghan]

Updated to add a redirect for when the user searches by placename. The redirect takes the query string and redirects to search fo that the postcode= param is maintained.

[Mike-Heneghan]

Need to process postcode when redirecting to improve formatting.

[Mike-Heneghan]

Added method to replace spaces with + for formatting of url.

[Mike-Heneghan]

Merged into master