Forums

Development to Live Environments :: rsync

Permalink
I've run into a little trouble bringing a fully live site back into a WAMP environment without losing some stuff. It's a young site so I can solve it through rebuilding - but I'm concerned about successfully doing localhost development and pushing to a live site (and back again) without a hitch. It's just me, no need for subversion control (for now). I've heard rsync is the way to go. Can somebody drop a little info gem about this process and what they've done to make it work seamlessly?

Thank you,

Rick
Ricalsin
 
triplei replied on at Permalink Reply
triplei
my typical process is something as follows for launching a site:

* clear cache on staging site
* export the database from the staging site
* rsync files using something like
rsync -avz /path/to/local/ user@live-domain.com:/home/path/to/live/public_html/

That should copy over all the assets, theme, packages, blocks, etc. If you have your c5 install localized on your live server, you may not want to copy that folder over.
* import database onto the live site
* make sure the config/site.php file reflects the live environment

let me know if you want clarification on any of the steps though and I'll do my best to help out.

Cheers
Ricalsin replied on at Permalink Reply
Ricalsin
Hopefully this is long enough to answer it in one shot. Thanks for your time.

I'll pick up the rsync code when I look into it deeper. I'm sure it's straightforward.

I was wanting to use sub-domains to host a c5 plug-in (essentially) for other websites to use it as an addition to their existing company website (with possible migration into one at a later date).

C5 localized, to me, means within a folder off the root where the site's files pull from it - the "BASE_URL" and "DIR-REL" values in the site.php. I will need that scenario for each sub-domain folder off the root. Like:

root
  secondaryRootCompanyName1
    index.php
    c5
      concrete-the update-able core
  secondaryRootCompanyName2
    index.php
    c5
       concrete-the update-able core
and so on...


So I would WAMP in the localhost inside properly named folders and it should translate - but that's a bit of an unknown for me right now. Somewhere, C5 must write the BASE_URL and DIR_REL into the constant __FILE__ but I don't know where. I know this because you can change the site.php file and the __FILE__ constant won't enable the code to find what it's looking for IF you happened to change those site.php files (for any reason). (It must be in the initial build.)

Knowing that things might migrate, I would like to understand and control the possibility of changing the file nomenclature and still keep the logic together.

Thanks for your thoughts.

Rick
triplei replied on at Permalink Reply
triplei
Hmm, maybe I'm not quite following what you are trying to accomplish. Are you planning on doing c5 installs for each sub-domain? (ie will each sub-domain have it's own database?). If that's the case, there are ways to get all the installs to share the same /concrete/ file so you only have one copy of that on the server.

Another thing you may need to look into is the licensing for the module you are trying to use on multiple sites if it's one from the marketplace.
Ricalsin replied on at Permalink Reply
Ricalsin
Yes, but I am a little way off from that right now. I'm still trying to see if my idea is viable. If it is, I would be concerned about giving the core software work away or into the hands of a third party - which would be required in order to get it hosted so as to share the core files. Furthermore, if it is viable, then paying for multiple licenses is not something I would care to try and save money on. I'd rather the developer get his share.

I realize (now) the magical constant __FILE__. What I'm troubled by is that the links to files that have been uploaded (by customers) to a website are broken (found but corrupted and un-viewable) when the site is migrated (along with the file folder). Is there a reason or this?