redirect URL for gluejar.com, etc.

[thatandromeda]

I've migrated the content of the gluejar.com site over to a Django thing, so we can shut down that piece of infrastructure and safely ignore it, as well as maintain gluejar.com more easily.

The code is in the gluejar_dot_com branch. Before I do a PR I want to talk domain redirects.

http://www.fir3net.com/Django/how-to-serve-multiple-domains-from-within-a-single-django-project.html was the most comprehensible thing I found, but I don't grok Apache.

I've set up gluejar_dot_com/urls.py so that all of the gluejar.com urls are being served right now from {{ base }}/gluejar_dot_com/{{ whatever }}, in hopes that that will make redirects straightforward. Mapping {{ base }}/gluejar_dot_com/{{ whatever }} to gluejar.com/{{ whatever }} will preserve the link structure on our existing site, because cool URIs don't change.

I'd like to make sure this is sane before issuing the PR -- I want the code to be such that when it's merged, all that needs to happen is the apache, cname, whatever, etc. work for the domain name.

[thatandromeda]

FYI after the merge, push to production, and URL redirect there are a few more things that I will need to do:

• populate the Events database
• incorporate analytics
• hibernate old gluejar.com site

[rdhyee]

I don't know all the details involved in hosting gluejar.com on production using the same instance either. You asking me to start to figure them out?

[rdhyee]

What I see so far. I've been looking at master...gluejar_dot_com and gluejar_dot_com...master and http://www.fir3net.com/Django/how-to-serve-multiple-domains-from-within-a-single-django-project.html

1. Can you merge master into gluejar_dot_com to make it easier to see what's being changed? (gluejar_dot_com...master is not empty right now)

2. Are you trying to emulate the directory structure in http://www.fir3net.com/Django/how-to-serve-multiple-domains-from-within-a-single-django-project.html -- one thing is that domain1 and domain2 are siblings whereas gluejar_dot_com (our domain2) is a child of unglue.it (our domain 1) in terms of file structure.

[eshellman]

maybe it's easier to just spin up a tiny-tiny instance and run a separate project

[rdhyee]

I tend to agree that it's better to run some tiny, tiny instance just for gluejar.com.

[thatandromeda]

Hate to throw the hosting part of the puzzle at you but I don't know enough about AWS or Apache to even know where to begin...

As for separate instances -- right now there are some parts of gluejar_dot_com that are linked to regluit (contact form reuses feedback form handling, uses user logins to populate email field in contact form, uses the admin interface so that our existing is_staff accounts can manage the site). Would putting it on a separate instance require these to be separated out all the way? That seems not DRY but otherwise fine for feedback handling, not important for email address prefilling, and kind of annoying for the staff accounts as we'd have to set up extra accounts just for this site.

File structure: does the current git repo give me any choice in the matter?

merge from master: duh, yes, good point, thank you. Running tests now.

[eshellman]

Remember that logins are tied to cookies and those won't carry over to a different domain.

[thatandromeda]

If logins won't carry over I guess there's no longer any good reason for gluejar_dot_com and regluit to be tied together at all. Shall I make gluejar_dot_com an entirely separate repo? What's easiest for deployment?

[rdhyee]

In this case, we should make gluejar_dot_com a separate repo and write gluejar.com as a standalone django project.

[thatandromeda]

Coolio, will do.