We made some changes early on to our cart that kept us from applying the point releases and upgrades.
Currently we're sitting at 4.02 (MVE) and want to move all the way to current.
The question is whether to "fix" the current shop and then upgrade though all the releases - or create a new app install of the latest version and migrate data.
Ideally we could create a new server and repoint our IP after migrating the data from the live store to keep our downtime to a minimum.
we need to upgrade too from 4.3.9 to latest please let me know if recommend us
If you just want to update from 4.3.9 to the latest version, and you're not moving to a new server, using the built-in upgrade center should work just fine for you. Backup your files and db first. The backup center makes its own backups prior to starting the upgrade process, but I prefer to err on the side of safety.
thanks for replying kellen but the developers did some core files changes and we not able to upgrade, is that somewhere you can help ?
I probably could, but there are a lot of others far more qualified and more efficient on those aspects than I am. Besides, I'm not really looking to take on any additional projects at this time. I mostly just maintain my own stores and do a few side projects for friends. I'm more of a sys admin who just digs into code only when I absolutely have to (I'm not very good at that stuff and don't particularly like doing it... hehe). You need someone who's more of a coder/developer/integrator.
Tbirnseth (one of the guys that replied in this thread and long time CS-Cart guru) would probably be a very good person to talk with.
If you have a lot of core code modifications on 4.3.9, then your developer did you a disservice. Cs-cart has reached the point of maturity that almost everything can be accomplished without core changes (there are exceptions). However it is more of a pain in the ass and takes longer to do so. But true cs-cart developers should be able to do development for you using cs-cart best practices. These best practices include:
1) using language variables
2) using both php and template hooks where they exist
3) using pre/post controllers where php hooks don't exist
4) using template 'overrides' when template hooks don't exist
But do note that at major version releases (like 3->4) even best-practices won't save your custom development without review and re-development.
If you have lots of custom development, just stay at the version you're at until you absolutely need to go forward. Then do a store import and redevelop your custom changes using best practices as you go forward from that point (write off the previous development).
When an override template file is discovered (the overrides directory path), it is used if it is non-empty (I.e. {$content|trim}). If that file contains hooks they will be honored just like the original file. The template override happens before any of the template code is executed.
Your template files should be in design/backend/templates/addons/[addon_name]/overrides/[template_path_to_override_relative_to_backend/templates]
if the override your discussing is a hook (I.e. file.override.tpl) then again, it is used if not empty and hooks are also honored within it. But note that any (I think) existing 'pre-hooks' for that hook are discarded and only 'post-hooks' remain unless they happen in a lower priority controller.