How to correct image/reference URLs placed on production once live? #105

Activity

1. mcheck commented on Mar 5, 2014

   

   mcheck

   on Mar 5, 2014

   Author

   More actions

   Ah, it seems that once you change the wp_options sitename, the picture urls form themselves correctly. I wan't having this experience before with staging and branches, possibly because of url rewrites.

   @ericclemmons @EvanK
   Sorry to bother you with this, but a related question is regarding 301 redirects once live. It seems that once the DNS switch has been flipped to point www to the production.domain.com system, we would want to provide 301 redirection to the www address from production as well.

   Or is there some other provision in genesis or best practice for configuring apache once the launch happens? It seems one would not want the user to be able to go directly to production.domain.com any longer...
2. ericclemmons commented on Mar 5, 2014

   

   ericclemmons

   on Mar 5, 2014

   Contributor

   More actions

   Man, that's a good question! We haven't worried about the production. domains because of the no_robots.txt being served up.

   The only good way, IMO, would be to add an .htaccess rule to conditionally redirect all URLs for that host name. Thoughts?
3. mcheck commented on Mar 5, 2014

   

   mcheck

   on Mar 5, 2014

   Author

   More actions

   I guess I should have asked this earlier so here goes :)
   Have you or the rest of the team used genesis in actual production? I don't mean this to sound snarky, it's not. But if I'm the first, I'm happy to help transition us all over some of the humps...

   What I did in this case, so far is to change the apache directives, though changing the htaccess file might be better suited. I just wasn't comfortable changing a universal htaccess file when it would be used in different environments. This is one of the reasons I was advocating different configs per env. We sort of have that with capistrano, but when we deploy the system, it is essentially the same codebase for all envs with code providing different results per environment. I try to work toward the 12factor ideas if possible.

   So what I did was to change the apache configs, I'm happy to entertain doing this at the htaccess level if y'all can give me some help.

   In production, I changed the 003-production.domain.com to this:

   <VirtualHost *:80>
       ServerName domain.com
       Redirect permanent / http://www.domain.com/
   </VirtualHost>
   
   <VirtualHost *:80>
       ServerAdmin webmaster@localhost
   
       ServerName production.domain.com
   
   #    ServerAlias domain.com
       ServerAlias www.domain.com
       ServerAlias *.domain.com
   ...
   

   But it might make more sense to add production.domain.com to the 301 redirect virtual block once it is live?
4. ericclemmons commented on Mar 5, 2014

   

   ericclemmons

   on Mar 5, 2014

   Contributor

   More actions

   We have, last I checked, somewhere over 30+ sites live using this from small to very large.

   Because of the no_robots.txt & fact that we're not publicly linking production., we haven't had the need to explicitly redirect production. to www. once "live". Similarly, we use the .htaccess to redirect non-www traffic to www, or vice-versa as needed.

   As a fail-safe, is removing the DNS entry for production. a valid solution?

   I do like the idea of being able to add more blocks apache for apache specific to the project. Many of the rules that find their way to the .htaccess now belong elsewhere.

   Can you help me understand the problem/solution created with the current setup so we can address it better? I still feel as if we don't share the same workflow/problems.

   Thanks!
5. mcheck commented on Mar 6, 2014

   

   mcheck

   on Mar 6, 2014

   Author

   More actions

   Thanks for the info.

   Can you include or direct me to the .htaccess config that you use to permanently (301) redirect the bare domain.com to www ?

   I don't see how you can not be publicly linking production. The ServerName in the apache2 vhost is production.domain.com. Something I don't understand there.

   I suppose I could remove the production DNS entry, but then, how does one do update/deploys to the production code? I think production.domain.com is used by cap to deploy to prod.

   Happy to help and describe our process/workflow. This following is considering a client that has a running www site, we;re upgrading/migrating it, for instance:

   1. local development on vagrant, modifying files and building theme, etc., committing to repo
   2. provision and deploy to cloud vps (for instance) as staging. push and pull files via local git changes, push and pull db changes with capistrano. This gives us a server we can beat on on see if cloud version acts like our vagrant.
   3. Ready to launch we provision and deploy a production.domain.com, load the db and get ready for launch.
   4. Point bare domain, www to production and we're live!
   5. Changes? Pull production db to local & staging, Make/test changes in local, deploy to staging for remote test. All good? Deploy to production: cap production deploy
   6. Go back to 5 as needed.

   So I want to keep the production machine as a deployable extension of the repo. Local development, remote staging for testing, and production deployable at any time. Isn't that similar to your workflow, too?

   The virtualhost blocks I built for apache are good, I can pull request them if you like. But maybe I should wait until we decide a good strategy for post launch use of production ?
6. ericclemmons

   added this to the v0.2.51 milestone on Jun 12, 2014
7. ericclemmons commented on Jun 16, 2014

   

   ericclemmons

   on Jun 16, 2014

   Contributor

   More actions

   Heads up, I'm working on version 1.0.0 right now, and this will be resolved. Images & all URLs from within WordPress *will be path only, no hostname`.
8. ericclemmons

   closed this as completedon Jun 16, 2014