NB Public repo. So avoid pushing secrets...
CMS and REST API built using Wagtail. It runs on http://localhost:8000 by default. With admin pages exposed on http://localhost:8000/admin and API exposed at http://localhost:8000/api/v2/
For actual production usage we will most likely rely entierly on REST API, so consider all templates and html views test/dev only.
Initial site following structure as outlined in official Getting Started tutorial. So check that out for a quick introduction into how contents are structured.
aktuelt
app is combination of blog
from tutorial and start of actual Aktuelt sectionapi.py
files (mapped in tgno/urls.py
)home
and search
apps are init/tutorial leftoversExample urls
Prioritized tasks:
docker-compose
based development setup functional and documentedaktuelt
appaktuelt
app to get a minimal realistic and functional article setup in place (look at existing page for inspiration)We are using Docker via docker-compose for local development. To get started
.env.example
to .env
docker compose up
make createsuperuser
make seed-for-development
to create basic setup with dummy content (not safe to use if content has already been added)Once running you should start an interactive shell in web
container in order to have full access to any Django and Wagtail commands. This can be done via docker compose exec web bash
, or via our shortcut make
/make shell
We recommend this approach since it makes it a lot easier to tinker and learn how things work. To list all commands available try python manage.py
(while in the interactive shell)
And no, we will not try to replicate every possible command in our Makefile.
We use pre-commit for making sure all code conforms to the same formatting. This happens automatically on commit after this first time setup.
pip install pre-commit
or brew install pre-commit
)pre-commit install
Site should follow expected Wagtail and Django patterns if nothing else is mentioned.
publish_scheduled
command every x minutesUse python manage.py test
in container, or make test
locally to run test suite. We generally try to rely on Wagtail and Djange framework as much as possible, but feel free to test custom behaviour/code and add sanity checks.
Having test coverage will be helpful when debugging issues or figuring out how existing code was intended to behave (aka. answering the age old question of, is current behaviour a bug or just an unknown feature?).
This repo is developed and maintained by the Systemstøtte crew at The Gathering. Once we get further along PR will be accepted, for now either apply to join our crew or reach out to us via issues before spending any time on development.