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

OK, i've downloaded the 1.5.5. files from GitHub and uploaded them. Still getting blank Admin:

[01-Nov-2016 14:40:10 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function zen_get_ip_address() in /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/includes/init_includes/init_sessions.php:31
Stack trace:
#0 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/includes/autoload_func.php(48): require()
#1 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/includes/application_top.php(171): require('/var/www/vhosts...')
#2 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/index.php(10): require('/var/www/vhosts...')
#3 {main}
  thrown in /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/includes/init_includes/init_sessions.php on line 31

My 1.5.5a ZenCart uses a database that I imported from an old 1.3.8 installation where I used to use the old version of Stocks By Attributes. Could this be a cause for any of the issues I am having here?

Thanks

Dene

Deno:

OK, i've downloaded the 1.5.5. files from GitHub and uploaded them. Still getting blank Admin:

[01-Nov-2016 14:40:10 UTC] PHP Fatal error: Uncaught Error: Call to undefined function zen_get_ip_address() in /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/includes/init_includes/init_sessions.php:31
Stack trace:
#0 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/includes/autoload_func.php(48): require()
#1 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/includes/application_top.php(171): require('/var/www/vhosts...')
#2 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/index.php(10): require('/var/www/vhosts...')
#3 {main}
thrown in /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/includes/init_includes/init_sessions.php on line 31

> 
> My 1.5.5a ZenCart uses a database that I imported from an old 1.3.8 installation where I used to use the old version of Stocks By Attributes. Could this be a cause for any of the issues I am having here?
> 
> Thanks
> 
> Dene
Check your includes/functions/functions_general.php file to see if the function zen_get_ip_address exists. 

That is the function reportedly missing. I realize that the file is not modified by this code and don't really see a specific reason that the file would have been touched, but that's the first place I would look.

Then having looked at the load sequence for ZC, the other thing(s) that seem like it could be is something say that was off about the added admin/includes/auto_loaders file for SBA, though I thought the filename remained the same in all of these edits so the newest install would correct whatever was a problem there.

As to historical things, well in a post on the previous page you indicated that the download overwrote an admin/includes/functions/extra_functions file. ZC doesn't come with any files in that directory and the fact that it was one to be overwritten indicates that one or more other files from a previous version of SBA existed. As such, it is difficult to identify what files are interacting poorly or to that extent without being identified what other changes have been made to the store that could be causing this. 

No the database modifications made by SBA, whether current or historical would not cause an issue provided files aren't looking for/acting on those changes.

Uploaded several changes to the github location. Seems to me that would consider uploading to ZC after a little work on the customid management. But let me try to identify some things that might be of interest:

1. Supports edit orders. Tested on version 4.1.7. As currently written, EO does require at least the insertion of one line if you use the SBA added option type of 'SBA Select List (Dropdown) Basic'. If using the current version of Product Attribute Grid, then one additional line would be necessary or a modification to a few lines in that plugin which is to be updated shortly. If you don't use either the PAG plugin or the added option name then no modification to EO is necessary.

Locate in admin/edit_orders.php a section that has this code (at or around line 998):

                switch($optionInfo['type']) {
                    case PRODUCTS_OPTIONS_TYPE_ATTRIBUTE_GRID:
                    case PRODUCTS_OPTIONS_TYPE_RADIO:
                    case PRODUCTS_OPTIONS_TYPE_SELECT:

and add before the first case statement:

                    case PRODUCTS_OPTIONS_TYPE_SELECT_SBA:
                    case PRODUCTS_OPTIONS_TYPE_GRID:

So that it would look like:

                switch($optionInfo['type']) {
                    case PRODUCTS_OPTIONS_TYPE_SELECT_SBA:
                    case PRODUCTS_OPTIONS_TYPE_GRID:
                    case PRODUCTS_OPTIONS_TYPE_ATTRIBUTE_GRID:
                    case PRODUCTS_OPTIONS_TYPE_RADIO:
                    case PRODUCTS_OPTIONS_TYPE_SELECT:

Features added to as part of EO: when adding a product, if the SBA attribute selection does not exist then the product will not be added, with an error message provided. Also when adding a product, if the store is set to prevent overselling product then the admin will be notified if the quantity entered will cause the product quantity to go below 0. Such a restriction does not exist for editing a product mostly because there are so many additional variations available as to what is going on or what is to happen next. But when updating, if the SBA attributes selected are non-existent then the product will be updated with whatever data has been entered except the attributes. The problem attributes are listed in the provided error message as well as references to identify which record's attributes were not updated.
2. Dynamic Dropdowns now support Read-Only Attributes and still be able to show the quantity of stock available at whatever the last available selection is.
3. Dynamic Dropdowns now offers only attribute combinations that have been defined as a variant when showing out-of-stock quantities (Ie. if a product with attribute 2 value 1 is only offered with attribute 1 value 1 then when selecting attribute 1 value 2 that "special" option will not be shown as out-of-stock unless the variant exists in the database. Or in "real world" discussion, if blue shoe laces can only be offered with yellow shoes, then when presenting blue shoes, the blue shoe laces should not even be visible). From my reading the term for this appears to be dependent attributes; however, there is no current support to provide some alternate option such as instead of laces to change to tread trim. Tread trim would have to have already been defined as one of the attributes associated with the shoe.
4. It is in part possible but not necessarily advised to control read only attributes as products/variants such that specific read only attributes are applied to specific combinations of other attributes. Changing of the read only content is not yet afforded, but basically the read only attribute(s) displayed would serve as an attribute option and would show up on the shopping cart and beyond as a selected attribute. This feature does not appear to currently be supported by Edit Orders.
5. Improvements/modifications were made to the code for the admin products SBA/PWA entry area:
a. the search text box was made as a default area when the page loads.
b. when selecting a box/field for edit in the table the field is made active with the cursor at the beginning of the field.
c. the javascript was put through a javascript evaluator to ensure compatibility/functionality with improvements made.
d. the designation used for field recognition was modified to a more human readable format instead of using a numerical designation that had no specific relationship. This change in process will allow the addition/growth of other related fields and make them easier to update.
e. a link to the attribute controller for the product was added to make reaching the modification area of the product's attributes easier.

Potentially a few other improvements depending on when you last downloaded the code.

Enjoy, and please let me know if there are issues with the code, I'd be glad to get it resolved/fixed.

Actually, with regards to the above about PRODUCTS_OPTIONS_TYPE_GRID, I've submitted an updated copy of Product Attribute Grid to have the grid product type established/set so that it will work with Edit Orders. This means that only PRODUCTS_OPTIONS_TYPE_SELECT_SBA needs to be addressed. I will be submitting a request to edit orders to add that attribute type to the program. An unfortunate alternative is to work through all of the javascript that might be needed in order to visually support the option(s). While that is desirable it would/will take a bit of time to implement considering how edit orders handles/displays attributes far differently than how the ZC store front does.

Question with regard to 1.5.5b comparability. Is it necessary to download from GitHub (https://github.com/mc12345678/Stock_By_Attributes_Combined) or does the 5.1.3 link in the Plugin area have the same files (https://www.zen-cart.com/downloads.php?do=file&id=202%29?

Also, if GitHub is required do you install just the 1_5_5 files or do you first install 1_5_1 then 1_5_3/4 then 1_5_5 to get all the required files? Also, on GitHub there is a second set of admin and includes folders at the top level (not down in 1_5_5). Are these also installed at some point in the process?

Thanks for this highly useful feature for ZenCart.

rhenrie:

Question with regard to 1.5.5b comparability. Is it necessary to download from GitHub (https://github.com/mc12345678/Stock_By_Attributes_Combined) or does the 5.1.3 link in the Plugin area have the same files (https://www.zen-cart.com/downloads.php?do=file&id=202%29?

Also, if GitHub is required do you install just the 1_5_5 files or do you first install 1_5_1 then 1_5_3/4 then 1_5_5 to get all the required files? Also, on GitHub there is a second set of admin and includes folders at the top level (not down in 1_5_5). Are these also installed at some point in the process?

Thanks for this highly useful feature for ZenCart.

As a good zenner, by now you probably have already downloaded the software and on your test site, you have begun trying to install it. Further then you may have begun to see how the file layouts apply, how if you applied the files of the earlier fileset that, one probably the store doesn't work in some ways/regards, two you'll be redoing a lot of things, three as additional observers have been added to ZC, some of the code changes have become unnecessary and are addressed through observers, so files would be unnecessarily modified to support operation already supported by ZC.

Anyways, I believe that all of the questions asked above are answered in the following posts (and I'm sure there are more that are similar in this thread as well as in others).

Please see/read posts #2659, #2648, #2587, and #2571.

Basic thing: github is up-to-date, ZC version of the software at this time works only for older ZC versions, but there are some that have been able to get it to work through incorporation of the applicable changed portions of the code. All systems need the base includes and admin folders, then the files applicable to the current ZC version can be installed/merged.

Has anyone tried this plugin using version 1.5.5?

jodean:

Has anyone tried this plugin using version 1.5.5?
When you say "this" plugin. What are you considering the source of the files to be?

Stock by Attributes - Version: 1.5.3

jodean:

Stock by Attributes - Version: 1.5.3

Version 1.5.3 as available for download in the plugins version is strictly compatible with ZC 1.5.1, would require care to merge with any more recent version, and is missing a large number of improvements that have been made to the plugin. If I may suggest, please read backwards in this forum on how to obtain a copy of the plugin that has been made compatible with ZC 1.5.5 and previous versions of ZC 1.5.x.

I want to thank the github user @jodeantn that pointed out an issue with the ZC 1.5.5 file(s) includes/templates/YOUR_TEMPLATE/templates/tpl_checkout_confirmation_default.php and equivalently includes/templates/YOUR_CLASSIC_RESPONSIVE/templates/tpl_checkout_confirmation_default.php. Apparently when arriving at the checkout_confirmation page, an error was generated in the logs folder and the remainder of the page/final checkout was affected. Issue #43 at the github storage location provides some more detail. The error was similar to:

PHP Fatal error: Call to undefined method  payment::process_form_params() in public_html/includes/templates/YOUR_TEMPLATE/templates/tpl_checkout_confirmation_default.php  on line 205 Line 205   echo zen_draw_form('checkout_confirmation',  $form_action_url, 'post', 'id="checkout_confirmation"  onsubmit="submitonce();"' . (is_array($payment_modules->modules) ?  $payment_modules->process_form_params() : ''));

Where YOUR_TEMPLATE would be expected to be the foldername for the active template for the user visiting.

The fix involves removing a portion of code that was incorporated into the SBA provision of the files for ZC 1.5.5 in December 2016, expecting that the PayPal InContext code provided/referenced in the solution would be used/considered. That appears to still be out for debate, but I didn't remove the following snippet until today about 15 minutes ago.

Applicable only to copies that were downloaded sometime between December 18, 2016 and today January 31, 2017:
To fix existing installations/downloads of the ZC 1.5.5 templates (although this code was not specifically marked as being applicable to SBA) then need to modify as applicable both
includes/templates/YOUR_TEMPLATE/templates/tpl_checkout_confirmation_default.php
and
includes/templates/YOUR_CLASSIC_RESPONSIVE/templates/tpl_checkout_confirmation_default.php

and change this: (portion to be removed in red color)

echo zen_draw_form('checkout_confirmation', $form_action_url, 'post', 'id="checkout_confirmation" onsubmit="submitonce();"' . (is_array($payment_modules->modules) ? $payment_modules->process_form_params() : ''));

to this:

echo zen_draw_form('checkout_confirmation', $form_action_url, 'post', 'id="checkout_confirmation" onsubmit="submitonce();"');

See issue #1192 on the ZC github for updates on incorporating the PayPal Incontext code that would be needed to support keeping the file(s) the way they were.

I'm running SBA v1.5.4 with Zencart v1.5.5d with a Sheffield Blue template on PHP v5.4.45.
Although it seems to be working, when an order is placed, there is an intermittant problem in that the stock levels are not updated. I've tested it and it always seems to work, but when real orders some in, about 1 in 3 does not have the stock levels updated.

Any idea where to start looking?

ttfan:

I'm running SBA v1.5.4 with Zencart v1.5.5d with a Sheffield Blue template on PHP v5.4.45.
Although it seems to be working, when an order is placed, there is an intermittant problem in that the stock levels are not updated. I've tested it and it always seems to work, but when real orders some in, about 1 in 3 does not have the stock levels updated.

Any idea where to start looking?

Stock adjustment code resulting from a purchase is located in the includes/classes/order.php flowpath. SBA latches onto that operation using the observer class on the catalog side in includes/classes/observers. Next is the notifiers with the order class.

Could you please identify when the files were downloaded?

@ttfan,

Also, the product to which this is being reported against, how are it's variants populated? Is it product that has only one option name (one attribute) or product that has multiple option names (multiple attributes)? If multiple option names, is the stock populated such that each attribute has its own stock quantity or as a combined variant where a set of attributes each has its own quantity?

Files were downloaded about 2 months ago, it was installed by Anne from Picaflor Azul.

Each product has one attribute,called "colour/thickness", and the options are for example "red 2.2mm", "black 2.0mm". There are different quantities for each of these options.
As I mentioned, when I test this, it seems to work properly, and the quantity (both the total and the particular attribute) is updated correctly, but it fails regularly for actual orders.

ttfan:

Files were downloaded about 2 months ago, it was installed by Anne from Picaflor Azul.

Each product has one attribute,called "colour/thickness", and the options are for example "red 2.2mm", "black 2.0mm". There are different quantities for each of these options.
As I mentioned, when I test this, it seems to work properly, and the quantity (both the total and the particular attribute) is updated correctly, but it fails regularly for actual orders.
Okay. I want to make sure that we are both talking about the same "setup" because each of the three "styles" of listing product as a variant has a different consideration and can take different paths in the code.
So, in the catalog option names area, you have one option name that is called colour/thickness. And when you go to the option values menu, in the dropdown to add a new option value you have a single selection in that list that reflects colour/thickness. And then for every possible combination of those you have an option value listing black 2.0mm, or red 2.2 mm.

Then in the attributes controller, you have one option name group of colour/thickness with all of these combinations listed as a single row for each combination.

Then in the products with attributes stock table under the catalog option, you have for a product that is to be tracked by stock again a single row for each combination and when you go to add variants for the product you have a single dropdown with text boxes below it. All correct so far?

And then you are able to adjust the quantity of the individual variants from the admin screen.

Now you are saying that when you try to make a purchase on your own, the quantities are being reduced, but somehow you are saying/identifying that when others are permitted access and make a purchase that the quantities are not reducing.

I'm curious about how you have identified the lack of reduction and if you can determine anything about what is going on at the store at the time when it seems like stock is not being reduced. I also question the date on which the software was obtained because there was some changes to the stock decrement portion that were made on Oct 11th because the code was not robustly considering all three of the above options. All three styles/methods were tested without issue, but it seems that somehow from the above that perhaps the testing was not robust enough to identify the issue(s) similar to what you are claiming.

So were there multiple people shopping at the time of the issue? Were they all working with the same product, did some of them have items stored in theirtfom a previous browse? Did they all submit their purchase at the same time?

All-in-all I might suggest placing the files that are in the base includes and admin folders over your existing version of those files and trying/seeing again how things go. Of course would rather have the new files compared against the old to see what has changed in the observer that might affect that operation, but seems better to get back on track and know that the recent files are in place rather than guess.

Trying to also see if there is a database cache issue, does it seem to relate to the number of SBA tracked items in the cart and/or the mix of those? (like all items of the same product but different attributes?) I plan on running some more tests but would like to try to target them as much as possible.

I continue to read through the code to see what issues seem likely/plausible.

Thank you so much for looking into this. Sorry I've taken so long to reply, but I'm struggling to get my head around how this works, as I'm no programmer.

mc12345678:

Okay. I want to make sure that we are both talking about the same "setup" because each of the three "styles" of listing product as a variant has a different consideration and can take different paths in the code.
So, in the catalog option names area, you have one option name that is called colour/thickness. And when you go to the option values menu, in the dropdown to add a new option value you have a single selection in that list that reflects colour/thickness. And then for every possible combination of those you have an option value listing black 2.0mm, or red 2.2 mm.

Then in the attributes controller, you have one option name group of colour/thickness with all of these combinations listed as a single row for each combination.

Then in the products with attributes stock table under the catalog option, you have for a product that is to be tracked by stock again a single row for each combination and when you go to add variants for the product you have a single dropdown with text boxes below it. All correct so far?

And then you are able to adjust the quantity of the individual variants from the admin screen.
Yes that is correct

mc12345678:

Now you are saying that when you try to make a purchase on your own, the quantities are being reduced, but somehow you are saying/identifying that when others are permitted access and make a purchase that the quantities are not reducing.

I'm curious about how you have identified the lack of reduction and if you can determine anything about what is going on at the store at the time when it seems like stock is not being reduced. I also question the date on which the software was obtained because there was some changes to the stock decrement portion that were made on Oct 11th because the code was not robustly considering all three of the above options. All three styles/methods were tested without issue, but it seems that somehow from the above that perhaps the testing was not robust enough to identify the issue(s) similar to what you are claiming.
We don't have high volume sales, and although we have a large catalogue of item, we only have small quantities of each. We keep double records while we're testing, which is how we know it's failing regularly.

mc12345678:

So were there multiple people shopping at the time of the issue? Were they all working with the same product, did some of them have items stored in theirtfom a previous browse? Did they all submit their purchase at the same time?

All-in-all I might suggest placing the files that are in the base includes and admin folders over your existing version of those files and trying/seeing again how things go. Of course would rather have the new files compared against the old to see what has changed in the observer that might affect that operation, but seems better to get back on track and know that the recent files are in place rather than guess.
It's highly unlikely multiple orders were placed at the same time, as out shop is low volume, and in most cases different items are purchased.

ttfan:

Thank you so much for looking into this. Sorry I've taken so long to reply, but I'm struggling to get my head around how this works, as I'm no programmer.

Yes that is correct

We don't have high volume sales, and although we have a large catalogue of item, we only have small quantities of each. We keep double records while we're testing, which is how we know it's failing regularly.

It's highly unlikely multiple orders were placed at the same time, as out shop is low volume, and in most cases different items are purchased.

All of the "consternation" is understandable. There's a lot of things that have to fall together to first even get results, then there are a number of twists and turns that could exist and explain why one feature or another doesn't work as expected.

From the description of the setup, right now I'm considering without additional "this is how I can make it happen again" data, that the issue is either out-dated code because there was a period around Oct 11th, 2016 when the stock decrement calculations/actions were changed with the expectation of handling the decrease of stock for any type of "allowed" variant combination. In your case, it appears that a variant is a single entry, no combinations with other things.

Couple of answers to questions can help resolve the issue, the first is to identify if the code contains expected information. If you could please access the file: includes/classes/observers/class.products_with_attributes_stock.php and then around line 442 possibly as far down as line 489, look for the function: updateNotifyOrderProcessingStockDecrementBegin.
If you could please copy the code of that function.
Then if you could reply to this message, select the # symbol in the message box toolbar to generate ```
[CODE][/CODE]

So another question is how is the includes/classes/order.php file different from the standard/vanilla version of that file?

What other plugins are installed?

When looking at the product, purchases, type of product in the order(s), etc, what commonalities are found? Did the lack of decrease observed have anything to do with the remaining amount and the amount purchased? (ie. Was that the last available quantity and it didn't go out of stock, or any other information to help.)

Do the product have a maximum and is it limited by a mixture? Ie. Is there a case involved that limits the total quantity that can be purchase say to 5 and the customer can pick a total of 5 of the associated items, but only a total of 5, not 5 of each type of attribute? That type of thing.

Another relates (though I don't think it would be a specific reason for the issue) is the setting of using Dynamic Dropdowns, is it as most robust set to be active only when multiple attributes are involved?

Here is the code you requested:

function updateNotifyOrderProcessingStockDecrementBegin(&$callingClass, $notifier, $paramsArray, &$stock_values, &$attribute_stock_left = 0){
    global $db; //, $pwas_class;

    $this->_stock_values = $stock_values;

    if ($this->_orderIsSBA && $stock_values->RecordCount() > 0) {
      // kuroi: Begin Stock by Attributes additions
      // added to update quantities of products with attributes
      // $stock_attributes_search = array();
      $attribute_stock_left = STOCK_REORDER_LEVEL + 1;  // kuroi: prevent false low stock triggers
      $this->_attribute_stock_left = $attribute_stock_left;

      // mc12345678 If the has attibutes then perform the following work.
      if(isset($this->_productI['attributes']) and sizeof($this->_productI['attributes']) > 0){
        // Need to identify which records in the PWAS table need to be updated to remove stock from
          // them.  Ie. provide a list of attributes and get a list of stock_ids from pwas.
          // Then process that list of stock_ids to decrement based on their impact on stock.  This
          // all should be a consistent application.
        // mc12345678 Identify a list of attributes associated with the product
        $stock_attributes_search = $_SESSION['pwas_class2']->zen_get_sba_stock_attribute(zen_get_prid($this->_productI['id']), $this->_productI['attributes'], 'order');
        $stock_attributes_search_new = $_SESSION['pwas_class2']->zen_get_sba_attribute_info($this->_productI['id'], $this->_productI['attributes'], 'order', 'ids');
          if (isset($stock_attributes_search_new) && $stock_attributes_search_new === false) {
              
          } elseif (isset($stock_attributes_search_new) && is_array($stock_attributes_search_new) && count($stock_attributes_search_new) == 0) {
              
          } elseif (isset($stock_attributes_search_new) && $stock_attributes_search_new && count($stock_attributes_search_new) > 0) {
              foreach ($stock_attributes_search_new as $stock_id) {
                  // @todo: address in PWAS table whether particular variant should be altered with stock quantities.
                  $get_quantity_query = 'SELECT quantity from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id=' . zen_get_prid($this->_productI['id']) . ' and stock_id=' . (int)$stock_id;
                  $attribute_stock_available = $db->Execute($get_quantity_query, false, false, 0, true);
                  if (true) { // Goal here is to identify if the particular attribute/stock item should be affected by a stock change.  If it is not, then this should be false or not performed.
                      $attribute_stock_left_test = $attribute_stock_available->fields['quantity'] - $this->_productI['qty'];
                      $attribute_update_query = 'UPDATE ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' SET quantity="'.$attribute_stock_left_test.'" where products_id=' . zen_get_prid($this->_productI['id']) . ' and stock_id=' . (int)$stock_id;
                      $db->Execute($attribute_update_query, false, false, 0, true);
                      if ($attribute_stock_left_test < $attribute_stock_left) {
                          $this->_attribute_stock_left = min($attribute_stock_left_test, $this->_attribute_stock_left);
                          $attribute_stock_left = $this->_attribute_stock_left;
                      }
                  }
              }
          }
          
/*        $get_quantity_query = 'select quantity from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id="' . zen_get_prid($this->_productI['id']) . '" and stock_attributes="' . $stock_attributes_search . '"';
        $get_quantity = $_SESSION['pwas_class2']->zen_get_sba_attribute_info($this->_productI['id'], $this->_productI['attributes'], 'products', 'stock');
  
        // mc12345678 Identify the stock available from SBA.
        $attribute_stock_available = $db->Execute($get_quantity_query, false, false, 0, true);  
        // mc12345678 Identify the stock remaining for the overall stock by removing the number of the current product from the number available for the attributes_id. 
        $attribute_stock_left = *//*$attribute_stock_available->fields['quantity']*//* $get_quantity - $this->_productI['qty'];
  
        // mc12345678 Update the SBA table to reflect the stock remaining based on the above.
        $attribute_update_query = 'update ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' set quantity='.$attribute_stock_left.' where products_id="' . zen_get_prid($this->_productI['id']) . '" and stock_attributes="' . $stock_attributes_search . '"';
        $db->Execute($attribute_update_query, false, false, 0, true);  
        //$this->_attribute_stock_left = $attribute_stock_left;*/
      }
      $attribute_stock_left = $this->_attribute_stock_left;
    }
  }

  /*
   * Function that is activated when NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_END is encountered as a notifier.
   */
  // Line 776
    /**
     * @param $callingClass
     * @param $notifier
     * @param $paramsArray
     */

Very few plugins are installed at this stage, as we're still trying to get things working. The plugins are: CK editor & image handler, as well as stock by attributes of course.

I can see no commonalities between orders that pass/fail, except that the ones fails always have the atrributes discussed above. Items with no attributes work properly.