Printable View
Trying to get a consensus on best practices for testing upgrades to newer versions of ZC - is it better to (1) use the current database with a saved backup of it (2) use a renamed copy of the database or (3) use a test only database with sample data when testing new versions. Please include your reason(s) for the method you practice.
Thanks,
Goldbuckle
I'm going to go based on the "testing a new version of ZC" as the basis for my response. Testing an older DB against a new ZC would be a whole different story.
I would use either a local server setup or something "above the root" on my current site's server (my choice) so that I could isolate the trial and use the highest possible suitable version of PHP for testing. Keeping the site separate from the existing where PHP is concerned is important so as not to break your current version. Using my current site's server allows me to also test the new ZC's compatibility with the server that will be hosting it.
Testing with a database that contains anything other than the newest release setup is asking for trouble IMHO. if anything is in the older database and not compatible with the newer ZC, problems arrive immediately. Collation and an incorrect datetime value of 0000-00-00 00:00:00 come to mind immediately. Yes, they are easily fixed but, why bother.
Load everything and all the demos. Having them there let's you see operations you might not encounter on every site. Just a more thorough look.
In the case of templates, clone them before making any changes so that you have a fall back setting without having to restore a backup as some hosts charge for that. For other file changes or mod additions, you can quickly zip the area the change/mod is going to affect and use that as a restore point. Doing so on each change may be tedious but also may prevent a complete do over.
$0.02
Primer:https://www.zen-cart.com/showthread....90#post1383990
As a non-professional developer, with no Linux experience, I develop locally on a Windows PC using Laragon, phpStorm and Beyond Compare.
I use the latest php available (8.1) which gives an early heads-up on php deprecations before the hosting upgrades automatically and breaks something out of the blue.
Either
a) you setup up a clone of your existing site and merge in the latest files, then upgrade the database to match what those new files may be expecting to find.
or
b) you install the new/current version, import your real database and upgrade it, ensure it works, then merge in your customisations.
The end result should be identical but the pain in-between, probably not. New files looking for new things in the old database=multiple white screens of death.
I think the second option is the easiest for non-pro developers as it is easier to spot when you have broken something and in the process of adding in your customisations you will decide that a lot of the fluff you added into your real site in the past really is not necessary: it's a spring clean, and now you know more, you can add copious notes to the modifications and do things with overrides and observers.
Any issues with the imported real database that you can discover can either be fixed in the real database so they are not a problem on the real upgrade/final import/upgrade, or you can build up a list of SQL queries to fix them all at once at upgrade time.
Once all is done locally, set up this test site on your real server (separate from your real shop) so you can test it in the same environment. The pros will say you should develop on the same environment as the real site, but I think I have had two issues that cropped up due to not doing that in 10 years, from 1.39-1.58, so in my opinion it does not outweigh the convenience of developing locally (not uploading every file change).
With the upgrading as the premise, I agree with option b as presented by Torvista. As with testing a new release, keeping the upgrade in a folder that can be a separate PHP from the current site.
I also use the Mod List by swguy as a quick aid for helping with the upgraded database. Many times, old mod files or changes to the DB are forgotten and the Mod List will "complain" that it can't find a setting or show a setting that is not in configuration.
Just a little helpful extra way to find out someone once installed or partially removed a mod that wasn't remembered or documented.
If you're doing an upgrade and building a test version, pull a copy of your current database and use that. I assume you're doing testing on a local server or one that's separate from live. Here's how to pull a database backup:
https://docs.zen-cart.com/user/runni...-your-database
If you're on the same server, you will want to copy the database to a new name (like "test").
You can refresh your test database with a copy of live at your convenience; just remember to re-run zc_install, and re-apply any SQL patches you did during the upgrade.
If you do the test in a separate folder on the live server and the live version is in the root directory rather than a separate folder, once the test site checks out can you easily move that test site out of the test folder and to the root directory to overwrite the live site or would you go through the process all over again installing in the root?
And if I use the current database with a backup copy saved locally, is it safe to use the database on the live server on both the live site and the test site folder simultaneously?
Quote:
Originally Posted by dbltoe
> If you do the test in a separate folder on the live server and the live version is in the root directory rather than a separate folder, once the test site checks out can you easily move that test site out of the test folder and to the root directory to overwrite the live site
That's fine.
> And if I use the current database with a backup copy saved locally, is it safe to use the database on the live server on both the live site and the test site folder simultaneously?
No. Use two separate databases, since your upgraded version may be different from live (say 1.5.7 test vs 1.5.6 or 1.5.5 live). Also you want the ability to make template changes (try a different template; try different settings) and not have them show up live.
The whole point of a test site is that even if you botch things, it doesn't affect live. And that means two separate databases.
I am using database with this software