Access (add/edit/delete) to “Site” in the wagtail admin panel is controlled via permissions in groups. For example a user with no delete permission for the site.

Wagtail itself works alright if no site is available and if something relies on the site wagtail gives a descriptive message that no site is configured. For example, all sites are removed and access to “Site Settings” in the admin panel gives an error.

Just like wagtail’s “Site Settings” IoGT relies on the existence of a default site (if no default site then use the first site—not implemented right now but can be which wagtail itself uses in some places) in multiple cases, for example, registration survey, global theme, etc.

The following are possible options

• Don’t give access to anyone for “Site”. Only superusers will have access to it. This would be difficult to manage I imagine.
• Add help text in the "Site" admin panel that explains the repercussion of deleting a site.
• Don’t let anyone delete the site if only one is remaining.
• Rethink and refactor the IoGT code to handle no-site scenarios.

I think we should be following Wagtail's lead i.e. assume that there may be no site at all and defend against that situation. Focusing first on the specific problem with GlobalDataMiddleware will fix the bug described by this issue. If there are other similar scenarios where a default site is assumed to always exist, then those should be addressed too, but maybe as a separate issue(s).

With the introduction of Wagtail Cache, it is also worth considering whether GlobalDataMiddleware is still required, and if not, then the fix might be to remove it.