Dynamic Price Updater

mvstudio:

I didn't see a css file for the plugin. The templates folder only contains a jscript and sideboxes folders.
Correct, the plugin's folders do not contain a css file. What I was referring to was that your site did not load from my mobile device because of some problem on the site. Part of the observatio of that problem was that css would not get applied to the html objects because of whatever the error was.

Now, today, I tried to access your site to see if it was the jquery 1.7.1 or some other issue that is causing the problem. Right now I see two console errors through firefox:

onload@http://www.byvalenti.com/bvostoretemp/index.php?main_page=product_info&cPath=8_9&products_id=4:2:3
index.php:4:3
Use of getPreventDefault() is deprecated. Use defaultPrevented instead. jscript_jquery-1.7.1.min.js:3:6598

The first is because it appears that only part of this plugin has been removed (includes/modules/pages/product_info/jscript_dynamic_price_updater.php) for some reason. Mind you the image replace option could have been turned off so that there wouldn't be a spinning image to possibly stay behind... I've again tested the specific change(s) on my site without problems or javascript errors.

The second because of the use of jquery 1.7.1... Would suggest looking into the ability to update/upgrade the zx Slideshow or at least to try to use newer jquery.

Thank you for looking into that.
The first the file is on the folder, however I turned off the pluggin as I spent the weekend installing other modules required for the site/tweaking overall design and the spinning image was making it harder to see the changes.
The second, the jquery 1.7.1 is the file on the latest version of the pluggin, go figure. I'll locate an updated version and see if that makes a difference.
I'll keep you posted.
Thank you again for looking into it.

I've updated to the latest jquery I could find 1.9.1, no change.
I deleted both files from the server the 1.7.1 and 1.9.1 and no change. The wheel keeps on spinning non-stop.
I've checked the error log, nothing is generated so I'm assuming everything works the way it should.
I'm going to leave the DPU on with the latest jquery installed for you to check it out.
Thank you again for looking into it.

mvstudio:

I've updated to the latest jquery I could find 1.9.1, no change.
I deleted both files from the server the 1.7.1 and 1.9.1 and no change. The wheel keeps on spinning non-stop.
I've checked the error log, nothing is generated so I'm assuming everything works the way it should.
I'm going to leave the DPU on with the latest jquery installed for you to check it out.
Thank you again for looking into it.

Preliminary review has identified "two", no actually three things. One which would be resolved by not using the replacement image, seeming to cause the problem with the image. :)

There is either some setting or condition that is causing the change of the attribute to attempt to access the login page (which has also been seen "randomly" by attempting navigate the site) I don't know if this is a session issue or what is causing it, but that is one response which is causing trouble and seems to be the reason that the image does not clear as the page is being redirected and I'm not logged in. If being logged in ends up being a criteria for use of this on your server because of your setup, then it could be disabled until the user is logged in as part of the initial load sequence. I could guide you to that if necessary and if the observation is your expected process.

The third thing possibly, which would likely at least resolve a part of the overall issue is that upon first attempt to access the data, a proxy authentication required message was received one time which is then processed, but by that point the ajax has already been considered to basically have failed and no further action is/was taken in a way. (After additional network monitoring, I'm not so sure that this is the specific problem or just something else that was observed at the same time as the issue occurring.) Haven't stepped through the entire transmission/response cycle sufficiently to identify which part of the process causes the loss of the onscreen restoration that was seen, but there is the possibility of incorporating some additional "retry" code to work through the authentication request that was seen to occur.

Thank you for looking into it. I really appreciate the time you've invested.

So, thing number 1, turned off the loading graphic, price doesn't update at all, logged in or not. I also tried having the loading graphic turned on, while logged in, nothing, no change on the perpetual spinning. I would like the price updater to work whether the client is logged in or not.

I turned off all the modules I could, to see if that would make a difference and no change.

I'm turning off the module for the time being until we can figure out what's the issue.

Thank you for all the effort you've put into it. =)

mvstudio:

Thank you for looking into it. I really appreciate the time you've invested.

So, thing number 1, turned off the loading graphic, price doesn't update at all, logged in or not. I also tried having the loading graphic turned on, while logged in, nothing, no change on the perpetual spinning. I would like the price updater to work whether the client is logged in or not.

I turned off all the modules I could, to see if that would make a difference and no change.

I'm turning off the module for the time being until we can figure out what's the issue.

Thank you for all the effort you've put into it. =)

The issue appears to have initially been whatever is in place (or not) that is requiring a user to be logged in. Not so much that the individual is or is not logged in, but something I found just in navigating the site is that sometimes when trying to change to another page I am redirected to the login screen... Sometimes I am not.. Do you have some sort of additional session handling/handler? BTW, since the software is completely turned off, there is no way that I can identify anything further because this is something affecting your site specifically and for some reason... I can't recreate it on anything that I operate. If it could remain enabled but without the replacement image then at least it could be further investigated/tested and at least one can see the base price (rather than the price being hidden by a spinning dial).

Otherwise, if you wish to figure it out on your own, I suggest you become familiar with the debugger of the browser of your choice. There are some javascript related issues that were identified with your particular page (outside of this plugin) and as far as "finding" a newer jquery, your particular ZC store already has 1.12.0 and therefore there is no other jquery that needs to be loaded (assuming that the other software needing jquery can operate in that environment.)

On second thought, what "change" are you expecting to see? The example product that I have seen technically contain only one attribute. Therefore, the price displayed is the only price to be displayed... Just after I posted the above, I went to the site and the plugin was still enabled... I didn't see any errors returned and the price was identified as starting at: XX.XX... Therefore from my perspective the plugin was working just fine. Now if there was a product that had two or more attributes where at least two of the attributes had a different price, then maybe we could be talking about the updates not occurring. Of course now that the plugin has actually been disabled I can't do anything further other than report what was observed while it was present.

Right. We were focusing on the perpetual spinning wheel and were not able to actually see the price change not taking effect as it was masked completely by the image. It wasn't until turning off the image loading last night that I realized the price wasn't updating at all and I assumed both events - the perpetual spinning and the price not updating - were related. In this product http://www.byvalenti.com/bvostoretemp/index.php?main_page=product_info&cPath=2&products_id=2 with 2 attributes and two different price points the price doesn't update at all. I've turned the mod back on and removed the image loader for you to see the behavior. No error logs are generated.
Thank you!

mvstudio:

Right. We were focusing on the perpetual spinning wheel and were not able to actually see the price change not taking effect as it was masked completely by the image. It wasn't until turning off the image loading last night that I realized the price wasn't updating at all and I assumed both events - the perpetual spinning and the price not updating - were related. In this product http://www.byvalenti.com/bvostoretemp/index.php?main_page=product_info&cPath=2&products_id=2 with 2 attributes and two different price points the price doesn't update at all. I've turned the mod back on and removed the image loader for you to see the behavior. No error logs are generated.
Thank you!

No thank you for continuing to test. I've sent a PM with some proposed code changes to try to address this. If it works, then I have a good starting point on which to further improvement to get over what looks like a proxy server related issue. If it seems to resolve the issue (or doesn't) I have another idea, but ultimately I can see a need for some code changes to make addressing things like this a little easier/cleaner. I am aware of one solution reported to work, but I'm concerned of the ramifications.

Also, regarding the spinning image and disabling "replace" there is a code change/modification that would allow the image to appear, but not obscure the price(s). An admin switch has not yet been added to do this, but I think it would help.

The subject code change to allow it to appear but not replace the text is to modify includes/modules/pages/product_info/jscript_dynamic_price_updater.php line 49 from:

var imgLoc = "replace"; // Options are "replace" or , "" (empty)

to:

var imgLoc = ""; // Options are "replace" or , "" (empty)

by deleting just the word replace... This will revert DPU back to an "earlier" condition where the image would appear for posterity. :)

Then reenable loading the image from the configuration menu.

Hi all,

just trying a small modification. Actually the plugin is working great, i would like to modify it so that if an article is out of stock (quantity = 0) an image is displayed instead of the price. In the old version of my site i have modified the file \includes\templates\YOUR_TEMPLATES\templates\tpl_product_info_display.php adding around lines 83 (after the // base price start) the following:

//BOF No price if out of stock, show image instead
  //echo $one_time . ((zen_has_product_attributes_values((int)$_GET['products_id']) and $flag_show_product_info_starting_at == 1) ? TEXT_BASE_PRICE : '') . zen_get_products_display_price((int)$_GET['products_id']);
  if ($products_quantity > 0) {
  echo $one_time . ((zen_has_product_attributes_values((int)$_GET['products_id']) and $flag_show_product_info_starting_at == 1) ? TEXT_BASE_PRICE : '') . zen_get_products_display_price((int)$_GET['products_id']);
} else {
  echo "<img src=images/esaurito.gif>";
   }
//EOF No price if Out of stock, show images instead

I've done the same with the new version of my site (which have installed last version of DPU) but after displying the OUT OF STOCK image for a few second, DPU replace it with the price...
Before messing with DPU code I prefere to ask if someone have a good hint on how to have it work.

Thanks

Zencart 1.55e
DPU last version

izar74:

Hi all,

just trying a small modification. Actually the plugin is working great, i would like to modify it so that if an article is out of stock (quantity = 0) an image is displayed instead of the price. In the old version of my site i have modified the file \includes\templates\YOUR_TEMPLATES\templates\tpl_product_info_display.php adding around lines 83 (after the // base price start) the following:

//BOF No price if out of stock, show image instead
//echo $one_time . ((zen_has_product_attributes_values((int)$_GET['products_id']) and $flag_show_product_info_starting_at == 1) ? TEXT_BASE_PRICE : '') . zen_get_products_display_price((int)$_GET['products_id']);
if ($products_quantity > 0) {
echo $one_time . ((zen_has_product_attributes_values((int)$_GET['products_id']) and $flag_show_product_info_starting_at == 1) ? TEXT_BASE_PRICE : '') . zen_get_products_display_price((int)$_GET['products_id']);
} else {
echo "<img src=images/esaurito.gif>";
}
//EOF No price if Out of stock, show images instead

> 
> I've done the same with the new version of my site (which have installed last version of DPU) but after displying the OUT OF STOCK image for a few second, DPU replace it with the price...
> Before messing with DPU code I prefere to ask if someone have a good hint on how to have it work.
> 
> Thanks
> 
> Zencart 1.55e
> DPU last version

So, one of the future features desired for this is to allow it to consider the status of stock of an attribute or attribute combination. Considering that this is being used to support attribute selection, I would think that while you may not have such implemented, that you might have interest in such future capability.  With that in mind, there are a few places I could see some code modification to support the possibility of attribute stock determination without requiring significant rework in the future, or a way to just have DPU not load/activate if the products_quantity within the products table is 0 or less (this part assuming that it is not desirable/possible for the store to "oversell" product).

Most of the modification I would see in the includes/classes/dynamic_price_updater.php file, possibly in the insertProduct function where some data would be collected based on the current selection(s), to test the quantity of product available in the store, and then in prepareOutput to consider that data collected and basically assign the "price" to your html for your image (suggest to build the image using the ZC built in functions rather than "hard coding", but whatever seems to work I guess). This way, when the "price" is replaced, it will update the image with whatever your "sold-out" image is.

If you just want to cut DPU off at the pass, then in the top of includes/modules/pages/product_info/jscript_dynamic_price_updater.php (or includes/modules/pages/YOUR_PRODUCT_TYPE/jscript_dynamic_price_updater.php) add an additional test for no quantity of the product and whatever further "allowance" to disable DPU on this product page and therefore, the image added to your template file will not be displayed.

Then, there is the thought that perhaps the price should be displayable AND an image to be provided... That can be accomplished in either of the above two ways or by modifying the insertion point of the image in the template file to be outside the class identifiers for where the price is to be displayed.  But, it would seem that if that were the case or desired, then the original change would not have been made.  Unfortunately such a modification (not displaying price) also leaves "everyone" in the dark about whether the site is competitive for recently out-of-stock items or as unmonitored/out-of-date for product that remain visible for an extended period of time.

Hi Mc,

as always You are full of ideas and hints!
First thing first, the last one you wrote is something I was considering just know. Why show just the image and not the price? Logically the image showing the OUT OF STOCK status is good, but removing the price could, as You stated, make some customer considering looking elsewhere cause the price is not competitive.
Dunno if this is the better way, commercially speaking, but now that You have highlighted it I could not stop thinking that i have to try it. More, doing so I will avoid a huge coding (It just show an image when the quantity is 0 or below).

Just for coding purpose I've tried to modify the includes/modules/pages/product_info/jscript_dynamic_price_updater.php adding test for quantity, still testing.

Currently i have modified the code and the positioning of the image, if the quantity is 0 or below.
Modified the file :includes\templates\YOUR_TEMPLATES\templates\tpl_product_info_display.php around line 80

<!--bof Product Price block -->

<div id="productOFS">
<!--BOF No price if out of stock, show image instead-->
<?php
  if ($products_quantity <= 0) {
    echo "<img src=images/esaurito.gif>";
   }
?></div>
<!--EOF No price if Out of stock, show images instead-->

<h2 id="productPrices" class="productGeneral">

I also added a class #productOFS in stylesheet.css so to have more control over the display of the image.

izar74:

Currently i have modified the code and the positioning of the image, if the quantity is 0 or below.
Modified the file :includes\templates\YOUR_TEMPLATES\templates\tpl_product_info_display.php around line 80

Btw, note that the image will display any time quantity is less than or equal to zero, even if you choose later to allow back ordering product from your store. Would recommend documenting something regarding that in case you ever choose to allow back ordering and to help on upgrade of your file(s) as well to understand the capabilities/restrictions of the content.

I dont know if this has been mentioned previously or not, but in trying to install DPU, I kept getting a complete site crash on upload. Setting DPU Status to False had no effect on this. I personally am just begaining to learn PHP, so I have no idea as to what incompatibilities I should be looking for, however I do know how to narrow it down to what files in general are the problem-causers.

For referance, I am running Zen-Cart 1.5.5d, and DPU 3.0.8.

Includes > auto_loaders > jscript_dynamic_price_updater is causing the entire site crash. Removing it alone made everything run again, but I'm FAIRLY certain it's an important file to have. This did leave me with compleatly blank screens however, when I went to an actual product discription page.

Removing Includes > modules> pages > product_info > jscript_dynamic_price_updater fixed the white-page issue, but it doesn't matter, as with those two files removed, the module wouldn't work in the first place...

Lordzoabar:

I dont know if this has been mentioned previously or not, but in trying to install DPU, I kept getting a complete site crash on upload. Setting DPU Status to False had no effect on this. I personally am just begaining to learn PHP, so I have no idea as to what incompatibilities I should be looking for, however I do know how to narrow it down to what files in general are the problem-causers.

For referance, I am running Zen-Cart 1.5.5d, and DPU 3.0.8.

Includes > auto_loaders > jscript_dynamic_price_updater is causing the entire site crash. Removing it alone made everything run again, but I'm FAIRLY certain it's an important file to have. This did leave me with compleatly blank screens however, when I went to an actual product discription page.

Removing Includes > modules> pages > product_info > jscript_dynamic_price_updater fixed the white-page issue, but it doesn't matter, as with those two files removed, the module wouldn't work in the first place...
So, when an error occurs, in particular a blank screen, then suggest following the instruction provided here: https://www.zen-cart.com/content.php?124-blank-page

That said, would recommend verifying proper placement of files as there is no: includes/autoloaders/jscript_dynamic_price_updater file. Files that begin with jscript_ are expected to be in a template directory or a directory within includes/modules/pages. Nothing prevents them from being elsewhere, just not common practice and this plugin specifically doesn't have any in the autoloaders directory.

That is actually my bad, I ment to write Includes > auto_loaders > config.dynamic_price_updater, not the jscript. As far as placement goes, I have triple checked my uploads, and everything is where it is supposed to be.

Lordzoabar:

That is actually my bad, I ment to write Includes > auto_loaders > config.dynamic_price_updater, not the jscript. As far as placement goes, I have triple checked my uploads, and everything is where it is supposed to be.

That will cause a problem of being present if includes/classes/dynamic_price_updater.php is not in place or not fully loaded to the system

Again though the logs as described in the above link would help to identify the issue otherwise we will be talking about how things should be and aren't in some way as expected.
.

Lordzoabar:

I dont know if this has been mentioned previously or not, but in trying to install DPU, I kept getting a complete site crash on upload. Setting DPU Status to False had no effect on this. I personally am just begaining to learn PHP, so I have no idea as to what incompatibilities I should be looking for, however I do know how to narrow it down to what files in general are the problem-causers.

For referance, I am running Zen-Cart 1.5.5d, and DPU 3.0.8.

Includes > auto_loaders > jscript_dynamic_price_updater is causing the entire site crash. Removing it alone made everything run again, but I'm FAIRLY certain it's an important file to have. This did leave me with compleatly blank screens however, when I went to an actual product discription page.

Removing Includes > modules> pages > product_info > jscript_dynamic_price_updater fixed the white-page issue, but it doesn't matter, as with those two files removed, the module wouldn't work in the first place...
Although the above information at least implies that the installer ran (admin->configuration for DPU is present) when reviewing the jscript_ file in the product_info page, one of the first things that is in that file is a test of a database define. If the system were in strict mode and the database settings were removed, but this file was not, then an error would be logged. (not a condition expected here because the database settings were present.) still, there is no real reason to leave that line of the file as is, so will be making a change there. As to removing the autoloader file which in turn wouldn't load the dpu class and have it available for that file? I'm not so sure that coding for that condition is the real right thing to do as it imples that for any program that is installed that it should check on each use that the package is installed. Perhaps during installation or as requested this makes sense, but not each and every time it is used. For example the language class isn't exactly verified for presence by a specific if test, but it is by use of a require.

I (and I'm sure others) would be interested to know what the issue(s) are/were with this install. If you did receive log files (myDebug) would you mind sharing the pertinent contents? If you figured out what wasn't fully/properly installed would you mind sharing as well?

I apologize if I came off too hard with my previous post(s). I allowed the current pressure to resolve some minor things to interfere with my normal patient support.

So back to the file removal scenarios. Removal of the autoloaders file from the catalog side will in fact prevent the dpu class from loading and will cause a cascade of non-functionality since that file does the central processing of the data. Removal of the jscript_ file from the product_info pages directory will prevent "communication" between the user and DPU, but won't generate an error.

With both files in place there are a number of points in between that could have a problem if the upload didn't complete (partial file uploaded) or if there was some other related issue. This is where the debug logs would help rather than guessing at all the possibilities. So, if you wouldn't mind posting back, would appreciate it

That's fine. I compleatly understand stress from a thousand minor issues building up.

After finally figuring out that the write permissions for our Logs folders were turned off..... (I inherited the site maintainance from someone else, in order to clean up their mess...) This is what I've got.

[B] PHP Parse error: syntax error, unexpected '(float)' (double) (T_DOUBLE_CAST) in /home/athensar/public_html/includes/classes/dynamic_price_updater.php on line 200

Line 200 reads:

      $this->shoppingCart->contents[(int)$id] = array('qty' => (empty((float)$qty) || (float)$qty < 0 ? zen_get_buy_now_qty((int)$id) : (float)$qty)); //(float)$qty);