Layouts don't always work when a prototype is migrated

[BenSurgisonGDS]

What

The use of layouts should be consistent when creating or migrating a prototype so that they are consistent with the documentation for version 13.

Version 12 and before had app/views/layout.html (and app/views/layout-unbranded.html)

Version 13 has app/views/layouts/main.html

The idea being we can rely on layouts being in the layouts folder, and possibly offer the user a choice of layouts when creating pages from templates.

Layouts help the user make changes that affect multiple pages, for example a custom header, footer, scripts and so on.

In migration, if the old layout.html has changed at all, we do not provide a new layouts/main.html. This means new pages made from templates will not work or even viewed. This is not highlighted to the user as a migration fail.

We could:

• fix the migration script to process layouts better, and warn about this issue
• add a check to the kit that helps users who have already migrated to fix it via the Manage Prototype UI

Who needs to work on this

• developers

Who needs to review this

• developers

Done when

• Dev discussion on whether we make change @joelanman @nataliecarey
• Raise a ticket to fix the migration script
• Design the UX for people who have migrated and have a missing layouts/main
• The way layouts are used matches the version 13 documentation for both create and migrate

[joelanman]

discussed with @nataliecarey - this is a regression, there should be a fallback layout if layouts/main is missing so templates continue to work

[joelanman]

investigated again, the fallback does seem to work. There is definitely a bug in migration though - it should error if layout.html has been edited. Currently it does not, and it deletes the includes that layout.html relies on.

There is a separate bug:

• If app/views/layouts/main.html is missing, viewing templates in Manage Prototype does not work #2119