#18397 closed Cleanup/optimization (fixed)
Change media.lawrence.com examples
Reported by: | Owned by: | Aymeric Augustin | |
---|---|---|---|
Component: | Core (Other) | Version: | 1.4 |
Severity: | Normal | Keywords: | |
Cc: | Danilo Bargen | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
settings.py mentions media.lawrence.com as an example URL at four places:
# Example: "/home/media/media.lawrence.com/media/" # Examples: "http://media.lawrence.com/media/", "http://example.com/media/" # Example: "/home/media/media.lawrence.com/static/" # Example: "http://media.lawrence.com/static/"
Given the already somewhat confusing history and current state of the media/static settings, I recommend we use another site as an example, since from what I understand, the media subdomain is merely a coincidence. Perhaps code.djangoproject.com instead? :)
Will supply a patch if this is a good idea.
Change History (9)
comment:1 by , 12 years ago
Component: | Documentation → Core (Other) |
---|---|
Easy pickings: | set |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 12 years ago
What I mean is this:
"Part of the purpose of introducing the staticfiles app is to make it easier to keep static files separate from user-uploaded files." (Managing static files).
So if we want to distinguish the static files from media (user uploaded) files, then certainly we should not mention media as a subdomain for *static* files. For media files, sure, but not for static files.
Take this URL, for example: "/home/media/media.lawrence.com/media/". 'media' is mentioned three times which makes it really difficult to understand what the setting is referring to. 'If I change this, will I change the subdomain of the site?', etc.
So, while I may agree on lawrence.com not being optimal, what I really think we should change is the media subdomain.
comment:3 by , 12 years ago
Ah - got it. Yes, that's definitely something that should be cleaned up.
So - the summary:
- Change "media" to "static" when we're actually talking about static content.
- Use example.com rather than lawrence.com
- Simplify the directory path so it doesn't keep saying "media" -- e.g., /home/example.com/media would be clearer than the current example.
comment:5 by , 12 years ago
Has patch: | set |
---|
I changed to /var/www/example.com/{static,media}, since you'd only use collectstatic in production and if you need it locally you'd override this with a settings_local or similar. But perhaps that's a bit confusing, too?
comment:6 by , 12 years ago
Cc: | added |
---|
+1 for the /var/www
change.
I added two comments to the pull request https://github.com/django/django/pull/111, after those things are changed, I'd consider the ticket ready for checkin.
comment:7 by , 12 years ago
Owner: | changed from | to
---|
comment:8 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Agreed that we shouldn't be referencing lawrence.com. If nothing else, there's the potential that our default setting is causing increased load on the lawrence.com server.
I'd be inclined to use an intentionally dummy server -- example.com -- rather than djangoproject.com, for exactly the same reason. On top of that, using djangoproject.com could lead to some confusion as to whether a non-django domain can be used. If we stick to a generic placeholder like example.com, it's obvious that the value is meant to be replaced.
The media subdomain isn't a coincidence -- it's a real-life example, with a reasonably common default name. When your site expands, you eventually reach the point where your static media needs to be served from a different box to the rest of your site. When that happens, it's a reasonably common practice to use a subdomain to identify the static media box. 'media' is a common (and obvious) prefix to use.