Stock by Attribute v4.0 addon for v1.3.5-1.3.9

[mc12345678]

FYI, added the ability to copy product with associated Stock By Attributes attributes being transferred/copied to the new product, or to other product or categories (attributes controller).
Also found two minor bugs:
1) related to interrelationship with Products Attributes Grid (PAG).
2) the other a potential javascript error that could affect other parts of the page as well as if a product has read only attributes and the read-only attributes are not at the end of the attribute list, the product is added to the cart, the cart visited, then selected from the cart to return to the product info page, (deep breath) now all of the attributes that were selected to add the product to the cart will be auto selected again like it is in a default install...
Addressed PHP 7.2 compatibility based on upcoming deprecation of functions.
A few files had alignment modifications.
Other minor modifications to support other improvements.

master branch of https://github.com/mc12345678/Stock_...utes_Combined/ has these items applied

[mc12345678]

Minor bug identified reguarding the latest push to github. Issue is that the customid is not found for product variants that are created by combining all attributes into one variant where there is more than one attribute involved.

To correct (update to be pushed to github "soon") go to:
includes/classes/class.products_with_attributes_class_stock.php

Goto line 191:
Change

        if ($this->zen_product_is_sba($product_id)/*$attribute_stock->RecordCount() > 0*/) {

To:

        if ($this->zen_product_is_sba($products_id)/*$attribute_stock->RecordCount() > 0*/) {

By adding an s after product and before _id so that it reads products_id instead of product_id.

[mc12345678]

I pushed an update to https://github.com/mc12345678/Stock_...butes_Combined to accomplish two things,
1) Ensure the capture of the customid for all currently supported methods of defining variants and
2) Support display/retrieval of the customid for all such supported methods of defining variants. (for cases where a products attributes are individually stocked, the customid for the individual attribute is displayed adjacent to the attribute as well as combined with any existing customids for a single customid display.

The only time that a combined customid would be the same as any other is if none of the other attributes have a customid assigned to them. State this because the customid is controlled such that an entered customid is unique for every entry (when one is made), but in the case where individual attributes are tracked (thus limiting the purchase of that product to the smallest quantity available of all of the associated attributes), a combination of customids with a combination of no customid could result in a single customid for all variations of attributes that include that one attribute.

Anyways, looking for some feedback as I move on to updating the instruction that potteryhouse began so that this can be posted to the ZC plugins section. Yes, there are still a few improvements that can be made in various areas, but those can follow.

Also note, that recently I added the ability to copy the sba attributes where product copying was made available (didn't dig into the option names or option values managers for this type feature) but when copying a product (specifically when at the catalog menu and presented with linking or duplicating the product an option was added to omit copying the sba attributes, but such an option has not been made available at say the product's attibutes screen. Could add it there as well, but then the buttons along the top would need to be modified or an additional field or another "screen" made available to choose such an option. Anyways, welcome input. (famous last words)

[st.bobo]

I have used this plugin and been happy with it. Today I created a new site, installed zen cart 1.5.4 and then installed latest version of SBA. I am getting a blank page after install. Clean install a second time of Zen Cart, then installed SBA one file at a time. The problem is general.php which is located in admin/includes/functions. Not sure why it is breaking latest version of Zen Desk, but it is.

[mc12345678]

I have used this plugin and been happy with it. Today I created a new site, installed zen cart 1.5.4 and then installed latest version of SBA. I am getting a blank page after install. Clean install a second time of Zen Cart, then installed SBA one file at a time. The problem is general.php which is located in admin/includes/functions. Not sure why it is breaking latest version of Zen Desk, but it is.

What error(s) were generated in the logs directory?

The only modification documented as being made to that file is related to product removal.

[mc12345678]

I have used this plugin and been happy with it. Today I created a new site, installed zen cart 1.5.4 and then installed latest version of SBA. I am getting a blank page after install. Clean install a second time of Zen Cart, then installed SBA one file at a time. The problem is general.php which is located in admin/includes/functions. Not sure why it is breaking latest version of Zen Desk, but it is.

Please describe the "method" of install. I just fully installed the files of the current github version of SBA to a ZC 1.5.4 site and have been able to access store and admin side without issue, I have also made an individual purchase of a product tracked by SBA, a product that has attributes (not tracked by SBA), and a product that had no attributes. Then I went back and purchased one of each of those products in the cart. In all cases, no errors reported, no problems encountered. I have also gone through and compared an entire fresh install fileset of ZC 1.5.4 to the files of my temp site and other than incorporating the issues associated with ZC 1.5.4 as identified in the ZC 1.5.4 known issues area and having added in a troubleshooting tool to look at data associated with operation its a blank slate.

Expectation and way that it has been coded is that all files in the original includes and admin directories (no core modifications though a few template files are included which when incorporated here without the remaining install will have zero effect on the remainder of the store) then to install the ZC version specific files. Mind you, installation is to mean merging the very few changes that have been made to the file(s) into the existing file(s) and not to blindly replace the file(s) that exist because those files may have been modified to support some other plugin/operation.

[mc12345678]

I've also just now fully installed a ZC 1.5.5e version on PHP 7.0.14, activated the responsive classic template as the base template, first installed just the "core" files, accessed both the store and the admin without issues, then installed/merged the changes for SBA (primarily to support the use of the customid), (haven't yet run the install code for the database) accessed the store and the admin, no problems.

Ran the install: No problems.

Navigated the store and the admin: No problems.

Added 10 each of products id 2 from the demo product (Matrox G400 32MB) Used the combined attributes such that there are four variants, each variant has two product option names, each option name having one option value. (Ie.:
Model: Premium
Memory: 16 mb)

Navigated to and added a deluxe, 32mb Matrox G400 32MB graphics card to my shopping cart. (Dynamic Dropdowns were active by default so was forced to first select a Model then the Memory option available based on the quantity presented)
Went to the shopping cart, product showed as expected with attributes.
went to checkout shipping: No issues
Payment, no issues
confirmation, no issues
Success page... No issues...

I have verified that the files on github in the master branch match what I am using and that I am using no more than what is in the master branch on github. No errors with ZC 1.5.5e checking out, using the admin or any other default ZC operation.

That doesn't mean that an issue may not pop up on someone else's computer system based on their setup, what they have installed in parallel, etc... In the last 7 hours though, two people have posted on the ZC forum indicating a problem, one using ZC 1.5.4 and another ZC 1.5.5e... I have just installed the same software on two different installs of ZC (although on the same server and each running different PHP versions) without experiencing blank pages as reported. I would like to understand what has caused these blank pages and to do so look forward to hearing from each individual (preferably as much as possible in the forum, but as necessary via PM). Unlike how some don't show interest in continuing to make this community available software better by resolving discovered issues, I would like to see that they be resolved and that at least a functional, minimal featured option be available to those that use ZC. That can only be done through the help of those that discover a problem. That goes for anything that is posted on this site. It's a community because it takes the people that use the software to identify issues (and hopefully solutions) to make improvements.

[mc12345678]

I have used this plugin and been happy with it. Today I created a new site, installed zen cart 1.5.4 and then installed latest version of SBA. I am getting a blank page after install. Clean install a second time of Zen Cart, then installed SBA one file at a time. The problem is general.php which is located in admin/includes/functions. Not sure why it is breaking latest version of Zen Desk, but it is.

Just also realized... Never said from where the "latest version" was obtained.... The fully functional version that works for ZC 1.5.1, 1.5.3, 1.5.4 and 1.5.5 can be found: https://github.com/mc12345678/Stock_...butes_Combined

[cefyn]

Upgraded to 1.5.5e ok except admin/products_with_attributes_stock.php disappeared. And I just can't get it back in. Latest version of Stock_By_Attributes_Combined-master. Upload it with Filezilla, it disappears again, and again, and ...again. Tried the file upload in cpanel, and I get "The file you uploaded, products_with_attributes_stock.php, contains a virus so the upload was canceled: YARA.eval_post.UNOFFICIAL FOUND" I've done a scan on it, and of course, there's no virus.
I can only think it's a permissions issue, the file uploads at 664, I try to change it to 644 in Filezilla, refresh the file list and it disappears again. Everything else working ok. Ideas anyone ? Thanks.

[mc12345678]

Upgraded to 1.5.5e ok except admin/products_with_attributes_stock.php disappeared. And I just can't get it back in. Latest version of Stock_By_Attributes_Combined-master. Upload it with Filezilla, it disappears again, and again, and ...again. Tried the file upload in cpanel, and I get "The file you uploaded, products_with_attributes_stock.php, contains a virus so the upload was canceled: YARA.eval_post.UNOFFICIAL FOUND" I've done a scan on it, and of course, there's no virus.
I can only think it's a permissions issue, the file uploads at 664, I try to change it to 644 in Filezilla, refresh the file list and it disappears again. Everything else working ok. Ideas anyone ? Thanks.

There's a few things that look like might cause some sort of response like that, though the things I'm looking at seem to be there to exactly prevent issues/injection.

The first consideration is to remove some additional checks in some of the if statements. For example changing:

in line 54:

    if (isset($_POST['products_id']) && is_numeric((int) $_POST['products_id'])) {
      $products_id = (int) $_POST['products_id'];
    }

to:

    if (isset($_POST['products_id'])) {
      $products_id = (int) $_POST['products_id'];
    }

With similar at lines 114,

changing doubleval(nnn) type statements to type cast the value to float such as in line 184 from:

$products_id = doubleval($_POST['products_id']);

to:

$products_id = (float)$_POST['products_id'];

If those don't resolve the detection of evaluation of the content to appear as if there is an evaluation of the $_POSTed data, then a next possible revision is to remove the direct use of $_POST in some of the operations and first assign a variable to the value of $_POST and then let the function perform the operation on the variable, or in cases where the $db->bindVars or $db->getBindVarValue sanitization is used to instead cast the $_POSTed result to the same type.

For example changing:
line 128 from:

$quantity = $db->getBindVarValue($_POST['quantity'], 'float');

to:

$quantity = (float)$_POST['quantity'];

or beginning on line 428 from:

        $query = 'delete from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id= :products_id:';
        $query = $db->bindVars($query, ':products_id:', $_POST['products_id'], 'integer');
        $db->Execute($query);

to:

        $query = $db->Execute('delete from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id= ' . (int)$_POST['products_id']);
//        $query = $db->bindVars($query, ':products_id:', $_POST['products_id'], 'integer');
//        $db->Execute($query);

Which from recent discussions of PHP 7.1, concatenation of values with strings and type casting probably would have to be rewritten like:

        $query = $db->Execute('delete from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id= ' . (string)(int)$_POST['products_id']);
//        $query = $db->bindVars($query, ':products_id:', $_POST['products_id'], 'integer');
//        $db->Execute($query);

Another example line 444 from:

        $query = 'delete from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id= :products_id: and stock_attributes=:stock_attributes: limit 1';
        $query = $db->bindVars($query, ':products_id:', $_POST['products_id'], 'integer');
        $query = $db->bindVars($query, ':stock_attributes:', $_POST['attributes'], 'string');
        $db->Execute($query);

to:

        $db->Execute('delete from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id= ' . (int)$_POST['products_id'] . ' and stock_attributes=\'' . (string)$_POST['attributes'] . '\' limit 1';
//        $query = $db->bindVars($query, ':products_id:', $_POST['products_id'], 'integer');
//        $query = $db->bindVars($query, ':stock_attributes:', $_POST['attributes'], 'string');
//        $db->Execute($query);

Those are some ideas that might prevent the response that has been identified but maintain the same level of sanitization that has been incorporated to prevent the possible injection of malicious code. I would be very interested to know which of the above either individually or combined resolved the issue.

I do not know how/why the permission level was set to 664 instead of 644 upon upload. I would suggest looking at the permission level of the other files that are/were uploaded to see if they also are 664 or if they were uploaded to the expected 644 and then attempting to understand what it takes to otherwise upload with a permission level of 644.