# foundation.mozilla.org **Repository Path**: mirrors_mozilla/foundation.mozilla.org ## Basic Information - **Project Name**: foundation.mozilla.org - **Description**: Mozilla Foundation website - **Primary Language**: Unknown - **License**: MPL-2.0 - **Default Branch**: main - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2020-08-22 - **Last Updated**: 2026-09-19 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # foundation.mozilla.org The Mozilla Foundation site, now live at mozillafoundation.org (repo name predates the domain change). See [foundation_cms/legacy_apps/README.md](foundation_cms/legacy_apps/README.md) for the Mozilla Festival and Donate site specifics. ## How this repo is organized This is a Django/Wagtail monorepo. Most of the site runs on a "redesign" that replaced an older ("legacy") build in 2025. The two aren't a clean 50/50 split, they're asymmetric: - **Redesign is the mainline codebase.** Its backend (page models, blocks, templates) lives directly in `foundation_cms/`, alongside everything else, not in a separate app, because it isn't a carve-out, it's just how the project works now. Its frontend is a separate yarn workspace at `frontend/redesign/` (esbuild, Vitest, Playwright/Percy), documented in [frontend/redesign/README.md](frontend/redesign/README.md). - **Legacy is the older code**, kept because it still powers a couple of standalone site sections (see [foundation_cms/legacy_apps/README.md](foundation_cms/legacy_apps/README.md) for which ones). Its backend lives in Django apps under `foundation_cms/legacy_apps/`, and its frontend is a separate yarn workspace at `frontend/legacy/`. Both are documented together in that same README. Everything else in this README (env vars, Docker/invoke setup, Python testing, deployment) applies to the whole project regardless of legacy or redesign. ## Getting started Before you start working on the project, be sure to read this README and the linked docs. - [Setup with Docker](#how-to-setup-your-dev-environment-with-docker) - [Environment Variables](docs/environment_variables.md) - [Local development](docs/local_development.md) - [Engineer Workflow](docs/workflow.md) - [OPS and Heroku Settings](docs/ops_heroku_settings.md) - [Scheduled Task](docs/scheduled.md) - [Stack](docs/stack.md) - [Upgrading Wagtail](docs/upgrading.md) - [Redesign Frontend](frontend/redesign/README.md) - [Legacy Apps](foundation_cms/legacy_apps/README.md) ## How to Setup your Dev Environment with Docker **Requirements**: Docker ([Docker Desktop](https://www.docker.com/products/docker-desktop) for macOS and Windows or [Docker Compose](https://docs.docker.com/compose/install/) for Linux), [Python 3](https://www.python.org/downloads/) with the [invoke](https://www.pyinvoke.org/installing.html) package installed globally, and [git](https://git-scm.com/). ### Installing Invoke We recommend that you install Invoke using [pipx](https://pypi.org/project/pipx/), but any Python package manager should work (pip, poetry, etc). ### Check your environment - `docker run hello-world`. - `invoke --version` should return 0.22.1 or higher. ### Setup steps Run the following terminal commands to get started: - `git clone https://github.com/MozillaFoundation/foundation.mozilla.org.git` - `cd foundation.mozilla.org` - `inv new-env` You're done :tada: This task creates a `.env` that is in charge of managing your environment variables while running Docker. The installation will take a few minutes: you need to download images from the Docker Hub, install JS and Python dependencies, create fake data, migrate your database, etc. When it's done, run `docker compose up`, wait until the static files to be built, and go to `0.0.0.0:8000`. You should have a local working version of the foundation site with fake data. When you want to stop, do `^C` to shut down your containers. Once the webserver is running, you can log in to the admin site at http://localhost:8000/cms/. A superuser will have been created with username `admin` with password `admin`. To catch up on new dependencies, migrations, etc. after initial setup, you can use the `inv catch-up` command. To get a full new environment with a new database, run `inv new-env` again. Use `inv -l` to get a list of all the available invoke commands. More information on how to work with Docker and how to manage Python dependencies are available in the [local development](docs/local_development.md) part of the documentation. ## Environment Variables Environment variables are loaded from a `.env` file in the project root (gitignored) for local development, and must be set in [Heroku config vars](https://devcenter.heroku.com/articles/config-vars) for staging and production. See `foundation_cms/settings/base.py` for the full list with defaults, or [docs/environment_variables.md](docs/environment_variables.md) for the full reference table. --- ## Code style To ensure a consistent code style and quality, we use linters and formatters. `inv lint`/`inv format` below are a convenience wrapper that run everything (Python, HTML, and both frontends' JS/SCSS) inside Docker in one go. CI itself doesn't use `inv` though, it runs the underlying tools directly per workspace (see `.github/workflows/lint.yml`). For faster local iteration on just one frontend's JS/SCSS directly, use the workspace-specific commands documented in [frontend/redesign/README.md](frontend/redesign/README.md) or [foundation_cms/legacy_apps/README.md](foundation_cms/legacy_apps/README.md) instead. ### Linting To check the code base for quality and style issues run `inv lint`. This will run all configured linters. You can run the linters individually with, e.g. `inv lint-js` for JavaScript only. Check available commands with `inv -l`. ### Formatting If `inv lint` shows linting errors you can try running `inv format` to fix style issues. `inv format` should automatically fix most formatting issues. There might be some linting issues that can not be fixed automatically. ## Testing ### Unit tests When relevant, we encourage you to write tests. You can run the tests using `inv test`. This will run the full test suite. To run only a subset or a specific Python test, you can use following command: ```console inv test-python --file path/to/file.py ``` The `test-python` command also support flags for turning increased verbosity on/off (`-v`) and for running tests in parallel (the `-n` option). To run tests with 4 parallel processes and increased verbosity, use: ```console inv test-python -v -n 4 ``` The `-n` flag also supports the `auto` value, which will run tests with as many parallel cores as possible. For more info, consult the [pytest-xdist docs](https://pytest-xdist.readthedocs.io/en/stable/distribution.html). See also [the Django docs on running tests](https://docs.djangoproject.com/en/4.1/topics/testing/overview/#running-tests). There is no JS unit test framework set up for the legacy frontend. The redesign frontend has its own Vitest suite (see [frontend/redesign/README.md](frontend/redesign/README.md#unit-testing-vitest)). The legacy frontend also has its own Playwright integration, URL-checker, visual regression, and accessibility test setup (see [foundation_cms/legacy_apps/README.md](foundation_cms/legacy_apps/README.md#testing)). --- ## Frontend commands - The frontend is composed of two yarn workspaces defined in a root `package.json` file. The two workspaces are located in `frontend/legacy` and `frontend/redesign`. Running `yarn` commands from the root will trigger the root scripts defined in the root `package.json` and are helper scripts defined to run for all workspaces. To run `yarn` commands from an individual workspace, you can `cd` into the workspace, or you can use workspace syntax from the root directory (for exapmle: `yarn workspace redesign lint`) Frontend-specific dev workflow, linting, and formatting commands are documented per workspace: - Redesign: [frontend/redesign/README.md](frontend/redesign/README.md) - Legacy: [foundation_cms/legacy_apps/README.md](foundation_cms/legacy_apps/README.md) ## Gotchas As this is REST API and CMS built on top of Django, there are some "gotcha!"s to keep in mind due to the high level of magic in the Django code base (where things will happen automatically without the code explicitly telling you). #### **DEBUG=True** The `DEBUG` flag does all sorts of magical things, to the point where testing with debugging turned on effectively runs a completely different setup compared to testing with debugging turned off. When debugging is on, the following things happen: - Django bypasses the `ALLOWED_HOST` restrictions, which again can lead to `400 Bad Request` errors in `DEBUG=False` setting. - Rather than HTTP error pages, Django will generate stack traces pages that expose pretty much all environment variables except any that match certain substrings such as `KEY`, `PASS`, etc. for obvious security reasons. - ...there are probably more gotchas just for `DEBUG` so if you find any please add them to this list. ## Translations Translations of UI strings (from the Django and React apps) are stored in [the fomo-l10n repository](https://github.com/mozilla-l10n/fomo-l10n). Translations are happening in Pontoon, in multiple projects: [Foundation website](https://pontoon.mozilla.org/projects/mozilla-foundation-website/), [\*Privacy Not Included](https://pontoon.mozilla.org/projects/privacy-not-included/) and [Mozilla Festival](https://pontoon.mozilla.org/projects/mozilla-festival/). The latest source strings are regularly exposed to Pontoon by a Localization PM using the following process: ### Initial setup: - Clone the [`fomo-l10n`](https://github.com/mozilla-l10n/fomo-l10n) repository locally. - Set the `LOCAL_PATH_TO_L10N_REPO` variable in your `.env` file. Use the absolute path to your copy of the `fomo-l10n` repository and include the trailing slash. E.g. `LOCAL_PATH_TO_L10N_REPO=/Users/username/Documents/GitHub/fomo-l10n/` ### Exposing latest source strings: - Make sure your local repositories of `fomo-l10n` and `foundation.mozilla.org` are matching the latest revision from main. - Run `inv docker-makemessages` from your `foundation.mozilla.org` repository. - Files should have been updated in your `fomo-l10n` repository. You can now create a pull-request. ### Getting the latest translations for local dev Latest translations are uploaded to S3. To get them, run: - `curl -o translations.tar https://foundation-site-translations.s3.amazonaws.com/translations.tar` - `tar -C foundation_cms -xvf translations.tar` You don't need to run `compilemessages` and it works for both pipenv or docker workflows. The `translations_github_commit_[...]` file from the archive is only used for debug purposes on Heroku. It can be safely deleted if needed. ## Contributing We love contributors, but the team maintaining this project is small and not structured to significantly support new and inexperienced contributors. If there's an unassigned issue that catches your eye, feel free to open a PR for it, but keep in mind our support will be limited. We usually don't have the capacity to walk you through the process of spinning up the project, opening a PR or describing what the solution to the issue could be. See also: [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).