From 49eac935e01d7af37d965130e4cce4c56ffcec00 Mon Sep 17 00:00:00 2001
From: Vinta Chen <vinta.chen@gmail.com>
Date: Fri, 2 Oct 2026 16:16:35 +0800
Subject: [PATCH] docs: rewrite Web Asset Management category intro

The intro predated the 2026-10-02 audit and did not mention the newly added whitenoise.

Co-Authored-By: Claude <noreply@anthropic.com>
---
 .../data/category_intros/web-asset-management.md  | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/website/data/category_intros/web-asset-management.md b/website/data/category_intros/web-asset-management.md
index 03733638..4403349b 100644
--- a/website/data/category_intros/web-asset-management.md
+++ b/website/data/category_intros/web-asset-management.md
@@ -1,12 +1,15 @@
-Django serves static files only in development, but django-storages puts them and user uploads on S3 or other clouds. Django Compressor bundles CSS and JS.
+Static files can skip a separate server: with WhiteNoise, Django static files are served by your app itself. Uploads go to cloud storage via django-storages.
 
 How to choose:
 
-- Static files and user uploads on S3, Google Cloud Storage, or Azure: django-storages
-- CSS and JavaScript combined and minified from your templates: Django Compressor
+- Static files served by your Django or other WSGI app: WhiteNoise
+- User uploads on Amazon S3, Azure Storage, Google Cloud Storage, or SFTP: django-storages
+- CSS and JavaScript from your Django templates, combined into one file: Django Compressor
 
-django-storages is [a collection of storage backends for Django](https://django-storages.readthedocs.io/en/latest/): Amazon S3, Google Cloud Storage, Azure Storage, and more. Install the extra for your backend, like [`django-storages[s3]`](https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html#installation). Configure it through Django's [`STORAGES` setting](https://docs.djangoproject.com/en/stable/ref/settings/#storages), with the backend's settings under `OPTIONS`. The `default` key stores user uploads, and a `staticfiles` key has `collectstatic` [put your static files on S3](https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html#configuration-settings) too. Django's security docs say to [serve user uploads from a separate domain](https://docs.djangoproject.com/en/stable/topics/security/#user-uploaded-content), not a subdomain of your site.
+WhiteNoise lets your app [serve its own static files](https://whitenoise.readthedocs.io/en/latest/), with no separate web server. It works with any WSGI app, with extra auto-configuration for Django. On Django, switch to its [compressed manifest storage backend](https://whitenoise.readthedocs.io/en/latest/django.html#add-compression-and-caching-support), which compresses your files and gives them hashed names, so browsers can cache them forever. Its docs advise against [pushing static files to S3](https://whitenoise.readthedocs.io/en/latest/#shouldn-t-i-be-pushing-my-static-files-to-s3-using-something-like-django-storages) with django-storages: that adds libraries, configuration, keys, and deploy steps.
 
-Django Compressor [processes, combines, and minifies](https://github.com/django-compressor/django-compressor) the CSS and JavaScript in your Django templates into cacheable static files. It also supports compilers like Sass and LESS. Its maintainer sees it as [an alternative for people who don't want to keep up](https://github.com/django-compressor/django-compressor/discussions/1095) with JavaScript build tools and want one easy setup for development and production. Add `compressor` to `INSTALLED_APPS` and [its finder](https://django-compressor.readthedocs.io/en/stable/quickstart.html) to `STATICFILES_FINDERS`. Then wrap your `<link>` and `<script>` tags in `{% compress css %}` and `{% compress js %}` blocks. In production, its docs [strongly recommend a real cache backend](https://django-compressor.readthedocs.io/en/stable/usage.html). On several servers, or with compressed files on a CDN, use [offline compression](https://django-compressor.readthedocs.io/en/stable/scenarios.html#offline-compression): set `COMPRESS_OFFLINE` and run `manage.py compress` when you deploy. Jinja2 templates work through [its extension](https://django-compressor.readthedocs.io/en/stable/jinja2.html).
+django-storages is a [collection of storage backends](https://django-storages.readthedocs.io/en/latest/) for Django, covering Amazon S3 and S3-compatible services, Azure Storage, Google Cloud Storage, Dropbox, FTP, and SFTP. Each backend has its own settings: to save uploads to S3, for example, set `storages.backends.s3.S3Storage` as the [`default` backend in `STORAGES`](https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html#configuration-settings) and pass its settings under `OPTIONS`.
 
-django-storages and Django Compressor work together. Django Compressor's docs [point to django-storages](https://django-compressor.readthedocs.io/en/stable/remote-storages.html#django-storages) for pushing compressed files to S3, and it saves them to the storage you define under [the `compressor` alias](https://django-compressor.readthedocs.io/en/stable/settings.html#django.conf.settings.COMPRESS_STORAGE_ALIAS) in `STORAGES`.
+Django Compressor [combines the CSS and JavaScript](https://django-compressor.readthedocs.io/en/latest/) that your templates link or inline into one cached file, and browsers can cache that file forever. Wrap the tags in a [`{% compress %}` block](https://django-compressor.readthedocs.io/en/latest/usage.html#examples). By default it compresses during requests, but when you run several servers or [WhiteNoise serves the files](https://whitenoise.readthedocs.io/en/latest/django.html#django-compressor), turn on [offline compression](https://django-compressor.readthedocs.io/en/latest/scenarios.html#offline-compression) and run its `compress` command on deploy.
+
+Keep user uploads out of your static files. WhiteNoise [isn't suitable for serving them](https://whitenoise.readthedocs.io/en/latest/django.html#serving-media-files): uploads served from your app's own domain are a security risk, and local disk makes scaling across machines harder. Its docs point to django-storages instead. Django's own docs recommend serving uploads [from a separate domain](https://docs.djangoproject.com/en/stable/topics/security/#user-uploaded-content), like usercontent-example.com for example.com, not a subdomain.