Google’s documentation says:
> robots.txt is not a mechanism for keeping a web page out of Google. To
> keep a web page out of Google, you should use noindex directives
We’ve implemented a noindex directive now, so we don’t need to serve
robots.txt any more.
Reimplements https://github.com/alphagov/notifications-aws/pull/796
Since deploying alphagov/notifications-utils#736 I’ve been looking at
how members of the public are ending up on our support page. The vast
majority are landing on https://www.notifications.service.gov.uk/features/email
Previously we thought that they were clicking the ‘contact us’ link in
the page, which deep linked into the support journey, so we removed
these deep links in alphagov/notifications-admin#3451
But the tickets are still coming in, so I think that people are still
landing on this page, then going directly to ‘support’ in the top
navigation. So the next measure we have available is to try to stop
people from landing on this page in the first place. All the examples
I’ve looked at show people coming from Google to this page. By putting
the page’s URL in our robots.txt it should stop Google (and other search
engines) listing it in search results.
We have a policy about how suppliers are allowed to use Notify. But we
don’t explain it anywhere. Which drives contact to our support form.
This commit that adds a new page that explains the policy.
I’ve moved the related content about who else can use Notify from the
get started page to this page as well, where it doesn’t need to sit in
a details element.
We had two templates that contained a link styled as an old style
button but that weren't being used anywhere (one would actually give a
`500` if you tried to visit it). This removes them and the view function
for one of them (the other no longer had a view function).
Rather than hard coding the page titles, let’s just accept anythin
that’s a real template in the guidance folder – will make it easier for
Karl to edit and create pages.
This way we have a URL we can give people that always points to the
latest version of the spec.
And it makes our code more Flask-idiomatic to be using `url_for` to be
generating a URL, rather than passing around a constant.
Rather than force us to write the decorators in a specific order let’s
just have one decorator call the other. This should make fewer lines of
code, and fewer annoying test failures. It also means that the same way
of raising a `401` (through the `current_app` method) is used
everywhere.
Utils 33.0.0 adds alt text to email branding - the HTMLEmailTemplate now
initializes slightly differently as a result (with both `branding_name`
and `branding_text`).
So that you don’t have to use the footer navigation to switch between
these related pages. Matches the template we use for organising
features-related content.
Returns the data calculated by the API. Stored in Redis against a
hardcoded key so that no-one hammering the home page is directly hitting
the database.
This adds a preview pane which is visible when updating a letter brand.
If JavaScript is enabled, the preview pane shows on the set-letter-branding
page, and submitting the form saves updates the letter brand for a service
immediately. If Javascript is not enabled, there is a separate 'Preview email
branding' page which shows a preview of the brand and has a 'Save' button on it.
it wouldn't show search if there were under a certain amount of letter
or email branding options - however we know there will always be more
than that amount so lets remove some complexity.
Also, rename the SearchTemplatesForm because it can search anything -
it just prompts you to search by name is all.
The value that means no branding (in the form) has changed from `'None'`
to `'__NONE__'`.
This commit:
- accounts for that value
- makes sure that no branding (ie plain GOV.UK) is still displayed when
no query argument is given
Coloured brandings can just be a coloured
background with text. At the moment the /_email
preview page assumes a logo image will be part of
a brand so looks broken.
Setting the branding_style to 'None' causes the
API to remove the email_branding field from a
service model. The branding request page
controller was depending on that value being
to present get the brand type.
The email preview page (used in an iframe on
various pages) wasn't able to recognise a
branding_style of 'None', causing a blank page to
render.
