Opened 19 years ago

Closed 19 years ago

Last modified 18 years ago

#669 closed defect (fixed)

site table

Reported by: ian@… 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:

  1. you would be having a single app running in product/state/dev environments all with different hostnames (possibly different site-ids)
  1. it is 'another' thing to remember when you change your hostname that your site runs on.
  1. 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 eugene@…, 19 years ago

I like 'host:' header idea. It allows to use content distribution networks (like Coral CDN) seamlessly.

comment:2 by hugo, 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 Sune Kirkeby <sune.kirkeby@…>, 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 Adrian Holovaty, 19 years ago

Resolution: invalid
Status: newclosed

Please open a new ticket with a specific problem/bug/idea. This is very broad.

comment:5 by ian@…, 19 years ago

Resolution: invalid
Status: closedreopened

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 Adrian Holovaty, 19 years ago

Resolution: fixed
Status: reopenedclosed

(In [1119]) Fixed #669 -- core.Site objects are now editable in the admin

comment:7 by anonymous, 18 years ago

Component: Admin interfaceMetasystem
milestone: Version 1.0
priority: normalhigh
Severity: normalminor
Type: enhancementdefect
Version: 0.91

comment:8 by (none), 18 years ago

milestone: Version 1.0

Milestone Version 1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top