redirect URL for gluejar.com, etc. about regluit HOT 10 CLOSED

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

from regluit.

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?

from regluit.

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.

from regluit.

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

from regluit.

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

from regluit.

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.

from regluit.

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

from regluit.

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?

from regluit.

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

from regluit.

Coolio, will do.

from regluit.