CS-cart shouldn't modify (build) an SEO name unless it is a new product creation or the SEO name field is empty.
We are getting this error while attempting to upgrade to Upgrade 4.3.3 - 4.3.3.SP1
ErrorThe ZipArchive class not found. Read more: https://php.net/manual/en/class.ziparchive.php
ErrorPackage content schema not found
It sounds like you do not have Zip installed on your server.? Ask your host about it.
It sounds like you do not have Zip installed on your server.? Ask your host about it.
yes sorted the issue.
Seems like test/verification of the class existing should be one of the pre-checks since it's not a standard PHP extension....
Seems like test/verification of the class existing should be one of the pre-checks since it's not a standard PHP extension....
There are no "standart" PHP extensions. There are extensions that PHP can be compiled with - they are bundled with PHP. There are also PECL extensions - they should be downloaded and installed separately. Availability of extensions that are bundled with PHP is all about the flags used for PHP compilation (talking about "zip", "--enable-zip" flag is required). In popular server operating systems like Debian and Ubuntu Server package that contains PHP ("php5-common") has PHP binary that was compiled already with "zip" extension.
Moreover, "zip" extension was always listed at system requirements for CS-Cart 4.x: https://www.cs-cart.com/requirements.html and our installer checks for its availability and displays a warning if it's not available.
Also, an error notice "The ZipArchive class not found" is triggered by CS-Cart code as a part of pre-backup environment checks, and this is not PHP's fatal error.
CS-cart shouldn't modify (build) an SEO name unless it is a new product creation or the SEO name field is empty.
When CS-Cart modifies a SEO-name and the previous wasn't empty, it also creates a rule for 301 redirect from old URL to new. When you visit an URL that contains old SEO-name, 301 redirect is performed to the URL for a new SEO-name.
"assign payment methods to shipping methods" feature seems to be incomplete and just a basic feature because the restriction should be applicable to Products and Product categories as well because payment methods are not always location specific, we require some payments restricted to some products especially "COD". I was waiting for this feature since long and finally it is added with just a basic functionality
When CS-Cart modifies a SEO-name and the previous wasn't empty, it also creates a rule for 301 redirect from old URL to new. When you visit an URL that contains old SEO-name, 301 redirect is performed to the URL for a new SEO-name.
As I said, it shouldn't modify it unless it's empty, regardless of 301.
Get this error when upgrading to 4.3.3 SP1
Validation Issue
Validation Restore returned fail status
Unable to prepare restore file File var/upgrade/restore.php was locally modified/renamed/removed. Restore the original restore.php file before the upgrade.
Thanks
I got the same error how ever I did change file's permission but still not working. Please advice.
When CS-Cart modifies a SEO-name and the previous wasn't empty, it also creates a rule for 301 redirect from old URL to new. When you visit an URL that contains old SEO-name, 301 redirect is performed to the URL for a new SEO-name.
Webmasters should be able to decide what URLS they use. If a website has used the same perfect URL's for a decade then CS-Cart should not modify these at all. It damages the site/sales, even IF the 301 redirects work. Which they do not in many cases.
There are no "standart" PHP extensions. There are extensions that PHP can be compiled with - they are bundled with PHP. There are also PECL extensions - they should be downloaded and installed separately. Availability of extensions that are bundled with PHP is all about the flags used for PHP compilation (talking about "zip", "--enable-zip" flag is required). In popular server operating systems like Debian and Ubuntu Server package that contains PHP ("php5-common") has PHP binary that was compiled already with "zip" extension.
Moreover, "zip" extension was always listed at system requirements for CS-Cart 4.x: https://www.cs-cart.com/requirements.html and our installer checks for its availability and displays a warning if it's not available.
Also, an error notice "The ZipArchive class not found" is triggered by CS-Cart code as a part of pre-backup environment checks, and this is not PHP's fatal error.
Okay, I should have used the word "common" instead. But if you're going to add pre-checks for things like Timeout and max_execution_time then you should add checks for classes that don't exist that are used by the software BEFORE THEY FAIL.
The vast majority of merchants are not running with extended Linux environments (Debbian or Ubuntu) but generally basic Centos. Additionally, many are running less than current versions of PHP. I guess time will tell how many have ZipArchive compiled in or available as an extension without their hosting's intervention.
If you'd have just reverted to the Tar_Archive you used to use, it would be distributed with your product, would have done all that you need with acceptable performance and been within your control to address any issues that "might" surface. Latest and greatest doesn't always equal best.
Thats a smart approach to keep product URLS unique. But CS-Cart also keeps changing URLs for features, pages and categories. Does the mod resolve this too?
CS-cart shouldn't modify (build) an SEO name unless it is a new product creation or the SEO name field is empty.
When CS-Cart modifies a SEO-name and the previous wasn't empty, it also creates a rule for 301 redirect from old URL to new. When you visit an URL that contains old SEO-name, 301 redirect is performed to the URL for a new SEO-name.
Webmasters should be able to decide what URLS they use. If a website has used the same perfect URL's for a decade then CS-Cart should not modify these at all. It damages the site/sales, even IF the 301 redirects work. Which they do not in many cases.
Guys,
SEO names are not changed after they are set. No known bugs regarding this matter.
P-Pharma means that when you set name of product to e.g. "ipad.html" and there is already a subcategory with the "apple/ipad.html" name than the name of the product will be updated to ipad-en.html.
More details on this bug is here: http://forum.cs-cart.com/tracker/issue-5812-cs-cart-keeps-changing-unique-urls/
Please let's stop this discussion until you are 100% sure that you understand the existing problem.
"assign payment methods to shipping methods" feature seems to be incomplete and just a basic feature because the restriction should be applicable to Products and Product categories as well because payment methods are not always location specific, we require some payments restricted to some products especially "COD". I was waiting for this feature since long and finally it is added with just a basic functionality
Payment dependencies on products/categories is 100% custom addon/development.
We do not plan to add this to CS-Cart.
Okay, I should have used the word "common" instead. But if you're going to add pre-checks for things like Timeout and max_execution_time then you should add checks for classes that don't exist that are used by the software BEFORE THEY FAIL.
The vast majority of merchants are not running with extended Linux environments (Debbian or Ubuntu) but generally basic Centos. Additionally, many are running less than current versions of PHP. I guess time will tell how many have ZipArchive compiled in or available as an extension without their hosting's intervention.
If you'd have just reverted to the Tar_Archive you used to use, it would be distributed with your product, would have done all that you need with acceptable performance and been within your control to address any issues that "might" surface. Latest and greatest doesn't always equal best.
Tony, thank you for the advice,
We are collecting statistics on how many clients have problems with ZipArchive and in case there are many of them we will consider some improvements.
Besides I asked abolshakov to make some performance/resource consuming tests with ZipArchive and Tar.
But by the time you get stats on people who have issues, it will be too late since folks will already get stuck in the upgrade path. Most will be fine.
But what I really need is an answer to the Phar issues that exist that are preventing clients from upgrading. Waiting on helpdesk is like watching paint dry.
Regarding SEO name duplication... Given that you separate the name from the rules for SEO, it is impossible for you to detect duplicate names (unless you do so at rule change). If I have two products with foo.html and cat1/foo.html, these are valid and different SEO path names. But if I change the SEO rules to NOT show category in the path, then I get duplicate foo.html references.
Is the "Remove query strings from static resources" fix in 4.3.4? or next version?
Is the "Remove query strings from static resources" fix in 4.3.4? or next version?
Not in 4.3.4, will be in 4.3.5.
So....
when can I expect to see 4.3.4 in my upgrade centre.
'Refresh packages list' still revealing squat.
Not that I intend to upgrade myself.
Just wondering when I can call on my trusted new helper.
I can't see it either.