You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have to run collectstatic in order to move all static files into a single location. This makes an upfront startup cost, and occasionally means that incorrect static files are available.
We have already added a small workaround to make symbolic links instead of copying files to reduce disk space impact on some platforms.
Expected behavior
We should read and serve static files directly from their directories to avoid having to run collect static.
Possible implementations:
Use the WhiteNoise Django Middleware to serve static files
Replicate the finders mapping behaviour at startup to build the static files map from the WhiteNoise Django middleware, but keep serving static files from the top level WSGI application, so we avoid Django overhead for static file serving
Open Questions:
For serving from behind Nginx, we could either just proxy the static endpoint and let Nginx's caching handling serve up the file after it has first been requested
Alternatively, we could require that servers using Nginx still run collectstatic and serve the files directly
Observed behavior
We currently have to run collectstatic in order to move all static files into a single location. This makes an upfront startup cost, and occasionally means that incorrect static files are available.
We have already added a small workaround to make symbolic links instead of copying files to reduce disk space impact on some platforms.
Expected behavior
We should read and serve static files directly from their directories to avoid having to run collect static.
Possible implementations:
Open Questions:
User-facing consequences
Needs #7791 as a prerequisite
The text was updated successfully, but these errors were encountered: