Good day,
Hope someone with experience can assist. During the upgrade I needed to check "PHP Script timeout" and unfortunately it did not pass and asks for me to contact my hosting provider. My hosting provider needs to know what the PHP timeout should be set to?
I have also sent a ticket to support, but since it's Friday I will not hear back from them till Monday and maybe can get a quicker reply.
Help is greatly appreicated.
Claude
If possible, set 3600 seconds (1hr)
Thank you for your response ecomlabs,
This is the reponse form CS Cart:
QUOTE
Please contact your server administrator and ask them to increase the FastCGI timeout settings to 6 minutes and try to run a timeout test again.
UNQUOTE
and this is the response from my provider:
QUOTE
Please let them know that the server does not use FastCGI so we are unable to make that setting. Our shared hosting servers use SuPHP, so if there is a relevant setting that needs to be changed please let me know.
UNQUOTE
Do you think you can assist?
Thank you
Claude
You can use WHM and look at the Apache 'Timeout' setting. The Apache default is '300' (seconds) but one of my clients hosting reset it to '20'!
This is the amount of time that Apache will wait for output from PHP.
If during your upgrade, the 'dots' seem to stop or the "Loading" box seems to stay forever, then this Timeout may be the cause.
In WHM, you can access this setting yourself in the Apache Config settings. it's near the bottom of the page.
You can use WHM and look at the Apache 'Timeout' setting. The Apache default is '300' (seconds) but one of my clients hosting reset it to '20'!
This is the amount of time that Apache will wait for output from PHP.
If during your upgrade, the 'dots' seem to stop or the "Loading" box seems to stay forever, then this Timeout may be the cause.
In WHM, you can access this setting yourself in the Apache Config settings. it's near the bottom of the page.
I have been working with CS Cart Support team and my provider since Last Friday on this. I'm on a shared server and my provider has trried every possible setting. CS Cart mentions FastCGI, but servers uses SuPHP. Just today they increase the timeout on the shared server temporarely and still do not world. It gets stuck on the loading box "Compressing abck up". This happened last upgrade 3.3.3 and they made some changes to the app.ph file. They give the code to comment out I tried this time around and still does no upgrade. If seems CS Cart needs to the do upgrades for me all the time now (at cost of course). Kind fustrating, If any other ideas, please let me know thanks.
So before upgrading to 4.3.4 you have to check "PHP Script timeout"?
Or can you bypass that and continue? Am at the 4.3.3 SP1 right now
Thanks
If it is failing during the backup portion of the process it is probably due to cs-cart's use of the Phar archiver. It wants to take your site and put it into memory in order to archive it (stupid approach). So if your Apache Timeout value is set to 300 or greater, then Phar is probably the culprit. Usually you can go to a different page on your site and you will see an error notification that Phar failed (but it won't be logged anywhere).
To proceed, you will have to do a backup outside of cs-cart and then disable the backup within the upgrade process. Here's the response from helpdesk after 10 days to one-message-per-day resolution. Hopefully this will help others get past this issue since cs-cart won't accept responsibility for choosing to use the Phar archiver.
I have not yet done this but probably will later today. The whole upgrade process has gone downhill since V3.
Update: have done this and it gets beyond the failure. Note that you have to re-comment out those lines between each upgrade since a new file is part of the upgrade. This new checking of time out is kind of a heavy-handed way to do so. Not sure why you wouldn't just do:
set_timeout(3600);
$set_time = ini_get('max_execution_time').
If not requested timeout is not accepted then $set_time will hold the actual value of max_execution_time that PHP is current using.
As an alternative, we suggest that you create a store and database backup using server methods (via cPanel, for example) and disable the backup process during upgrade. In order to do it, open the app/Tygh/UpgradeCenter/App.php file and comment out the following part of code:
$logger->add('Backup files and Database'); Output::display(__('backup_data'), '', true);$backup_file = DataKeeper::backup(array( 'pack_name' => $backup_filename, 'compress' => 'zip', 'set_comet_steps' => false, 'move_progress' => false, )); if (empty($backup_file)) { $logger->add('Upgrade stopped: Failed to backup DB/Files'); return array(false, array(__('backup') => __('text_uc_failed_to_backup_tables'))); } // Send mail to admin e-mail with information about backup Mailer::sendMail(array( 'to' => 'company_site_administrator', 'from' => 'default_company_site_administrator’,
‘data’ => array(
‘backup_file’ => $backup_file,
‘settings_section_url’ => fn_url(‘settings.manage’),
‘restore_link’ => Registry::get(‘config.http_location’) . ‘/var/upgrade/restore.php?uak=’ . $restore_key,
),
‘tpl’ => ‘upgrade/backup_info.tpl’,
), ‘A’, Registry::get(‘settings.Appearance.backend_default_language’));
If it is failing during the backup portion of the process it is probably due to cs-cart's use of the Phar archiver. It wants to take your site and put it into memory in order to archive it (stupid approach). So if your Apache Timeout value is set to 300 or greater, then Phar is probably the culprit. Usually you can go to a different page on your site and you will see an error notification that Phar failed (but it won't be logged anywhere).
To proceed, you will have to do a backup outside of cs-cart and then disable the backup within the upgrade process. Here's the response from helpdesk after 10 days to one-message-per-day resolution. Hopefully this will help others get past this issue since cs-cart won't accept responsibility for choosing to use the Phar archiver.
I have not yet done this but probably will later today. The whole upgrade process has gone downhill since V3.
Update: have done this and it gets beyond the failure. Note that you have to re-comment out those lines between each upgrade since a new file is part of the upgrade. This new checking of time out is kind of a heavy-handed way to do so. Not sure why you wouldn't just do:
set_timeout(3600);
$set_time = ini_get('max_execution_time').
If not requested timeout is not accepted then $set_time will hold the actual value of max_execution_time that PHP is current using.
I have the same above code from support from last upgrade. They ended up upgrading for me. I'm in the same situation now. It's been fustrating with all the communication with them and then need to send to my provider. I agree with you, the upgrade hasn't been that so user friendly. I have already mentioned to them about the above code, but they haven't said anything. CS Support keeps teling me it's the timeout. But my provider already tried every option. I also tried the above code again and for me didn't work again. CS Cart will probably need to do it for me. So that means every upgrade there will be a points charged,
After getting through the upgrade process, when I try to open the stroefront it generates:
Uncaught ReferenceError: Modernizr is not defined
The site briefly displays but then the above error replaces the page output.
Thank God we're doing this on a development site or my client would be out of business with their site being down for 10 days trying to upgrade.
Make a backup in the control panel of your server or using built-in backup feature.
Open the app\Tygh\UpgradeCenter\App.php file and replace:
'compress' => 'zip',
with
'compress' => false,
Then run the upgrade
My guess is that on a 32bit Linux system that Phar will still choke even if compression is turned off for a site that is 4GB or more in size.
Replying as a shared host SuPHP user who is once again unable to upgrade CS-Cart from 4.3.4 to 4.3.5 after whatever upgrader changes were made in 4.x two or three revisions ago.
First issue is I have to customize Mailer.php for a known bug that has yet to be fixed (using Exchange as my mailserver is apparently to complicated for upgrades) and once I get that done I'm stuck on the backup steps as discussed in this thread. The notes here gave me hope that I could do it and not have to go through the 5 email two tickets & 3-4 days of a support assisted upgrade... looks like I will :-(
Status - I've tried setting Compress to false and tried commenting out the full backup code per EZ's post but still get hung on: "Backing up data for: phinxlog-xxxxxxxx".
Edit - I updated the the wrong file in my above response -> /App/Tygh/App.php not /App/Tygh/UpgradeCenter/App.php
Now that I've edited the correct file - the installer starts and immediately disappears.
/* $logger->add('Backing up files and database');
Output::display(__('backup_data'), '', true);
$backup_file = DataKeeper::backup(array(
'pack_name' => $backup_filename,
'compress' => false,
'set_comet_steps' => false,
'move_progress' => false,
'extra_folders' => array(
'var/langs'
)
));
if (empty($backup_file) || !file_exists($backup_file)) {
$logger->add('Upgrade stopped: failed to backup DB/files');
return array(false, array(__('backup') => __('text_uc_failed_to_backup_tables')));
}
$logger->add(sprintf('Backup created at "%s"', $backup_file));
// Send mail to admin e-mail with information about backup
$email_recipients = array();
$user_data = fn_get_user_short_info($_SESSION['auth']['user_id']);
if (!empty($user_data['email'])) {
$email_recipients[] = $user_data['email'];
}
$user_is_root_admin = isset($_SESSION['auth']['is_root']) && $_SESSION['auth']['is_root'] == 'Y';
if (!$user_is_root_admin) {
$root_admin_id = db_get_field(
"SELECT user_id FROM ?:users WHERE company_id = 0 AND is_root = 'Y' AND user_type = 'A'"
);
$root_admin_data = fn_get_user_short_info($root_admin_id);
if (!empty($root_admin_data['email'])) {
$email_recipients[] = $root_admin_data['email'];
}
}
$logger->add(sprintf('Sending upgrade information e-mail to: %s', implode(', ', $email_recipients)));
$mail_sent = Mailer::sendMail(array(
'to' => $email_recipients,
'from' => 'default_company_site_administrator',
'data' => array(
'backup_file' => $backup_file,
'settings_section_url' => fn_url('settings.manage'),
'restore_link' => "{$restore_http_path}?uak={$restore_key}",
),
'tpl' => 'upgrade/backup_info.tpl',
), 'A', Registry::get('settings.Appearance.backend_default_language')); */
And what does your php error_log file say? Also you can look at var/upgrade/core.log (or something.log - it's changed names in various releases).
Thank you!! We are upgraded.
Core_log showed a mail error in /app/Typh/UpgradeCenter/App.php so I just commented out the next six lines from what you posted - lines #626-632. This is in addition to a custom mailer.php file CSC support has supplied me for upgrades. I guess some day Exchange will get some traction in the email space and be recognized... ;-P
if ($mail_sent) {
$logger->add('E-mail was successfully sent');
} else {
$logger->add('Failed to send e-mail');
return array(false, array());
} */