Upgrade 4.3.3 Failed

I am unable to upgrade to 4.3.3. from 4.3.2. The upgrade is available and runs but doesn’t install, the cart reports after upgrade “?version” version 4.3.2 and the install option remains in upgrade.



After 2 long weeks with support who seem to dragging out support, I was hoping someone else may help me.



After changing all the permissions they requested and more – including recursive permissions for all folders to 755 and files 644 the issue remains.



I have other installs of cs-cart on the same server working fine and upgrading without issue.



I decided it would quicker to move the data to another install so I tried to export and import the data. This was not pretty in the least, not many products, invoices or customers matched up no matter what I did.



I loaded a 4.3.1 database and attempted a store import to 4.3.2 this just left me with a “Store Unavailable” not matter what I did. I made plenty of memory available each time.



I have 2 other stores on the server both “exported / imported” fine and both stores “Store Imported” fine.



I am now assuming the database is damaged and it may be best to start again, can anyone guide me as I really think Support is not interested in fixing this problem in the least.

Did you check the error logs? If you can provide us with the temporary FTP access, we can check the issue (not on the Friday evening please :))

PM sent

Finally I resolved the issues of the upgrades and why the last 2 failed so badly, thanks eComslabs for your help; with it I would not have looked further.



The server was running a PHP handler “dso” this allowed the files to run as nobody and caused issues to in the upgrades as it did not have permissions to run correctly. This seems to only effect upgrade to 4.3.2 & 4.3.3. I changed to PHP handler “suPHP” and reset all permissions and ownership across the server.



The following are run on a cPanel based Cent-OS platform -



Change all permissions for folders from 777 to 755

The following command will change the folders inside public_html for all accounts to 755, it doesn’t just list the ones needing changed:

find /home/*/public_html -type d -exec chmod 755 {} \;

Change all permissions for files from 666 to 644

The following command will change the files inside public_html for all accounts to 644, it doesn’t just list the ones needing changed:

find /home/*/public_html -type f -exec chmod 644 {} \;



Fix ownership to public_html contents to user:user (rather than user:nobody), but keep top level of public_html as user:nobody

for i in `ls /var/cpanel/users/`; do chown -R $i:$i /home/$i/public_html ; done
for i in `ls /var/cpanel/users/`; do chown $i:nobody /home/$i/public_html ; done




The first command recursively chowns all files and folders inside public_html to the users found in /var/cpanel/users folder. The second command puts the top-level of public_html as user:nobody as it needs to remain that setting.



Remove any php_value and php_flag entries in .htaccess files as they will produce an Internal Server Error if in an account’s .htaccess file.

find /home -type f -name ‘.htaccess’ -exec grep -Hrn ‘php_value’ ‘{}’ \;
find /home -type f -name ‘.htaccess’ -exec grep -Hrn ‘php_flag’ ‘{}’ \;




I ran the upgrade to 4.3.3 and it failed until I reset the following to these values in the config.local.php


// Default permissions for newly created files and directories
define('DEFAULT_FILE_PERMISSIONS', 0644);
define('DEFAULT_DIR_PERMISSIONS', 0755);




Re-running the upgrade script worked with this in place.



On a final note I would like to say CS-Cart thank you for taking 15 credits, resolving nothing and wasting 2 weeks of my time waiting for you. You explainations are poor at the best of times and seem to lack the basic understanding of what we are saying. I can not see myself paying of support again with you as I would rather pay someone else like ecomslabs who have been more helpful in a shorter time than you have been. It is a shame cs-cart support is so poor as it ruins a such a good product.

I know this is an old post but I am just trying to upgrade a site from 4.2.1, I ran into error going to 4.2.2 and CS-Cart tech changed something for them to be able to upgrade from 4.2.1 up to 4.2.4. Now I am trying to go up to 4.3.1 and I am getting this error:

Error

Unfortunately, you cannot proceed with the upgrade because we cannot access the var/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz/restore.php file, which is used to roll back the upgrade. We must be sure that the restore functionality works fine before you continue with the upgrade.

It seems that wrong permissions settings cause this issue.

  1. Try this:
  2. Set 644 permissions for the var/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz/restore.php file (chmod 644 var/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz/restore.php)
  3. Set 755 permissions for var/ , var/upgrade/ , var/upgrades/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz folders (chmod -R 755 ./var)
  4. Click the Install button to restart the upgrade procedure.

If this error message occurs after you have completed the above steps, contact our support team via your Help Desk account and give them a temporary SSH or FTP access to your store.

I asked CS-Cart tech to look into this and they replied saying it was something on my server and they were getting a 404 error when trying to access the restore.php file and they should have gotten an Access Denied message instead. I pointed out that they were trying to access the restore.php file with an incorrect URL and that I had verified all the permissions were correct, but yet I am still getting the above error message. I am running PHP 5.6 suPHP and have not had this issue before, anyone have any suggestions?

Backup your site and database manually.

Set define('DEVELOPMENT', true)

Edit the App.php (or possibly the upgrade.override.php controller) file and comment out anything related to backups or the restore file

Run the upgrade.

When you hit about 4.7 or so, you won't need to keep editing the App.php because there will be an option to skip backps.

Thanks Tony, I'll give it a shot.