Skip to content
This repository has been archived by the owner on Mar 15, 2024. It is now read-only.

Site-wide data models #19

Closed
solarissmoke opened this issue Jul 10, 2019 · 7 comments
Closed

Site-wide data models #19

solarissmoke opened this issue Jul 10, 2019 · 7 comments
Labels

Comments

@solarissmoke
Copy link
Contributor

solarissmoke commented Jul 10, 2019

I propose to use site-wide settings to store the following:

  • Legal footer text: rich text (required)
  • Top navigation menu links: orderable sequence of link blocks that can link either to a page on site or to an absolute URL (required)
  • Footer links: orderable sequence of link blocks that can link either to a page on site or to an absolute URL (required)
  • Language code to currency mapping (as defined in Confirm approach for localisation and currency detection #1).
  • Currency information:
    • Code
    • Symbol
    • Allowed payment methods
    • Default donation amounts: for each currency, 4 default suggestion values for that currency.

It might be easier to store currency information in code instead - to make a call before starting work on this.

@solarissmoke
Copy link
Contributor Author

solarissmoke commented Jul 10, 2019

I just realised that putting the legal footer text into a setting will complicate translations. If this text is not likely to change often then the simplest approach in my view is to hard-code it into the template, so that it can be translated in the normal way.

The same potentially applies for the navigation/footer menu items as well. I notice that on the current site, the top navigation is only available when viewing the site in English.

@alanmoo
Copy link
Contributor

alanmoo commented Jul 10, 2019

The top nav is only in English because the Foundation site itself is mainly only in English.

@solarissmoke
Copy link
Contributor Author

I've been looking into how to store currency information, and feel that we're best off having a hard-coded dictionary very similar to the current one.

The rationale for this is that this data doesn't change frequently, and so it doesn't seem worth the cost of modeling in the database and making editable in Wagtail.

@alanmoo @TheoChevalier does this sound OK to you?

@TheoChevalier
Copy link
Collaborator

@solarissmoke No issue on my side, thanks for asking :)

@solarissmoke
Copy link
Contributor Author

Closing on the basis that we've ended up storing all of this information in code, so no site-wide models necessary at present.

@alanmoo
Copy link
Contributor

alanmoo commented Jul 18, 2019

Out of curiosity (because we might need it on our other Wagtail site) is there any documentation on best practices for site-wide model implementation?

@solarissmoke
Copy link
Contributor Author

Yes - use wagtail.contrib.settings: https://docs.wagtail.io/en/v2.5.1/reference/contrib/settings.html

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants