Harald Ponce de Leon

There is a bug with the Braintree App v2.011 that does not respect the Payment Zone if one has been specified. Until the next App update is pushed out, those affected by this issue can easily apply the following change. In the following file: catalog/includes/modules/payment/braintree_cc.php on lines 95 and 97, the following constant is being referenced: OSCOM_APP_PAYPAL_DP_ZONE simple replace both instances with the following constant: OSCOM_APP_PAYPAL_BRAINTREE_CC_ZONE and save the file. Payment Zones will then work as normal.

Hi All.. Here are instructions on how to check how compatible your online store installation / PHP code is against all PHP versions from 5.0 up to the latest version (currently 7.3). This guide requires a minimum PHP 5.4 version to run. This is a medium level skill guide and requires the installation of Composer - a dependency manager for PHP that manages the installation and updates of third party libraries. I will link to the installation instructions of Composer instead of writing how to install it here. It's possible to perform this guide either remotely on the web server in a ssh terminal, or locally on a backup copy of the PHP code. Step 1 - Install Composer Composer can be installed on Windows, Linux, Mac, and Unix. If you're installing on Linux, there may be a Linux distribution package that can be installed depending on your access privileges on the server, otherwise a manual installation is required. The manual installation can be performed locally in your home directory without special user permissions. Instructions for how to install Composer on Windows can be found here: https://getcomposer.org/doc/00-intro.md#installation-windows Instructions for how to install Composer on Linux, Mac, and Unix can be found here: https://getcomposer.org/doc/00-intro.md#installation-linux-unix-macos Step 2 - Create Composer Project File Composer needs to create a composer project file in the directory where your online store installation or PHP code resides. This will create two files that will be publicly accessible through the web server - this will not pose any security issues. The setup will also eventually create a "vendor" directory however Composer will be configured to place this in the "includes" directory to block public web server requests to the directory. Copy and paste the following to composer.json in the directory where your online store installation resides: { "config": { "vendor-dir": "includes/thirdparty/composer" }, "require-dev": { "squizlabs/php_codesniffer": "^3.4", "phpcompatibility/php-compatibility": "^9.2" } } Step 3 - Install PHP_CodeSniffer PHP_Codesniffer detects violations of defined rules in your code. There are several coding standard rule sets available to make sure each PHP file meets the coding standards. There is no rule set currently available for OSCOM v2.x - for v3 the PSR12 rule set is used. As there will be a lot of violations running this with a coding standard, we will instead run it to use only one rule set to check compatibility against the latest PHP version. We will also configure PHP_CodeSniffer to ignore certain violations which is already taken care of in the online store installation. Run the following command to install PHP_CodeSniffer: composer install After this installs PHP_CodeSniffer and the PHP Compatibility rule set, a PHP_CodeSniffer configuration file will be created to configure the rule set that should be used. Copy and paste the following to phpcs.xml in the directory where your online store installation resides: <?xml version="1.0"?> <ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="PHP_CodeSniffer" xsi:noNamespaceSchemaLocation="phpcs.xsd"> <description>The coding standard for osCommerce.</description> <file>.</file> <exclude-pattern>*/includes/thirdparty/*$</exclude-pattern> <arg name="basepath" value="."/> <arg name="colors"/> <arg value="nps"/> <rule ref="PHPCompatibility"/> <config name="installed_paths" value="includes/thirdparty/composer/phpcompatibility/php-compatibility" /> </ruleset> Step 4 - Run PHP_CodeSniffer PHP_CodeSniffer can now be executed with the following command. It will automatically use the configuration file created in step 3: ./includes/thirdparty/composer/bin/phpcs which will produce the following output report: FILE: admin/includes/functions/compatibility.php --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- FOUND 15 ERRORS AFFECTING 12 LINES --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 32 | ERROR | Global variable '$HTTP_GET_VARS' is deprecated since PHP 5.3 and removed since PHP 5.4; Use $_GET instead (PHPCompatibility.Variables.RemovedPredefinedGlobalVariables.http_get_varsDeprecatedRemoved) 33 | ERROR | Global variable '$HTTP_POST_VARS' is deprecated since PHP 5.3 and removed since PHP 5.4; Use $_POST instead (PHPCompatibility.Variables.RemovedPredefinedGlobalVariables.http_post_varsDeprecatedRemoved) 34 | ERROR | Global variable '$HTTP_COOKIE_VARS' is deprecated since PHP 5.3 and removed since PHP 5.4; Use $_COOKIE instead | | (PHPCompatibility.Variables.RemovedPredefinedGlobalVariables.http_cookie_varsDeprecatedRemoved) FILE: admin/includes/functions/database.php ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- FOUND 25 ERRORS AFFECTING 24 LINES ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 179 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead (PHPCompatibility.Extensions.RemovedExtensions.mysql_DeprecatedRemoved) 181 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead (PHPCompatibility.Extensions.RemovedExtensions.mysql_DeprecatedRemoved) 185 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead (PHPCompatibility.Extensions.RemovedExtensions.mysql_DeprecatedRemoved) Here we can see which files violate a PHP Compatibility rule set, the line in the file where the violation occurs, the reason for the violation, and the actual rule set that was violated that we'll be using to ignore the false positive reports with. In the example output, it states that $HTTP_GET_VARS, $HTTP_POST_VARS, and $HTTP_COOKIE_VARS are deprecated since PHP 5.3 and are still used in your online store installation. This is a false positive as osCommerce Online Merchant already has its own implementation to work with or around it. In this case, the variables are safely defined in admin/includes/functions/compatibility.php and includes/functions/compatibility.php. It also states that "mysql_" is deprecated in PHP 5.5 and still used in the online store installation. This is also a false positive as osCommerce Online Merchant wraps calls to the "mysql_" functions if "mysqli" does not exist. We'll add to the PHP_CodeSniffer configuration the rules that can be ignored. The rules can be seen in the output report in brackets ( ). Below is an updated phpcs.xml file with a list of rules being safely ignored for a osCommerce Online Merchant v2.3.4.1 installation: <?xml version="1.0"?> <ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="PHP_CodeSniffer" xsi:noNamespaceSchemaLocation="phpcs.xsd"> <description>The coding standard for osCommerce.</description> <file>.</file> <exclude-pattern>*/includes/thirdparty/*$</exclude-pattern> <arg name="basepath" value="."/> <arg name="colors"/> <arg value="nps"/> <rule ref="PHPCompatibility"/> <config name="installed_paths" value="includes/thirdparty/composer/phpcompatibility/php-compatibility" /> <rule ref="PHPCompatibility.Variables.RemovedPredefinedGlobalVariables.http_get_varsDeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.Variables.RemovedPredefinedGlobalVariables.http_post_varsDeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.Variables.RemovedPredefinedGlobalVariables.http_cookie_varsDeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.Variables.RemovedPredefinedGlobalVariables.http_session_varsDeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.Variables.RemovedPredefinedGlobalVariables.http_server_varsDeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.Variables.RemovedPredefinedGlobalVariables.http_post_filesDeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.Extensions.RemovedExtensions.mysql_DeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.IniDirectives.RemovedIniDirectives.session_bug_compat_42DeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.IniDirectives.RemovedIniDirectives.session_bug_compat_warnDeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.FunctionUse.RemovedFunctions.session_registerDeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.FunctionUse.RemovedFunctions.session_is_registeredDeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.FunctionUse.RemovedFunctions.session_unregisterDeprecatedRemoved"> <severity>0</severity> </rule> <rule ref="PHPCompatibility.FunctionUse.RemovedFunctions.mysql_escape_stringDeprecatedRemoved"> <severity>0</severity> </rule> </ruleset> Please remember that a lot of false positives will be reported and will need to be individually checked to see if a workaround exists in the PHP code. Additional rules to ignore can be added to the PHP_CodeSniffer configuration file. Happy PHP 7.3 incompatibility hunting!

Every v2.x release is being sunsetted, including v2.4. Someone is welcome to continue development through the Community Edition program. My focus is 100% on v3. All Community Edition releases will have their own support area in the forum and their own version in the Marketplace. Linking to the releases on our downloads page is just the start - it is planned to have dedicated pages for each release so their features can be showcased.

Yes, at Github. 1.0.0.0 to 1.0.0.2: https://github.com/gburton/Responsive-osCommerce/compare/v1.0.0.0...1.0.0.2 1.0.0.2 to 1.0.0.3: https://github.com/gburton/Responsive-osCommerce/compare/1.0.0.2...1.0.0.3 They will be made aware as CE releases use the same update mechanism from v2.3. This means the update procedure is manual for v2.3 based CE releases (the architecture does not support online updates). Automatic updates will first arrive with v3 and v3 based CE releases. Community Edition maintainers have the ability to push out a release to the website without my intervention. In fact, the website automatically checks Github once every hour to see if a new release has been pushed out at Github and automatically updates the download page and posts a news announcement if one was posted at Github. This will be addressed when Community Editions are officially announced. If they want to stay on PHP 5.6 they can with their current installation. If it runs perfectly today, it will run perfectly tomorrow, and there are active developers in the forum that can help when problems arise. If they want to move to another release or platform, they can't stay on PHP 5.6. There is a lot of excitement when releases are pushed out, however your current installation is not going to burn if you don't upgrade immediately.

The next update will be pushed out this month and takes care of that 👍

There's also Relevancy and Last Updated sort options. Relevancy is the default.

Sorry, it's not the % search, it's fulltext search.

It's the standard MySQL % searching. One of the next updates will move the searching to an Elasticsearch server.

The class constructor has a syntax error which is why the Apps Marketplace did not accept the upload. Here is the class constructor of includes/modules/header_tags/ht_jcm_owl_carousel2_js.php: function __construct() { $this->title = MODULE_HEADER_TAGS_JCM_OWL_CAROUSEL2_JS_TITLE; $this->description = MODULE_HEADER_TAGS_JCM_OWL_CAROUSEL2_JS_DESCRIPTION; if ( defined('MODULE_HEADER_TAGS_JCM_OWL_CAROUSEL2_JS_STATUS') ) { $this->sort_order = MODULE_HEADER_TAGS_JCM_OWL_CAROUSEL2_JS_SORT_ORDER; $this->enabled = (MODULE_HEADER_TAGS_JCM_OWL_CAROUSEL2_JS_STATUS == 'True'); } } global $oscTemplate, $category_depth; if (basename($_SERVER['SCRIPT_NAME']) == 'index.php' && (isset($category_depth) && $category_depth == 'top') && ! isset($_GET['manufacturers_id'])) { $oscTemplate->addBlock( '<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/OwlCarousel2/2.3.4/assets/owl.carousel.css">' . "\n", $this->group); $oscTemplate->addBlock( '<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/OwlCarousel2/2.3.4/assets/owl.theme.default.css">' . "\n", $this->group); } } Either the constructor is closed early before the global statement, or a function name is missing. Either way, it's good now that the Apps Marketplace can detect such issues 👍

Hi All.. The categories and versions in the Apps Marketplace have been cleaned up as follows: Versions v3.0 Alpha 5 and v3.0 versions vaulted Categories Payment Modules renamed to Payment Shipping Modules renamed to Shipping Order Total Modules renamed to Order Processing Credit Modules moved to Order Processing Content Modules moved to Features Zones moved to Other Images moved to Other InfoBoxes moved to Features Reports moved to Features