Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#669 closed defect (fixed)

site table

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


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 and another seperate one on the current site table doesn't allow for this. (or even redirecting to 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 10 years ago by eugene@…

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

comment:2 Changed 10 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 10 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 10 years ago by adrian

  • Resolution set to invalid
  • Status changed from new to closed

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

comment:5 Changed 10 years ago by ian@…

  • Resolution invalid deleted
  • Status changed from closed to 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 Changed 10 years ago by adrian

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:7 Changed 9 years ago by anonymous

  • Component changed from Admin interface to Metasystem
  • milestone set to Version 1.0
  • priority changed from normal to high
  • Severity changed from normal to minor
  • Type changed from enhancement to defect
  • Version set to 0.91

comment:8 Changed 9 years ago by anonymous

  • milestone Version 1.0 deleted

Milestone Version 1.0 deleted

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