It looks FUBAR, I mean 500. This is not a good way to handle it, even if admins receive an email about exception. Why?

Usually content editors are not admins. After adding such page, they can only guess what happened and why the content doesn't appear.

The attached patch fixes it. It does two things:

Validates flatpage when saved through admin panel. If there is an URL clash for some of the sites, validation errors are generated for 'sites' field.

For installations where a clash has already occured and is present in the database, it just serves the first page found by query. It may be misleading to hide the error, but I assume that (i) it's better to serve content than 500 to end user and (ii) any doubt would eventually cause content editor to go to the admin panel and try to edit the page, running the new validation.

In discussions today with Joseph and others decision was made to leave the view throwing a 500 when the database is in an inconsistent state that allows for URL collisions, but to apply the portion of the patch that stops users from corrupting the data from the admin panel.

Hoping to get tests sorted out soon. Currently no tests exist at all for flatpages middleware.

After spending way too many hours beating on testing for flatpages, and not making very much progress, I'm going to give up. Hopefully someone else can sort out how to test the admin panel and the view. Sorry :(