Opened 11 years ago

Closed 11 years ago

Last modified 10 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: UI/UX:

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 Changed 11 years ago by eugene@…

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

comment:2 Changed 11 years ago by hugo

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 Changed 11 years ago by Sune Kirkeby <sune.kirkeby@…>

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 Changed 11 years ago by Adrian Holovaty

Resolution: invalid
Status: newclosed

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

comment:5 Changed 11 years ago by ian@…

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 Changed 11 years ago by Adrian Holovaty

Resolution: fixed
Status: reopenedclosed

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

comment:7 Changed 10 years ago by anonymous

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

comment:8 Changed 10 years ago by (none)

milestone: Version 1.0

Milestone Version 1.0 deleted

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