#669 closed defect (fixed)
site table
| Reported by: | Owned by: | Adrian Holovaty | |
|---|---|---|---|
| Component: | Metasystem | Version: | 0.91 |
| Severity: | minor | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
there is currently no way to edit the site table from the admin gui.
I also have a question if this table would be better as a setting in the settings file, and if it should be a URL prefix, not just a domain name.
the reasoning is as follows:
- you would be having a single app running in product/state/dev environments all with different hostnames (possibly different site-ids)
- it is 'another' thing to remember when you change your hostname that your site runs on.
- some sites would be hosted 'inside' a domain.. ie.. you could have one application running as http://foobar.example.com/blah and another seperate one on http://foobar.example.com/zxy the current site table doesn't allow for this. (or even redirecting to foobar.example.com I think)
another option would be to use the 'host:' header on the incoming request, and being able to just use that. having this as the 'default' option would be the one offering the least surprise. I would think
Change History (8)
comment:1 by , 19 years ago
comment:2 by , 19 years ago
The host header is already available in the request as HTTP_HOST. So it might be a good idea to populate the template context with it if DjangoContext is used - as a variable named HOST. That way templates can just reference the host the user provided to reach the website.
But on the other hand this fiddles a bit with the idea of "canonical URLs" - if your site has two hostnames by which it is reached, only one should be the main one (that's the idea of the CommonMiddleware where the www. can be prepended automatically if missing). So maybe we still need the sites table - so that the system can decide _what_ host to use if there are different ones. Maybe it would be better to populate the HOST variable of the DjangoContext with the domain from the sites table.
The prefix stuff might be better placed into the urlpatterns, see #672.
comment:3 by , 19 years ago
You can't get rid of the site-table, because flatfiles have a foreignkey to it. But, it would be nice with the possibility of overriding site.domain with settings.SITE_URL when running development.
comment:4 by , 19 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
Please open a new ticket with a specific problem/bug/idea. This is very broad.
comment:5 by , 19 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
The problem is:
there is currently no way to edit the site table from the admin gui.
and I think there should be.
the desired resolution would be:
making it so admin can edit (but not delete) the record.
comment:6 by , 19 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
comment:7 by , 18 years ago
| Component: | Admin interface → Metasystem |
|---|---|
| milestone: | → Version 1.0 |
| priority: | normal → high |
| Severity: | normal → minor |
| Type: | enhancement → defect |
| Version: | → 0.91 |
I like 'host:' header idea. It allows to use content distribution networks (like Coral CDN) seamlessly.