mc12345678 / dynamic_price_updater Goto Github PK

At this line, the value being compared/reviewed is not cast to nor ensured to be a number that can be looked up in the SQL query and therefore the query appears as products_options_values_id =

and no value to the right of it. This should be changed to casting the $value to an integer instead or use bindVars so that the number of 0 will show up on the line instead of possibly an error being thrown.

One feature of DPU that appears could be beneficial is the ability to adjust the quantity of product available "on-the-fly". The problem is that in a default store, the quantity displayed on the product information page is captured within class productDetailsList if it is even to be displayed which (in responsive) is within the class group grids, but basically the default template does not contain sufficient "unique" information to be able to "point" at a piece of information and know that it is the correct one to be updated. Further, don't really want to take control of the system in order to display the information associated as there are just too many other potential variables to get in the way. Ideally each of the items would be identified via template to contain information that could be used by CSS, javascript or jquery. Need to submit a few PRs to make this happen and/or include instruction on how to apply the data.

Not sure, but DPU may be looking for attributes versus an item Priced by Attributes.

Case in point at silversageherbsDOTcom/_test/index.php?main_page=product_info&cPath=73&products_id=244. Since a text box should have no effect on the pricing of an item, you's expect nothing to happen as a person types in their Gift Message. Actually, as you type the message, the item price resets with every keystroke.

Same happens on https://silversageherbsDOTcom/_test/index.php?main_page=product_info&cPath=71&products_id=181 where the only selection is spray versus dropper.

Neither product is priced by attribute.

Fresh ZC155e installation.
Messagestack says installed ok but menu item does not appear on configuration menu.
DB entries for configuration and configuration_group are installed but admin_pages no.

At the time of writing this plugin it would seem that the user input field of "numbers" was not on the list of ways to provide input. That said, its time has come and should now be recognized. This is at least addressed in 6c2b93d and needs to be merged into the master thread along with a few other changes.

The numbers type allows more than one method of entry: arrow button(s) on the field, entry directly in the field and up/down incrementing depending on the browser and its implementation of the field. All actions as described available in internet research have been captured using addEventListener so that it does not overwrite any other events of the same type on the same "object".

During testing on a store that had Product Attribute Grid installed, noticed that changing the quantity associated with a grid did not generate the "expected" results (a change in the price based on a change in quantity). Certainly the code worked as written; however, to resolve this scenario it seems like if DPU had a notifier event for data collection that the quantity associated with PAG or any other plugin could be properly incorporated. This would also prevent a need to customize DPU for each such attribute type that is presented leaving the modification to the additional option name type.

When a product has a tax rate applied to it, after modifying an attribute selection the price is updated to include the tax even if the tax was already factored into the price for the original display.

This was caused by a partial edit to the includes/classes/dynamic_price_updater.php file in the prepareOutput function, line 116. The desire was to setup a way to return both prices of including and excluding the tax to be handled/managed as necessary in the javascript. Problem is that the operation as modified only accurately supported adding tax when the cart was set to not display tax on the store side, but then that one "difference" causes other issues.

The other "reason" for this being an issue is that the price as returned by this class is determined by the result(s) of a temporary shopping cart, such that the calculated price is the cost associated with the on screen quantity of product without consideration of the quantity in the cart. For this issue, basically stating that if the catalog side is to display the price's item with tax, then the shopping cart price would already include the tax price and no further/additional tax would be necessary. If the catalog were to display price without tax, then same thing no modification of the price is necessary to show the product's price.

Therefore, the solution to this is to basically restore line 116 from:

      $this->responseText['priceTotal'] .= $currencies->display_price($this->shoppingCart->total, zen_get_tax_rate($product_check->fields['products_tax_class_id'])/* 0 */ /* DISPLAY_PRICE_WITH_TAX */);

Back to:

      $this->responseText['priceTotal'] .= $currencies->display_price($this->shoppingCart->total, 0/* 0 */ /* DISPLAY_PRICE_WITH_TAX */);

Further development/coding needed to support returning both inc/exc prices either by using/reusing an existing plugin that is installed or incorporating the code from that plugin to here so that there is no dependency on it. Likely would consider adding two additional responseText fields, priceTaxInc and priceTaxExc.

When the javascript is collecting data about the current product and template options, if the imgLoc is not set to replace, then there are portions of the data collection that are not performed such as the pspClass which is used later when data has come back from DPU.

Because this is primarily an attribute "response" plugin, if the selection of attributes results in no attributes on the product, then the price is incorrectly reported as 0 after initially selecting an attribute and then returning the status back to the original condition. This condition should be addressed to prevent the price from being mistakenly reported as 0.00.

A couple of options that come to mind is:

1. Capture the original state (price/weight/etc..) upon page load and then if the selections return to that state then redisplay that value.
2. For price, evaluate the resulting price as compared to the calculated price and determine if the base price should be used.
3. Check to see if the product should have attributes and if it should and none are on the cart, then provide the base price. (This could be subjective because some attributes are not required, but presumably if the product has attributes and there are none associated with the object in the cart then the price should more than likely be or start at the current "lack of selection".) It doesn't necessarily mean that the product can be added to the cart, but at least doesn't present a price of 0.00.

Proposal for PHP 7.2 is that loops which are built like:

while (list($x, $y) = each($z)) {
} 

are to removed/replaced with:

foreach ($z as $x=>$y) {
} 

This type structure appears often in this code at least in the class file.

This plugin establishes its own interface to communicate with ZC through AJAX; however, as of ZC 1.5.4, there has also been a framework variable available of zcJS that supports similar communication with a number of "built-in" features.

This plugin uses XML to communicate with the server; however, to obtain/use related data "cleanly" the same information needs to be made available in JSON form in order to be processed by zcJS "properly". The current plan is to maintain the existing method as a possibility for "backwards compatibility" but to also make it available in JSON for "future" versions. Technically all of the data could be collected in one format and then processed accordingly, but with the age of this plugin it seems like changing that data structure could be problematic for other versions in the wild. Ideally, the JSON data structure could be picked up and used as necessary to support those other alterations, but doesn't need to do so right now.

If a product has populated the quantity discounts associated with an attribute, but has not also
populated the price of the attribute (first value to be used/considered when using such quantity discounts), then the "look ahead" for the price of the product based on future selections does not get populated. There are multiple ways to address the issue. One is to force the attribute to have a price even if only the discounts have a price, another is to use the discount quantity when sorting on those values.

As this software is intended to handle the outcome of what is in the database and not necessarily to control what can/can not be added to the database, a software resolution path is being considered. In ZC 1.5.6b, a notifier (ZEN_GET_PRODUCTS_BASE_PRICE) has been added in includes/functions/functions_prices.php allowing the modification of the base price to be returned from the function zen_get_products_base_price. As this is the function used to basically determine the lowest price associated with the product before it is selected, this function seems appropriate to which to attach and mimic in display/operation of the software from this module.

When a web address that includes products_id is forced to require main_page, the result has been for the page to continuously reload when DPU is enabled. This can be resolved by either adding the main_page parameter to the uri or removing the products_id parameter.

If you have configured the store for showing prices including tax and a product is a special, the striked through orginal price is shown by DPU as the net price. Should be the price including tax.
Suggested fix:
includes/classes/dynamic_price_updater.php
line 168
change from
$this->responseText['preDiscPriceTotal'] = $currencies->display_price($this->shoppingCart->total_before_discounts, 0 /zen_get_tax_rate($product_check->fields['products_tax_class_id'])//* 0 / / DISPLAY_PRICE_WITH_TAX */);
to
$this->responseText['preDiscPriceTotal'] = $currencies->display_price($this->shoppingCart->total_before_discounts, zen_get_tax_rate($product_check->fields['products_tax_class_id']), 1 );

The url link for the ajax.php file is "manually" built instead of using the ZC function zen_href_link which would support improved readability of results when viewed by other utilities that depend on links being generated by ZC rather than being pieced together.

Set strict error reporting, on an admin page refresh:

[22-Apr-2019 19:55:14 Europe/Madrid] Request URI: /tienda-156/admin1/index.php, IP address: 127.0.0.1
#1 constant() called at [...\public_html\tienda-156\admin1\includes\init_includes\init_dpu_config.php:114]
#2 require(...\public_html\tienda-156\admin1\includes\init_includes\init_dpu_config.php) called at [...\public_html\tienda-156\includes\autoload_func.php:49]
#3 require(...\public_html\tienda-156\includes\autoload_func.php) called at [...\public_html\tienda-156\admin1\includes\application_top.php:180]
#4 require(...\public_html\tienda-156\admin1\includes\application_top.php) called at [...\public_html\tienda-156\admin1\index.php:10]
--> PHP Warning: constant(): Couldn't find constant DPU_PLUGIN_CHECK in ...\public_html\tienda-156\admin1\includes\init_includes\init_dpu_config.php on line 114.

The code currently includes an action at the end to attempt to activate DPU after the javascript has been loaded (ie. last action to be performed). This is better implemented to be activated after the page has been loaded. The applicable/necessary code has been moved to the onload event within the applicable includes/modules/pages/XXXX directory.

Implementation provided in commit 40722fe. This needs to be merged into the master branch.

  if (0 == $pid) {
    $load = false;
  } elseif (zen_get_products_price_is_call($pid) || zen_get_products_price_is_free($pid) || STORE_STATUS > 0) {
    $load = false;
  }
  $pidp = zen_get_products_display_price($pid);
  if (empty($pidp)) {
    $load = false;
  }

It does not abort when the pid is zero (such as page not found) and so causes various php notices from zen_get_products_display_price using 0.
I did this:

    if ($pid === 0) {
        $load = false;
    } else {
        if (STORE_STATUS > 0 || zen_get_products_price_is_call($pid) || zen_get_products_price_is_free($pid)) {
            $load = false;
        }
        $pidp = zen_get_products_display_price($pid);
        if (empty($pidp)) {
            $load = false;
        }
    }

Identified by @webchills in the ZC forum: https://www.zen-cart.com/showthread.php?70577-Dynamic-Price-Updater&p=1329957#post1329957

If the configuration setting of: DPU_SHOW_LOADING_IMAGE, was set to false the price and other information do not update as expected (update information without use of an image). In review of operation in this configuration there were a few things that require updating.

This plugin seems to do well with showing the final price of a product based on selections made by the customer; however, there are a number of other conditions/factors that could be updated in the "heaviest" product. Ie. A product that is priced-by-attributes, that has a sale and a special... In such a condition, selecting an attribute option technically modifies the base price of the product as well as the final price to be paid. This plugin currently only updates the final price and not the base price or any of the prices in between. (ie. The sale price overriding the special price.)

There has been a request in the ZC forum thread: https://www.zen-cart.com/showthread.php?70577-Dynamic-Price-Updater&p=1333194#post1333194
And the few posts that followed.