Install new store on Subdomain on different Server then old store

[mc12345678]

Your choice of the second location (on a hosted area or on a local server) but so far sounds all correct, with one exception (perhaps omission). As far as "switching it live", remember that while you're working on your development site, transactions are occurring on the live site. These need to be incorporated into the development site. (Recommendation is to bring that database over to the "development" site and then do all the database mods necessary to restore it to what was modified to make it look the way desired.). See: http://www.zen-cart.com/entry.php?3-...d-of-upgrading

The method discussed above partially outlines (very partial) what is in that faq.

[kwright]

Your choice of the second location (on a hosted area or on a local server) but so far sounds all correct, with one exception (perhaps omission). As far as "switching it live", remember that while you're working on your development site, transactions are occurring on the live site. These need to be incorporated into the development site. (Recommendation is to bring that database over to the "development" site and then do all the database mods necessary to restore it to what was modified to make it look the way desired.). See: http://www.zen-cart.com/entry.php?3-...d-of-upgrading

The method discussed above partially outlines (very partial) what is in that faq.

Thanks mc12345678 for your feedback. I usually do all of my dev on a local host, then upload to production server, import a copy of the db and call it done. Trusting that SSL and email won't have a problem once setup. It's worked in the past for me without a hitch.

However, this particular site is going from ZC 1.3.8a on a shared server to ZC 1.5.4 on a VPS with many additions and changes. I have been testing the new site under a subdomain on the same shared server, but now I want to move that over to the VPS for final testing.

I think as long as I setup and point the A / MX record of the subdomain to the IP of the VPS server where the new ZC is, I'm good to go for final testing.

And yes, I'll have to updated the db once I set the down for maintenance on the old site. Then update DNS to point to the new server and remove the subdomain records...

From the link you suggested, I think what I'm doing should work...what do you think?

[mc12345678]

Thanks mc12345678 for your feedback. I usually do all of my dev on a local host, then upload to production server, import a copy of the db and call it done. Trusting that SSL and email won't have a problem once setup. It's worked in the past for me without a hitch.

However, this particular site is going from ZC 1.3.8a on a shared server to ZC 1.5.4 on a VPS with many additions and changes. I have been testing the new site under a subdomain on the same shared server, but now I want to move that over to the VPS for final testing.

I think as long as I setup and point the A / MX record of the subdomain to the IP of the VPS server where the new ZC is, I'm good to go for final testing.

And yes, I'll have to updated the db once I set the down for maintenance on the old site. Then update DNS to point to the new server and remove the subdomain records...

From the link you suggested, I think what I'm doing should work...what do you think?

The only thing that I see that might be an "issue" is related to the whole pointing the old site to the new site and associated timing. From what I recall reading somewhere, there is a potential caching delay from the old site to the new one, meaning if you speak with the host (or have sufficient access) then perhaps you could have the duration of caching for your current live site reduced so that when it does get transitioned (presumably after or close enough to the longest point of caching that occurs after the point that they make the change) visitors are redirected faster than if no action had been taken...

Oh and there is the issue of PHP differences that could cause an issue if some work is done on a greater PHP version than a destination "system".

As for SSL, it is always possible to test a file or two before committing the site to SSL (done if there is an immediate need to get a site operational or if the SSL hasn't been renewed), email.. Well, ways to test it but might as well use the real software to be sure. :)

Otherwise, I don't see an issue, with the above process... Could be overlooking something. :) Don't know till tried. :)

[kwright]

The only thing that I see that might be an "issue" is related to the whole pointing the old site to the new site and associated timing. From what I recall reading somewhere, there is a potential caching delay from the old site to the new one, meaning if you speak with the host (or have sufficient access) then perhaps you could have the duration of caching for your current live site reduced so that when it does get transitioned (presumably after or close enough to the longest point of caching that occurs after the point that they make the change) visitors are redirected faster than if no action had been taken...

Oh and there is the issue of PHP differences that could cause an issue if some work is done on a greater PHP version than a destination "system".

As for SSL, it is always possible to test a file or two before committing the site to SSL (done if there is an immediate need to get a site operational or if the SSL hasn't been renewed), email.. Well, ways to test it but might as well use the real software to be sure. :)

Otherwise, I don't see an issue, with the above process... Could be overlooking something. :) Don't know till tried. :)

I hear you, but I don't think reducing the TTL will benefit me in this case. I'll flush cache at the registrar too before I change DNS. I usually figure a 12 / 24 hour propagation regardless. PHP ver shouldn't be an issues. I've had it running with 5.4.x.

OK, so I'll give it a go...can't hurt to try! Thanks

[RodG]

I hear you, but I don't think reducing the TTL will benefit me in this case.

Sure it will. :-)

I'll flush cache at the registrar too

Not sure how you'll do that (may be a case of bad terminology). How do you propose to flush the caches of the zillions of other DNS's that could also be holding the 'stale' data?

I usually figure a 12 / 24 hour propagation regardless.

Hmmm, by altering the TTL's ahead of time (so that any/all cached data in any DNS server has the shorter TTL's *before* making any DNS data changes) you can/will reduce this 'propagation' down from many hours to just a few minutes. - Specifically, the duration of the TTL.

I do this (and recommend it to others) whenever I plan any changes to the DNS. The reasons are twofold. Firstly, because it *does* avoid the propagation delays, but I think most importantly, it is a little bit of 'insurance' against accidental mistakes, because if you DO make an error with the data (for example, you accidentally enter the wrong IP address, this error could end up in the DNS caches until the next propagation (or more specifically, until the TTL expires) - In other words, with a long TTL it could take many hours for the 'mistake' to be rectified across the 'net, even if you spotted and fixed it immediately.

With a short TTL the errors/fixes occur within minutes.

Long TTL's and errors can be a real nightmare as you don't have any control of what data any given DNS is going to provide which can result in intermittent/unpredicatble behaviour (either for you, or any potential visitors to the site) - Furthermore, if you don't spot the error when it is first made, it could take up to the 12/24hours before even *you* are made aware of it.

Naturally the TTL's should be 'upped' again after you are sure that everything is in order (I typically wait at least 2 or 3 days before doing this) - The short TTL's cause additional server load, but otherwise no harm, so no rush.

Of course, if you don't make mistakes and you are happy to wait 12/14 hours for any changes to be reflected across the globe that is entirely up to you. :-)

Cheers
RodG

[kwright]

OK, made the changes and it worked with a bit of a tweak. Just wanted to report here for others wanting to do the same thing!

On the server where your live ZC is running, add an A record under the cPanel DNS Zone Editor. The Host Record should be the subdomain you wish to use, example sub.mydomain.com. Leave the TTL at default (14400 which is 12 hours). Type should be A. Points to should be the IP of the servers cpanel where your new ZC will be installed.

On the new server, create a new cpanel account using the same mydomain.com of the old server. Now create the subdomain that you used in the A record (sub.mydomain.com). This takes care of the routing of your subdomain from one server to the other. You can test this by putting a test file under the new subdomain on the new server and verify that you can browse it! Should be very little delay before the changes take affect.

Now, on the new server, install or upload your new ZC as usual, including the db.

Here's the tweak I needed to do in order to view pages and admin via HTTPS on my new server. In your configuration.php, both catalog and admin side, your HTTPS URL will need to be the IP/~username URL to your subdomain and NOT the subdomain alias URL.

Example:
define('HTTP_SERVER', 'http://sub.yourdomain.com'); // non ssl url
define('HTTPS_SERVER', 'https://your account IP/~my-cpanel-account-name/sub'); // ssl url

Now, once all testing is complete, just move ZC from the subdomain folder to the root folder and change both configuration.php accordingly. Then follow the recommendations from https://www.zen-cart.com/entry.php?3...d-of-upgrading

[RodG]

Leave the TTL at default (14400 which is 12 hours).

Why? You really aren't leaving any room for error.

Should be very little delay before the changes take affect.

In this instance there shouldn't be any delay whatsoever. You have defined a brand new host - there isn't going to be any 'stale' data for it anywhere that would cause any delays. HOWEVER, *if* you happen to make a mistake it is now going to take up to 12 hours before it can be fully rectified.

As for the SSL - you can very easily run into trouble here because a certificate for 'mydomain.com' will NOT be valid for 'sub.mydomain.com' (just as it won't be valid for 'www.mydomain.com').

Furthermore, the setting
define('HTTPS_SERVER', 'https://your account IP/~my-cpanel-account-name/sub'); // ssl url

... is generally considered very "unprofessional" and there are only a couple of rare instances where this format would actually be needed - Typically 1) where it is a completely new domain and you wish to work ion the site before it will resolve, and 2) Where you are using a host supplied shared SSL - in which case the 'your account IP' will be your hosts shared server name - followed by the ~my-cpanel-account-name/sub.

If I thought that SSL offered anything more than 'warm fuzzies' and a false sense of security, I would actually avoid a site that presented me with a URL of the type that you have defined. :-)

Apologies for the apparent criticism, your method has obviously worked for you, so one could make a valid argument that there is little or nothing inherently *wrong* with this approach - but IMO it isn't the best approach. If I/we ignore the SSL aspect, you really haven't left any room for possible errors when making the DNS additions/changes - and that is the biggest 'issue' I have here.

I guess it could just be me that occasionally gets things wrong in this regard (dyslexia) - but I hate to admit how many hours I would have wasted over the years "chasing shadows" and waiting for DNS updates before I've been able to move forward. The advanced planning and reducing the TTL's to the absolute minimums allowed by the ISP really has saved me a lot of time, frustration and self annoyance at being so 'stupid' for messing up in the 1st place. ;-)

Ergo, I put this message to you NOT as a criticism as to what you have done, but as a little bit of friendly advice (personal experience) as to how you could possibly save yourself a few headaches in the future (should you ever need to go this path again).

As I stated previously, the reduction in the TTL's is best considered as a form of 'insurance'. It's not essential, but its a bleeding nice thing to have for when things don't go as planned.

Cheers
RodG

[kwright]

Why? You really aren't leaving any room for error.



In this instance there shouldn't be any delay whatsoever. You have defined a brand new host - there isn't going to be any 'stale' data for it anywhere that would cause any delays. HOWEVER, *if* you happen to make a mistake it is now going to take up to 12 hours before it can be fully rectified.

As for the SSL - you can very easily run into trouble here because a certificate for 'mydomain.com' will NOT be valid for 'sub.mydomain.com' (just as it won't be valid for 'www.mydomain.com').

Furthermore, the setting
define('HTTPS_SERVER', 'https://your account IP/~my-cpanel-account-name/sub'); // ssl url

... is generally considered very "unprofessional" and there are only a couple of rare instances where this format would actually be needed - Typically 1) where it is a completely new domain and you wish to work ion the site before it will resolve, and 2) Where you are using a host supplied shared SSL - in which case the 'your account IP' will be your hosts shared server name - followed by the ~my-cpanel-account-name/sub.

If I thought that SSL offered anything more than 'warm fuzzies' and a false sense of security, I would actually avoid a site that presented me with a URL of the type that you have defined. :-)

Apologies for the apparent criticism, your method has obviously worked for you, so one could make a valid argument that there is little or nothing inherently *wrong* with this approach - but IMO it isn't the best approach. If I/we ignore the SSL aspect, you really haven't left any room for possible errors when making the DNS additions/changes - and that is the biggest 'issue' I have here.

I guess it could just be me that occasionally gets things wrong in this regard (dyslexia) - but I hate to admit how many hours I would have wasted over the years "chasing shadows" and waiting for DNS updates before I've been able to move forward. The advanced planning and reducing the TTL's to the absolute minimums allowed by the ISP really has saved me a lot of time, frustration and self annoyance at being so 'stupid' for messing up in the 1st place. ;-)

Ergo, I put this message to you NOT as a criticism as to what you have done, but as a little bit of friendly advice (personal experience) as to how you could possibly save yourself a few headaches in the future (should you ever need to go this path again).

As I stated previously, the reduction in the TTL's is best considered as a form of 'insurance'. It's not essential, but its a bleeding nice thing to have for when things don't go as planned.

Cheers
RodG

Hi RodG,

I appreciate your feedback and observation! All valid points...However, I think you missed the purpose of my original post. This was for TESTING PURPOSES only using a subdomain on a different server.

...I would like to install and test the new Zen Cart on server B, including email and SSL before switching it live...

So, yes, if one were going live with this setup...not the preferred method. That's why I included the link from mc12345678 in my last reply. The link is to the preferred method once testing is done and you want to set your new site live!

Thanks again for all of your input! Got it all worked out!