X-Cart forums

[cflsystems]

It is best to patch manually then restoring original files - if you made undocumented changes to them you may not be able to apply this changes again after upgrade. Just run the upgrade - it will show a report first and will not modify any files. If you get anything else than "OK" or "Already patched" do not proceed further. First you need to manually patch files and then you can run the upgrade again

[Ana]

I did an upgrade last night in a test environment and I have to say, in the 7 years I've been using X-Cart, this one went the most smoothly of all upgrades.

I'm still testing the functionality of the store and will be for a few days to ensure all is working properly but so far, so good.

Thanks Qualiteam for making life a bit easier this time around.

Ana

[Ana]

Originally Posted by Mr. G

Sergey, in the very first sentence of the 441 to 444 Upgrade Notes, it says, "If any hot fix was applied to X-Cart, it is recommended to uninstall this hot fix to reduce the possibility of an unsuccessful upgrade." Please clarify what a hotfix is. Is a hotfix a patch? QT has applied the patches as listed in the attached doc. I have made changes as listed there. Do I need to uninstall/revert each of these before doing the upgrade?

Also, assuming that my 3rd party modules (shown below) are 4.4.4 compatible, do they still need to be uninstalled before the upgrade?

I too had applied hot fixes, however, I didn't uninstall them. They rejected on the first file verify and I went into the files and manually edited them. Most of the edits were nearly identical to what the hotfix had done. After manually upgrading files, I removed them from the upgrade files.lst and ran the upgrade again. So far, I have not seen any ill effects from doing it in this manner.

As for as the 3rd party mods, I have the CheckoutOne mod installed and didn't remove that prior to upgrade. Those files that were changed with the mod rejected and I upgraded them manually as well.

I'm still testing the site to make sure all is functioning properly and probably will continue testing for a few days.

Ana

[Ana]

Originally Posted by Mr. G

oops, didn't refresh. Reading...

Do not do the upgrade on a live site. Copy your database over to a test database and copy your existing site to a test environment. That way, if anything goes wrong, your bread and butter is still working.

I posted a link in this thread earlier that leads to a topic specifically on upgrading.

Edit-added link: http://forum.x-cart.com/showpost.php?p=191473&postcount=1

Check it out, there is useful information in there.

[cherie]

Official patches from your File Area should not need to be removed or worked around, such as the security patches and the recent USPS patches. Please, X-Cart, consider integrating checks for these patched files in the upgrade.

[cflsystems]

This is not new and it's been asked few times and still not fixed. When running the upgrade from admin the screen after the initial files check has this at the bottom

Tick here to continue upgrading regardless of the found problems

which is checked by default. "Apply patch" and "Go back" buttons are too close to each other and one can easily hit the wrong button. Applying the patch when there are "could not patch" errors will result of not all files being patched and the database not patched as well. This should not be checked by default and the "Apply patch" button should be disabled unless box is checked.

For your own safety do this and keep it in there. Open "admin/main/patch_apply.tpl" and at the top of the file insert this

<script type="text/javascript">
//<![CDATA[
{literal}
var agree_checkboxes = ['try_all'];
function check_agree(form) {
  for (var i = 0; i < agree_checkboxes.length; i++) {
    var c = form.elements.namedItem(agree_checkboxes[i]);
    if (c && !c.checked)
      return false;
  }
  return true;
}
function patch_agree(o) {
  var valid = true;
  for (var i = 0; i < agree_checkboxes.length && valid; i++) {
    var c = o.form.elements.namedItem(agree_checkboxes[i]);
    if (c && !c.checked)
      valid = false;
  }
  $('input[name=submit]').button(valid ? 'enable' : 'disable')
  return true; 
}
{/literal}
//]]>
</script>

then find

<form action="patch.php" method="post">

and replace with

<form action="patch.php" method="post" onsubmit="javascript: return check_agree(this);">

then find

<label for="try_all">{$lng.lbl_tick_here_to_apply_patch}</label><input type="checkbox" id="try_all" name="try_all" /><br />

and replace with

<label for="try_all">{$lng.lbl_tick_here_to_apply_patch}</label><input type="checkbox" id="try_all" name="try_all" onclick="javascript: patch_agree(this);" /><br />

then find

<input type="submit" value="{$lng.lbl_apply_patch|strip_tags:false|escape}" />

and replace with

<input type="submit" name="submit" value="{$lng.lbl_apply_patch|strip_tags:false|escape}"{if $could_not_patch ne "0" and $mode ne "sql"} disabled="disabled"{/if} />

Done.

Come on QT, this is your own code, just copy/paste, and you can't implement it to something as important as running a patch

[cflsystems]

So got my first 4.4.3->4.4.4 live upgrade - few files to manually patch and no problems at all with the upgrade. Smooth and it looks like all works just fine. Couple new shipping methods were activated after the upgrade but I assume these were newly added shipping methods by the upgrade (still they should be added as disabled). Over all positive experience with the upgrade. Looks like 4.4.4 is way better compare to 4.4.3, I even think a little bit faster. One warning for anyone using jquery from CDN (like Google and others) - make sure you are loading 1.6.2 or OPC and and some admin features depending on it will not work

[seyfin]

Originally Posted by cflsystems

This is not new and it's been asked few times and still not fixed. When running the upgrade from admin the screen after the initial files check has this at the bottom



which is checked by default. "Apply patch" and "Go back" buttons are too close to each other and one can easily hit the wrong button. Applying the patch when there are "could not patch" errors will result of not all files being patched and the database not patched as well. This should not be checked by default and the "Apply patch" button should be disabled unless box is checked.

For your own safety do this and keep it in there. Open "admin/main/patch_apply.tpl" and at the top of the file insert this

<script type="text/javascript">
//<![CDATA[
{literal}
var agree_checkboxes = ['try_all'];
function check_agree(form) {
  for (var i = 0; i < agree_checkboxes.length; i++) {
    var c = form.elements.namedItem(agree_checkboxes[i]);
    if (c && !c.checked)
      return false;
  }
  return true;
}
function patch_agree(o) {
  var valid = true;
  for (var i = 0; i < agree_checkboxes.length && valid; i++) {
    var c = o.form.elements.namedItem(agree_checkboxes[i]);
    if (c && !c.checked)
      valid = false;
  }
  $('input[name=submit]').button(valid ? 'enable' : 'disable')
  return true; 
}
{/literal}
//]]>
</script>

then find

<form action="patch.php" method="post">

and replace with

<form action="patch.php" method="post" onsubmit="javascript: return check_agree(this);">

then find

<label for="try_all">{$lng.lbl_tick_here_to_apply_patch}</label><input type="checkbox" id="try_all" name="try_all" /><br />

and replace with

<label for="try_all">{$lng.lbl_tick_here_to_apply_patch}</label><input type="checkbox" id="try_all" name="try_all" onclick="javascript: patch_agree(this);" /><br />

then find

<input type="submit" value="{$lng.lbl_apply_patch|strip_tags:false|escape}" />

and replace with

<input type="submit" name="submit" value="{$lng.lbl_apply_patch|strip_tags:false|escape}"{if $could_not_patch ne "0" and $mode ne "sql"} disabled="disabled"{/if} />

Done.

Come on QT, this is your own code, just copy/paste, and you can't implement it to something as important as running a patch

Thank you Steve, we will take it into consideration for future X-Cart releases.

[kustomrides]

Originally Posted by cflsystems

It is best to patch manually then restoring original files - if you made undocumented changes to them you may not be able to apply this changes again after upgrade. Just run the upgrade - it will show a report first and will not modify any files. If you get anything else than "OK" or "Already patched" do not proceed further. First you need to manually patch files and then you can run the upgrade again

That's my preferred method, too, owing to a number of modified files. Easier to manually patch than start fresh and reintegrate mods. If all else fails have a copy of the complete 4.4.4 version on hand for comparison.

[Ana]

Originally Posted by cflsystems

So got my first 4.4.3->4.4.4 live upgrade - few files to manually patch and no problems at all with the upgrade. Smooth and it looks like all works just fine. Couple new shipping methods were activated after the upgrade but I assume these were newly added shipping methods by the upgrade (still they should be added as disabled). Over all positive experience with the upgrade. Looks like 4.4.4 is way better compare to 4.4.3, I even think a little bit faster. One warning for anyone using jquery from CDN (like Google and others) - make sure you are loading 1.6.2 or OPC and and some admin features depending on it will not work

Yes, just found those shipping options activated today, believe it or not. But I agree, Steve, this one went the smoothest of them all in the 7 years I've been doing it.

Well done, Qualiteam. Glad to see the improvement.

Ana