Dynamic Price Updater

[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

<!--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.

[mc12345678]

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.

Sounds like a plan. :)

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.

[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...

[mc12345678]

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.

[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.

[mc12345678]

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.
.

[mc12345678]

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

[Lordzoabar]

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); 

[mc12345678]

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); 

Good work sleuthing out the logs folder issue(s). Probably then also saw that that particular issue had been discussed with a solution provided. Since then (a couple of weeks ago) I've also added some features to the mix for an improved user experience.

Take a look at this comparison between version 3.0.8 and the current github software: https://github.com/mc12345678/Dynami...3.0.8...master

It contains a function that I plagiarized from a Pull Request pushed by DrByte for an upcoming ZC release (please follow the depth of that PR for proper credit recognition).

Unfortunately in trying to enforce variable type and value, a little bit of a work around was needed to provide a single function that gives the needed data/value instead of a continued horrid amount of logic each time. :)

Btw, it also was that I was aggrivated at myself that I couldn't better express what was needed so that you (and others) could get through this faster than slower. :)

[Lordzoabar]

SUCCESS!

If I am understanding what you said correctly, the module has issues when presented with a product that has multiple attributes? Our shop deals with custom framing and photo printing/restoration, so I'm assuming when it was requesting product size, paper type, glass type etc... everything else got overwhelmed which led to a full-on crash.

That it's finally working, especially with those stated options, this is an absolute godsend for us. :)