Remove public site

[theskumar]

Description

• Keeps the migrations to delete the public tables
• Updates and adds a global footer (admin configurable)
• Update the layout of homepage

Fixes #3110 #3559

Test Steps

• Remove the public site, go to "Wagtail Admin" > "Pages", set the "Apply Home Page" as the default page of the site. Remove the public site page
• Do regression of the whole site

[frjo]

I have merged in all "Remove public…" PRs before this one now so this can be rebased of main.

[frjo]

I merged in the icon PR so this can be rebased.

I also see this error:

WARNINGS:
?: (urls.W003) Your URL pattern 'account/two_factor/setup/complete/' [name='two_factor:setup_complete'] has a name including a ':'. Remove the colon, to avoid ambiguous namespace references.
?: (urls.W005) URL namespace 'apply:projects:reports' isn't unique. You may not be able to reverse all URLs in this namespace

[frjo]

So nice seeing all the delete file statements in this PR!

[theskumar]

I merged in the icon PR so this can be rebased.

I also see this error:

WARNINGS:
?: (urls.W003) Your URL pattern 'account/two_factor/setup/complete/' [name='two_factor:setup_complete'] has a name including a ':'. Remove the colon, to avoid ambiguous namespace references.
?: (urls.W005) URL namespace 'apply:projects:reports' isn't unique. You may not be able to reverse all URLs in this namespace

These two warning doesn't seem to b/c of changes in the PR. If it make sense I'll update them in this PR or have them resolved in another PR.

[theskumar]

Unable to get the failing test reproduced locally. Will try it tomorrow.

[theskumar]

Django did had start up issues in very old versions before they introduced the apps.py config option with ready() function in that would be excecuted after all the model classes are loaded. So that could be it.

[theskumar]

@wes-otf you saved me hours. The solutions seems to be working and accessing the models before its initialized is a very bad idea in general. The loading of models and apps are very unpredictable.

That why Django introduced https://docs.djangoproject.com/en/5.0/ref/applications/#django.apps.AppConfig.ready to you can perform any on_load activities here.

I believe there are more code in the forms.py in certain apps that is initialized like this, instead of in the __init__.py looks like the fixes things for now. But we can re-visit and cleap all module level queries.

[frjo]

This doc need updating at some point as well:

hypha/docs/getting-started/contributing/code-contributions.md

Lines 19 to 34 in 50693eb

	### Reversing URLS
	Due to the way the urls are [configured](https://github.com/HyphaApp/meta/tree/6060bb2491e501e501979a68036dd52f60f6a6fe/Contributing/Implementation.md#url-configuration), tests for the Apply site will fail as the Apply site does not use the default URL config.
	This can be resolved on a per testcase basis using the following:
	```python
	from django.test import TestCase, override_settings
	@override_settings(ROOT_URLCONF='hypha.apply.urls')
	class MyTestCase(TestCase):
	pass
	```
	This is implemented by default for the `BaseViewTestCase`

[theskumar]

Reversing URLS

Updated.

[theskumar]

Looking into the test case failing. Let's hold on to merging before that. This something to do with the updated Sites setting.

[frjo]

Can it be that the initial migrations created a public and apply site and set the public as default. When testing against this we get errors.

[wes-otf]

@theskumar glad it worked!! Was a bit of a shot in the dark, weird stuff.

[theskumar]

Can it be that the initial migrations created a public and apply site and set the public as default. When testing against this we get errors.

Yes. You are absolutely right. updated the code in b788eec

Re-created by creating a fresh db, ran migration, without adding the sandbox db data

[frjo]

Deploying this to test now.

[frjo]

I have set the apply site as default on test now.