Printable View
The data generated by the php code is fed to the includes/modules/pages/YOUR_PRODUCT_TYPE/jscript_dynamic_price_updater.php which contains the javascript portion to present the results.Quote:
Originally Posted by diamond1
The question is what screen result is to be modified and what change is to be made?
The javascript that processes (handles) the returned data as provided in this plugin is found in the function: objXHR.prototype.handlePrice. So if there is something to be modified about the returned data and to modify it within the javascript it would be in that function and then depending on what is to be modified and how, likely to be within the applicable switch case prior to assignment to this.updateInnerHTML.
I have this but I do not know how to do it
objXHR.prototype.handlePrice = function (results) {
var thePrice = document.getElementById("<?php echo DPU_PRICE_ELEMENT_ID; ?>");
if (typeof(loadImg) !== "undefined" && loadImg.parentNode != null && loadImg.parentNode.id == thePrice.id && imgLoc != "replace") {
thePrice.removeChild(loadImg);
}
You haven't stated what "it" is. I.e. don't know how to do what?Quote:
Originally Posted by diamond1
The code snippet above is the first part of the handlePrice function and to explain what it does is:
1. set a variable thePrice to be the DOM object that has the id of whatever is entered in the database for DPU_PRICE_ELEMENT_ID which is a field in the configuration->Dynamic Price Updater settings.
2. basically, if a loadImg has been defined and it was added/displayed such that it was in addition to the price instead of replacing it, then remove the image. Later if the image *did* replace the text, then the new text would again replace the image. This is/was all to support the possibility of a "load image" being displayed that would need to be cleared when the results came back for display.
So, again, what is being displayed on the screen that is desired to be modified and what change is to be made or how is it to look different than the way it is provided?
Since I had to activate the currency symbol to have the comma in place of the decimal point, I realized that you could modify a little bit of php code to show the decimal places with the comma by removing the currency symbol.
Another thing, how do I remove UPDATER_PREFIX_TEXT (Your price:) without deleting it on the language file
/*
* Prepares the shoppingCart contents for transmission
*
* @return void
*/
protected function prepareOutput() {
global $currencies, $db;
$prefix = '';
switch (true) {
case (!isset($_POST['pspClass'])):
$prefix = UPDATER_PREFIX_TEXT;
break;
case ($_POST['pspClass'] == "productSpecialPrice"):
$prefix = UPDATER_PREFIX_TEXT;
break;
case ($_POST['pspClass'] == "productSalePrice"):
$prefix = PRODUCT_PRICE_SALE;
break;
case ($_POST['pspClass'] == "productSpecialPriceSale"):
$prefix = UPDATER_PREFIX_TEXT;
break;
case ($_POST['pspClass'] == "productPriceDiscount"):
$prefix = PRODUCT_PRICE_DISCOUNT_PREFIX;
break;
case ($_POST['pspClass'] == "normalprice"):
$prefix = UPDATER_PREFIX_TEXT;
break;
case ($_POST['pspClass'] == "productFreePrice"):
$prefix = UPDATER_PREFIX_TEXT;
break;
case ($_POST['pspClass'] == "productBasePrice"):
$prefix = UPDATER_PREFIX_TEXT;
break;
default:
$prefix = UPDATER_PREFIX_TEXT;
// Add a notifier to allow updating this prefix if the ones above do not exist.
$this->notify('NOTIFY_DYNAMIC_PRICE_UPDATER_PREPARE_OUTPUT_PSP_CLASS');
break;
}
So, the process incorporated into DPU for currencies is if it is desired to show values fully in the selected currency they will be displayed as defined by/within ZenCart with regards to all of the factors defined. If it is desired to not display the prices using the ZC currency format, then the values will be displayed as controlled by php for using the function number_format with only two parameters. (if more are desired, then they can be added into the class file for dpu to support whatever result is desired. Ideally, one would consider the possibility of showing the information to those both in and out of the primary "currency" or current language.Quote:
Originally Posted by diamond1
See for those that use the comma (,) for thousands and decimal (.) for parts of a whole, turning off currency appears to only remove the currency symbol(s).
Basically, there are some things that have been written into the code that offer places to modify to suit as well as to use the ZC default code.
I'm not exactly sure what you mean by "without deleting it on the language file". The proper way to control the content that is to replace UPDATER_PREFIX_TEXT and to minimize the differences between the distributed software and what is on your system is to define that text as nothing (blank) which is an empty string.Quote:
Originally Posted by diamond1
So the define would go from:
To:Code:define('UPDATER_PRICE_PREFIX', 'Your price: ');
And then anywhere for the language displayed that UPDATER_PRICE_PREFIX is presented it would be nothing.Code:define('UPDATER_PRICE_PREFIX', '');
Alternatively and currently left for those that wish to personalize the data, a new define could added for the individual class type(s) depending on the particular setup. These may get updated/modified as new ones are identified to apply, but at initial insertion, I didn't want to unnecessarily add x defines all having the same text and instead inserted one define used in x locations.
In review of the above code I did also realize that the notifier won't serve the function intended and have added a branch in github to address it for the next release as well as some additional code to address "personalization" of the various parts recently discussed of not using the currency symbol feature.
I noticed that if the product does not have attributes the price shown is zero as ever?
What version is installed and is the product setup to default to a zero quantity when the customer is first presented the product? There was a discovered issue with 3.0.6 that was corrected in 3.0.7 similar to what you describe.Quote:
Originally Posted by diamond1
Basically, a javascript error had been previously occurring that would prevent updating the price of a product without attributes, once the javascript error was properly addressed, then the price update review would occur with all product, well. The code was only trying to handle product with attributes and therefore calculated a 0 price for product without attributes. Once that was identified as occurring the "solution" was to go ahead and use DPU in all places when looking at the product info page, this way the display of information would/could be consistent and reduce the "flash" of changing from say starting at to minimum price or something like that. And prices for quantities (with or without attributes) could be displayed.
So... recommend updating to the latest version of at least 3.0.7.
I have version 3.07, maybe it was badly agued which would be the java file to be corrected
Thank you MC
Hello,
I upgraded a client's website to the latest version 1.5.5e
I installed Dynamic Price Updater module but it keeps sending the following warning in the logs
@Dr Byte kindly help
[14-Jul-2017 12:37:22 UTC] Request URI: /ajax.php?act=DPU_Ajax&method=dpu_update, IP address: 192.168.200.28
#1 header() called at [/home/yabba1/public_html/includes/classes/dynamic_price_updater.php:463]
#2 DPU->dumpOutput() called at [/home/yabba1/public_html/includes/classes/dynamic_price_updater.php:68]
#3 DPU->getDetails() called at [/home/yabba1/public_html/includes/classes/ajax/zcDPU_Ajax.php:16]
#4 zcDPU_Ajax->dpu_update()
#5 call_user_func() called at [/home/yabba1/public_html/ajax.php:72]
[14-Jul-2017 12:37:22 UTC] PHP Warning: Cannot modify header information - headers already sent by (output started at /home/yabba1/public_html/includes/classes/ajax/zcDPU_Ajax.php:1) in /home/yabba1/public_html/includes/classes/dynamic_price_updater.php on line 463
I'm not the good DrByte, but it appears that somehow there is a character before the opening <?php in the file: includes/classes/ajax/zcDPU_Ajax.php that is on your server. I have just downloaded the plugin and at least in the file viewer I am looking at such a character does not exist. How was the file uploaded/installed?Quote:
Originally Posted by mani
Further assistance regarding the warning message of Headers already sent can be found at this FAQ: https://www.zen-cart.com/content.php...s-already-sentQuote:
Originally Posted by mc12345678
Please report back what you find as it would be nice to know if the original fileset was found to cause this issue so that it could be prevented for others. I don't have those error messages in the installation that I have so would have to figure out what caused the introduction of an additional character (visible or non-printed) at least to ensure it wouldn't be present for others.
I just checked and there is no character at the opening
<?php
class zcDPU_Ajax extends base
{
function dpu_update()
What else could be the reason for this?
here is a complete log file
[17-Jul-2017 09:57:47 UTC] Request URI: /ajax.php?act=DPU_Ajax&method=dpu_update, IP address: 192.168.200.28
#1 header() called at [/home/*****/public_html/includes/classes/dynamic_price_updater.php:463]
#2 DPU->dumpOutput() called at [/home/yabba1/public_html/includes/classes/dynamic_price_updater.php:68]
#3 DPU->getDetails() called at [/home/yabba1/public_html/includes/classes/ajax/zcDPU_Ajax.php:15]
#4 zcDPU_Ajax->dpu_update()
#5 call_user_func() called at [/home/yabba1/public_html/ajax.php:72]
[17-Jul-2017 09:57:47 UTC] PHP Warning: Cannot modify header information - headers already sent by (output started at /home/******/public_html/includes/classes/ajax/zcDPU_Ajax.php:1) in /home/yabba1/public_html/includes/classes/dynamic_price_updater.php on line 463
Any help will be appreciated
The file was somehow uploaded with the incorrect file encoding (UTF-8/BOM) so there is an "invisible" character at the beginning of that file. I have uploaded to github just the change to the encoding (ANSI) to: https://github.com/mc12345678/Dynami...79eea406dd84cf.Quote:
Originally Posted by mani
It appears using your file has fixed the problem!
Thanks a lot :)
Much appreciated!
Now got one more warning
[18-Jul-2017 06:57:14 UTC] Request URI: /ajax.php?act=DPU_Ajax&method=dpu_update, IP address: 192.168.200.28
#1 DPU->removeExtraSelections() called at [/home/yabba1/public_html/includes/classes/dynamic_price_updater.php:62]
#2 DPU->getDetails() called at [/home/yabba1/public_html/includes/classes/ajax/zcDPU_Ajax.php:14]
#3 zcDPU_Ajax->dpu_update()
#4 call_user_func() called at [/home/yabba1/public_html/ajax.php:72]
[18-Jul-2017 06:57:14 UTC] PHP Warning: Invalid argument supplied for foreach() in /home/yabba1/public_html/includes/classes/dynamic_price_updater.php on line 150
How do I get this fixed?
Is this version of this module GitHub
https://github.com/Zen4All-nl/Zen-Ca...eases/tag/v3.1
Same as this one
https://www.zen-cart.com/downloads.php?do=file&id=1301 ?
In Github version there is no ajax folder in includes/classes
If I install GitHub version will it work with 1.5.5e?
I copied the contents of the file from classes/dynamic_price_updater.php from
https://github.com/mc12345678/Dynami...ce_updater.php
and now it doesnt create a log file
Is it the right approach?
Module version installed is downloaded from
https://www.zen-cart.com/downloads.php?do=file&id=1301
and only
classes/dynamic_price_updater.php has been updated from github!
No those two versions are no longer the same. While Design75 and I have been talking about moving forward with DPU, we haven't synced (yet) the two distributions. They remain linked however to be able to see the branch history and to locate an updated version.Quote:
Originally Posted by mani
After issue of 3.0.7, the bug described above was located and corrected on github in the master branch (similar location as identified above, but more "flexible" to reference because it would be up-to-date with the remainder of the software). Considering that for operations sake the only file really changed since 3.0.7 was the includes/classes/dynamic_price_updater.php file, updating the current install with that file is the way to go.Quote:
Originally Posted by mani
I am working on some additional functionality for the next ZC update such that the starting at: related text would/should be updated from say 'starting at:' (basically for the default values and/or no selections made) to 'at least:' (some selections have been made, but not all that are effectively required and based on attributes being included in the base price through the attributes controller) and then 'Your Price:' once all options have been selected, again somewhat based on the attribute(s) being identified as included in the base price. Still working through some of the "complexities" of options like check boxes (no requirement for one to be selected), text boxes that have pricing applied to the content, radio buttons that don't have a default value (potentially allowing submission of the product without having selected a radio button option which is a flexibility offered by the ZC software).
So yes, the action taken was a good approach to the issue identified in particular that the change(s) made to that file specifically were intended to address the issue observed here in post #1319. :) Had the solution not been there, then posting here about the issue or initiating an issue log on github should support getting the problem corrected once confirmed as an issue.
After i am back frommy summer holiday, I will update my repos to match the MC versoin
Quote:
Originally Posted by mc12345678
Firstly, many thanks for this mod, installed and worked straight away, can't believe its taken me so long to get around to using it!
A quick ask, incase i'm missing it, but when products are on discount (and priced by attributes) the discounted prices updates and displays all fine without error, but the "original" price (the one crossed out - reference span normalPrice) doesn't change to reflect the difference of original prices.
Glad that you found this then. :)Quote:
Originally Posted by Calljj
That is correct for the current operation, basically it updates the "bottom line" for the customer as determined by the shopping_cart class. At this time, it does not update each of the other associated price displays.
Edits can be made to modify what is displayed/replaced to support other presentations, but that is currently outside of the base coding of this module.
That's a shame as it confuses the customers on sale items especially if there is a big price difference between the cheapest and the most expensive attribute- when for example the normal price of £5 is struck through, it says save 25% and then the 'sale' price says £100!
Right, but the struck through price should say starting at. Now, you could also do other things with the code to have it simply replace the whole value once selections have begun to be made or not display the crossed through price, etc... right now though that's an extra feature that is not (yet) in my own priority list, unfortunately. It does strengthen my thought (if not already captured in say ZC 1.6.0) of a "price" function that returns all of the values associated with price display. Right now the vprice value returned is just the bottom line. Other prices could be determined, fed and then displayed. At the moment with this plugin id like the display to change as each priced by attribute attribute is selected or at least in the three conditions that the text is modified (starting at, at least, and your price).Quote:
Originally Posted by Calljj
@Calijj,
I created an issue on github: https://github.com/mc12345678/Dynami...ater/issues/10 to address/track this.
Thanks you for adding, i do feel like this would be a valid part of the module.Quote:
Originally Posted by mc12345678
on a tangent.. i have a finance calculator that uses the "base price" of a product when the products_page is loaded and gives payment information to the customer. lets call this finance_calc.php. Could you point me in the direction that i could tap into getting the current price of the option that is displayed to then pass across and reload the finance_calc.php.
This would enable the ultimate for me, which is the all the deposit ammounts, terms etc would all change to reflect the different attributes as they are selected. happy to fund this if that's what is required.
Just also noticed that if i do a salemaker for a category discount, and one of those products in the sale is Zero stock.
The discounted price says "0.00"
So, until now hadn't seen the previous message/request about "throwing" the current price of the selected options to or back to another piece of software. Also, regarding the above, there isn't anything in the price determination code to pick up on being "out-of-stock" in some sub-variant. There can be, it's just not there at the moment. Code would likely go into the class file for dpu in includes/classes. Though I am also trying to figure out the configuration that causes this. Is the problem being seen on the product's listing page (multiple product being displayed) or on the product info page (which at the moment doesn't make sense per se, or may need to be "worked around")?Quote:
Originally Posted by Calljj
Issue occurs on the product_info page. I'm not using any stock by attributes mods. just simply if the main product stock level is zero, the discounted price goes to zero (the original rrp remains the same).Quote:
Originally Posted by mc12345678
That final operation is a bit outside this plugin, but... there are a number of tools within it that would aid/support getting the desired result and/or that could be combined into the associated functionality (that way system doesn't have to double dip for data/info, just needs to be handled/processed either on the php side or the javascript side or both.)Quote:
Originally Posted by Calljj
What are the settings for stock related to product availability when "sold out", is it possible to purchase items that have a quantity of 0 or less, or are items just on display that are at 0 or less, what conditions are necessary to reproduce the issue so that can incorporate a fix as necessary?Quote:
Originally Posted by Calljj
The price that is displayed for the product and attribute selection is based off of attempting to add the product to the cart and figuring out from there what the price became. If something say prevented adding to the cart or gives such a 0 price, then that's the end result as far as this plugin is concerned.
Products are set to display only when stock is 0.Quote:
Originally Posted by mc12345678
to replicate, just set a standard product to zero stock quantity, no priced by attributes, then discount it.
the original price shows, the discount price = 0.00
Thank you for that information. Will look into one or more ways to address it. It sounds like based on the discussion of the product being out-of-stock that it the store is setup to not allow purchase of product if the quantity is 0 or less. Therefore that will be/become a factor moving forwards.Quote:
Originally Posted by Calljj
It does make me wonder how much if any of the shopping_cart related operation can be hooked into to allow the "addition" of a product in this condition so that the price updating can be visualized, but not to allow the addition of the product through another process. Otherwise (without editing the shopping_cart class), price updating may not be permitted for product that are out-of-stock when store is set to require a positive quantity of stock to add product to the cart.
Of course an alternative would be to include a separate version of a shopping_cart type class that does allow such a condition, but then it would need to either be maintained in parallel with the version of ZC or any other changes uniquely made to it, which just makes things more difficult to maintain consistent operation and the software.
A potential middle ground to that could be to evaluate the in-stock quantity and then manage the price determination based on that knowledge. :/
Some things to review and determine.
If you believe you need a temporary fix to the issue in the interim I can advise how to disable the price update feature for this condition.
In: includes/modules/pages/YOUR_PRODUCT_TYPE/jscript_dynamic_price_updater.php
Before the last line of this code (code section starts about line 23):
Make it look like:Code:if (empty($pidp)) {
$load = false;
}
if ($load)
This is based on the report that there is an issue when a special/sale exists for a product that has a stock quantity of zero and the store does not permit "over-purchase" of the quantity. It does not address the possibility of quantity discounts having the same "result" of displaying the discounted price as 0.Code:if (empty($pidp)) {
$load = false;
}
if ($load && STOCK_ALLOW_CHECKOUT === 'false') {
$pid_quant = $db->Execute("SELECT products_quantity FROM " . TABLE_PRODUCTS . " WHERE products_id = ". (int)$pid, false, false, 0, true);
if ($pid_quant->EOF || $pid_quant->fields['products_quantity'] <= 0) {
if (zen_get_products_special_price((int)$pid, false) !== false) {
$load = false;
}
}
}
if ($load)
HI, thanks for reply, just tried the code change but didnt make any difference.
Just noticed same issue applies to any product (discounted or not) if quantity set to 0, and setting for checkout not allowed when quantity is 0.
just noticed that if the setting "Show Sold Out Image in place of Add to Cart" is set to 1, then i just get 0.00 displayed for the price.
if the setting is set to 0, then the price displays fine.
one presumes that DPU is linked to this setting somehow?
So ,based on digging, found the only way i can get the price to still display correctly when product is sold out is to change the template file
tpl_product_info_display.php
find
and after it addCode:$display_button = zen_get_buy_now_button($_GET['products_id'], $the_button);
Code://jf added for dynamic price updater DPU----------------
if (strpos($display_button, 'button_sold_out.gif') !== false) {
$display_button = '<input type="hidden" name="cart_quantity" value="1" />' . zen_draw_hidden_field('products_id', (int)$_GET['products_id']) . $display_button ;
}
//eof jf add-------------------------------
this passes the hidden quantity and value fields which it appears DPU requires to calculate its values
Based on the additional information afforded by the above. There is a code modification that I am staging to github to address this issue such that DPU will still update prices of product with attributes even for product that are out-of-stock.
This change does not require modification of the template files. Further, it will identify the price associated based on the quantity identified by the ZC function zen_get_buy_now_qty for product that are out-of-stock and for quantity entered as zero or negative.
Pushed the update to github finally. To obtain the specific modification see: https://github.com/mc12345678/Dynami...d7002a43116075
It as well as a few minor updates/fixes for the ZC released version are now in the master branch of the github repo at: https://github.com/mc12345678/Dynamic_Price_Updater
I installed dpu, but I have a problem and I had to disable it.
The problem is that in admin I see who's online no longer has the normal link but this:
## /ajax.php?act=DPU_Ajax&method=dpu_update
Also if you look at generate generate source i get this one:
</ Head>
<Body id = "productinfoBody" onload = "try {
#### init ();
} Catch (dpu_err) {
#### console.log (dpu_err.stack);
}; ">
I think something in my installation does not go you even see who is online /ajax.php?act=DPU_Ajax&method=dpu_update
If you rely on the who's online information to conduct business I will look into the proper formatting of appending the results of zen_get_all_get_params so that the applicable ajax call will include the parameters on the uri even though they are not directly used by DPU. As to the source code presentation, yes that try/catch takes multiple lines. This helps with debugging by allowing each line to be executed individually and there fore can be tracked in the browser. The page passes html validation, what "issue" was it causing for you?Quote:
Originally Posted by diamond1
Also, while the same result in who's online was seen, the plugin User Tracking did not show the issue of the user executing an ajax method and shows more of a history than what the very last "click" was.
Waiting for a solution I disable the plugins,
Attachment 17261
Untested but should carry the information that would normally be seen in Who's online:
Two places each in two provided files to change to support both "methods" of operation:
includes/modules/pages/product_info/jscript_dynamic_price_updater.php
and
includes/modules/pages/product_music_info/jscript_dynamic_price_updater.php
Line 125 change from:
to:Code:this.XHR.open(strMode.toLowerCase(), this.url+"?act=DPU_Ajax&method=dpu_update"+(strMode.toLowerCase() == "get" ? "&" + this.compileRequest() : ""), true);
Line 132 change from:Code:this.XHR.open(strMode.toLowerCase(), this.url+"?act=DPU_Ajax&method=dpu_update"+(strMode.toLowerCase() == "get" ? "&" + this.compileRequest() : "")+<?php echo (!empty(zen_get_all_get_params())) ? '"&' . zen_get_all_get_params() . '"' : '""'; ?>, true);
To:Code:var option = { url : theURL+"?act=DPU_Ajax&method=dpu_update",
Code:var option = { url : theURL+"?act=DPU_Ajax&method=dpu_update<?php echo (!empty(zen_get_all_get_params())) ? '&' . zen_get_all_get_params() : ''; ?>",
Actually, tested now. Result is/was that provided all of the parameters in the uri except those excluded by the function (ie. don't get the main_page for example) which included the products_id and if present the cPath, etc... it also included an additional & at the end of the result which will be addressed separately to provide a cleaner result. So at least can identify at which product one is looking.Quote:
Originally Posted by mc12345678
it's not still good, my fear is for spider search engines what do they see exactly even if we have the canonical link?
I can not take risks and leave it still off until there is a right solution.
Attachment 17262
The result that is being logged is execution of ajax (javascript with php). A search engine is looking at the page. The "problem" that you are seeing is that the page is loaded, and then another page is loaded through ZC which when "recording" the current/last page visited appears as if accessed the ajax file. This has nothing to do with the actual loaded page. I don't know what you would rather see in your look at who's online, but as said in monitoring clicks/pages loaded through say User Tracking, the ajax action doesn't get registered and considering the use of that ajax call, there is no reason to show anything different/new.Quote:
Originally Posted by diamond1
How do you think that the information presented in who's online should relate to a search engine's results?
Spiders have to see the exact name of the link as it has always been, I would like an expert SEO opinion as to what impact will this url do not bring anywhere? Also, it is not possible to know where visitors are, what page they are visiting, of course, who is online is just about to know what the visitors are doing.
by doing local tests I noticed that on some products I get this kind of warning
Attachment 17264
another thing I noticed is that the DPU needs this file jscript_jquery.min.php to work, then it is not part of the package.
PHP Code:<script type="text/javascript">
if (typeof jQuery == 'undefined') {
document.write(unescape("%3Cscript src='//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js' type='text/javascript'%3E%3C/script%3E"));
}
</script>
Based on the above, I have to ask why have you either disabled zcJS or modified the DPU code not to use it although it has been recommended by the core developers to use zcJS and at least the associated ajax.php file?Quote:
Originally Posted by diamond1
Quote:
Originally Posted by diamond1
Did you also happen to notice that the reference used there is to load it over the Internet instead of from your local fileset? How would such a set of files be included? Besides that, there has been a statement made by the ZC software moderator that such files should not be included in the package itself as using any recent version of ZC automatically includes such a file. Further the script operates such that it only attempts to load the associated file if one hasn't already been loaded, this way there should not be any conflict by loading this plugin in conjunction with any other that is up-to-date.
If anything, I'd say that what has been pointed out is that likely the reference to the version is a little dated, though I doubt it plays a factor as a result of the above.
If you are looking for a specific answer to a specific question (even though in this case it was brought up as a result of this plugin) I would suggest initiating a new thread about the use of ajax.php and it's relationship to SEO. Then to provide a link here associated to that for interested readers.Quote:
Originally Posted by diamond1
As far as SEO "seeing" the link as it always was: what you see in who's online is data associated to what ZC has collected about the navigation within the software/site. It is not necessarily what a search engine sees. Though a search engine may put together the javascript parts to attempt to replicate performing the same action as a user. For this plugin, the effect is a change to the page/product price not necessarily "new content". There are ways to advise to the likes of google the variations in price unrelated to the operation of this plugin through the use of micro-data which is a discussion for a different thread.
First of all thank you for what you do for our community, I do not understand well I apologize, I have to translate in French with google and that's another thing. I have the original dpu files what do you mean zcJS disabled?HTML Code:Based on the above, I have to ask why have you either disabled zcJS or modified the DPU code not to use it although it has been recommended by the core developers to use zcJS and at least the associated ajax.php file?
the file did not sit in the zencart distribution I added because in test version 1.5.4 was the only file I had in and where dpu worked and if i removed the jscript_jquery.min.php file DPU it does not work.HTML Code:Did you also happen to notice that the reference used there is to load it over the Internet instead of from your local fileset? How would such a set of files be included? Besides that, there has been a statement made by the ZC software moderator that such files should not be included in the package itself as using any recent version of ZC automatically includes such a file. Further the script operates such that it only attempts to load the associated file if one hasn't already been loaded, this way there should not be any conflict by loading this plugin in conjunction with any other that is up-to-date.
If anything, I'd say that what has been pointed out is that likely the reference to the version is a little dated, though I doubt it plays a factor as a result of the above.
Yes for the rest I can ask in the SEO section however you should see in whois online the visitors where they are but you do not have to have the whois online in zencart
So a couple of things. On my side, I apologize to all for assuming that the site in question was a ZC 1.5.5e site based on the current tagline which states so. (future readers, this tag line may be different and therefore any posts by the OP stating to see the tagline should be taken with a grain of salt). Secondly for not asking directly which version was involved.Quote:
Originally Posted by diamond1
That said, ZC 1.5.4 comes with the same or similar jscript_framework.php file as in ZC 1.5.5 in the folder includes/templates/template_default/jscript. That file, when incorporated with the current template will provide zcJS which is preferred over the included/legacy XHR that was kept with this plugin for compatibility and potential of others having built on it.
Also, it was pointed out aboutthe jquery file not being included (whether in whole or by "reference". Looking through the file structure, it is not present as identified, though there was a bit of a language barrier issue/misinterpretation on my part. I thought the concern was not having provided the referenced file. The concern was that there was nothing that ensured that jquery (or rather javascript) was loaded.
So, from that short discussion there are improvements available to be made to the instruction to cover these two topics and possible an "alternate" folder to provide the loading of jquery if something is not there already.
So, on the issue of the pop up message. It occurs when zcJS is not used, the enquiry to the system is complete and the status response is not 200. It could be a response of no change or some other result. To identify, would suggest monitoring the network traffic through the browser and noting the response that occurs when that message is presented. It may be something to "catch".
As to the data in who's online... this plugin with the unique data that is at the beginning of the displayed url identifies that the visitor is looking at a product. Then with the provided modification, the pertinent data such as the products_id (unique identifier) and if present the category is provided. Therefore, one can tell at least when/where such info is made available what is being looked at. Generally speaking, any product type (main_page=PRODUCT_TYPE_info) could be substituted to see the actual product if it was not familiar to the admin.
Hope that helps.
DPU is installed both in zencart 1.5.4 and in zencart 1.5.5 as in the signature, the problems are identical on the two distributions of zencart 1.5.5 and 1.5.4, I also noticed that if there are no attributes the price remains zero . someone can tell me if he has installed DPU and that he has no problems I can give me a link. I also do the prose both locally and online when I can for a few seconds and the errors are both local and online.
for the fact that if there are no attributes the price and zero I already had time to tell it but I did not have an answer
https://www.zen-cart.com/showthread....pdater/page131 post 9
What version are you using because the issue of a "zero" price for product without attributes was corrected some time ago. The referenced post or post area even indicates that the issue has been corrected in more recent copies of the code. If you are still seeing that the price of a product without attributes is displayed as 0 for the given/selected currency, then I would say that the DPU for the store has not been properly upgraded and would suggest verifying that dpu's class file is up-to-date.
I have version 3.7 this https://www.zen-cart.com/downloads.php?do=file&id=1301 and the files are all original. Also I did not understand how to do to remove the pop up Status returned and how do I ever keep the file jscript_jquery.min.php what do I do to see DPU work?
Dynamic Price Updater (Version Installed) 3.0.7
Quote:
Originally Posted by diamond1
Copy from includes/templates/template_default/jscriptQuote:
Originally Posted by diamond1
The files jscript_jquery.min.php and jscript_framework.php to:
includes/templates/YOUR_TEMPLATE/jscript
Where YOUR_TEMPLATE is the name of the template used on your site.
That will address having jquery/javascript loaded for your template AND make zcJS available for use and the popup will not occur. With those two files in place dpu will work.
A form of javascript or jquery must be present, and it is expected that with a current version of ZC that at least a javascript or jquery file would have been included in the template.
As to a zero price showing for a product that doesn't have attributes, I can no longer reproduce that issue because of the changes that have been made and incorporated into DPU version 3.0.7 and the minor change made as shown in this commit: https://github.com/mc12345678/Dynami...d7002a43116075
From zero price that shows a product that does not have attributes worked the change you suggested, instead copying the two files in the jscript folder did not work to run dpu i always leave jscript_jquery.min.php if i put the two files you have suggested dpu is blocking Do you have another suggestion?
[02-Sep-2017 18:38:04 Europe/Rome] PHP Warning: Invalid argument supplied for foreach() in /home/blablabla/public_html/includes/classes/dynamic_price_updater.php on line 150
But I have this as a mistake now with the edit
To summarize the current situation of DPU, the posted/identified issues and the solutions or the proposed solution, the following posts have been made since issue of 3.0.7 with either a link or some form of direction on how to correct. The most latest forum posted code has not been massaged to remove an extra & from the end, but it allows identifying the product information when viewing the ZC default who's online. It seems like it may be beneficial to have some internal "switch" to allow not capturing the ajax call as a "who's online" condition such as perhaps a session variable when set to bypass the who's online "logging", clear the session variable and continue on. Seeing as the who's online table really only keeps the last unique record (i.e. the last "click"), filtering has to occur up front when the "action" is being taken rather than at some point later as in at the point of viewing the list/record. Obviously would be concerned about some sort of security "black out". I guess another solution is to incorporate a who's online update within the code so that the "position" of the current user does not appear as if in the ajax code... Brings about something of a *sigh*.
Also, one can see the changes that have been made and stored to keep a functional version of the plugin (changes to be incorporated into the next version plus any new features) by using the following link which compares the current code to the associated issued version (in this case 3.0.7): https://github.com/mc12345678/Dynami...3.0.7...master
Quote:
Originally Posted by mani
Quote:
Originally Posted by mani
Quote:
Originally Posted by mc12345678
Quote:
Originally Posted by mc12345678
Quote:
Originally Posted by diamond1
I can not follow you, but a version that works as it should not be there? with the editors who are online you see this now /ajax.php?act=DPU_Ajax&method=dpu_update&products_id=154&cPath=3&number_of_upload s=0& a little better than before but not enough for those who have installed the url rewrite, regarding the php error public_html / includes / classes / dynamic_price_updater.php on line 150 I always did not understand how to fix the error despite updated files that would be easier for everyone to upload the correct version of the forum
Although English is a second language (or maybe third, fourth or fifth), no one is a mind-reader or at least I am not one. Please explain what can not be followed, what is not understood, etc...Quote:
Originally Posted by diamond1
As to the line 150 issue. If you follow any of the links that go to github, you should see code that has been modified. Red, means that something about that line has been "deleted" or is the "old" line, green means something in that line has been "added" or represents how the new line should look.
If you need to specifically know what line 150 should now look like, then please ask.
As to the software as available from the downloads section of this site. Well, please also understand the nature of this public forum. Volunteers have offered code. That code is offered to the forum for yet other volunteers to review the code by a process and make it available to others at no cost. Sometimes in the overall process an error is found and a correction is made. In this case the correction was posted to the forum and to a live location that is not controlled or maintained by core ZC volunteers. That modified version is available for download which would provide a package very much like what is provided through the ZC forum.
As a user of the software, it is equally important to review the forum for similar issues and to either ask how to apply the fix or find someone to do so as it is for someone to post a central fix to an issue. Right now I have at least three major changes to this software to implement which will improve the overall operation and flexibility of the software and when issuing those changes the minor patches identified to date will be incorporated.
Again, let me just say that the github location: https://github.com/mc12345678/Dynamic_Price_Updater allows download of the code as a zip file. This would allow applying the patch for linme 150 of the class file.
Not sure about which URL rewriter you are speaking of or what is specifically desired to be seen. If they wish to see more information or specifically wish to see the full url, then it could be possible to incorporate a result from zen_href_link (properly sanitized) into the parameters to be displayed. I found that with CEON Uris installed that the result was similar to above. That result is or should be enough to determine the product being viewed.Quote:
Originally Posted by diamond1
Locally I have incorporated a jscript_jquery.min.dpu.php template file that will load jquery (currently set to load 1.12.4) if jquery is not yet already loaded. Github will be updated to reflect that additional file plus in time the modifications to the instructions that are needed to cover the things recently identified.
Submitted v3.0.8 to the ZC Forum to correct a number of issues discussed above and listed below:
Once reviewed and accepted it should be available for download from ZC here. Otherwise this version can be viewed on Github here. With the changes between the ZC 3.0.7 and ZC 3.0.8 release identified here.Quote:
3.0.8, What changed:
- Added a switch and code to support deactivating the use of currency symbols
in the sidebox, similar to the display of the base product price.
- Corrected the use of the notifier to support using an observer to provide
a prefix for displayed prices.
- Removed the specific comparison of an attribute being a checkbox for when
processing attributes to identify the lowest price of the product. Inclusion
of the attribute into the base price is controlled through the attributes
controller and should not be just blindly omitted within this code.
- Updated the installer including to incorporate the version checker provided
in the current alpha release of ZC 1.5.6 and to use that code instead of the built in code and
instead of pulling the recent file into the distribution of the
plugin (and then have multiple such versions out and about.)
- Updated the installer to write a debug log if the installer files have been
incorrectly placed in the catalog side of the installer.
- Updated the installer to expect an admin to be logged in, and the page not currently being
the login page or as a result of selecting the logoff option.
- Updated code for initial expected changes for PHP 7.2.
- Corrected the encoding (BOM) of the file that provides the ajax processing.
- Corrected issue with price being displayed as zero when it should be otherwise displayed.
- Added the general page information (though not with zen_href_link) and support understanding what
the customer is looking at at the point of the call.
- Updated the jscript code for the product_music to match the product_info code.
- Added template jscript code to attempt to load jquery if it has not previously included or
loaded to load jquery 1.12.4
Version 3.0.8 has been posted to the ZC website here.Quote:
Originally Posted by mc12345678
Hi there.
Just installed the latest version on a test site and got an error
[10-Oct-2017 10:21:00 America/Denver] PHP Parse error: syntax error, unexpected '(float)' (double) (T_DOUBLE_CAST) in /home/koolwedd/public_html/bvostoretemp/includes/classes/dynamic_price_updater.php on line 200
Thanks for the report. Could you please try applying the change to that file as indicated in the following commit difference: https://github.com/mc12345678/Dynami...e36f1c1e18928?Quote:
Originally Posted by mvstudio
I'd like to package that better, but best I could do from my phone when I saw your message.
Thank you for that.
I made the changes and now I get this error
[10-Oct-2017 16:07:36 America/Denver] PHP Fatal error: Can't use function return value in write context in /home/koolwedd/public_html/bvostoretemp/includes/modules/pages/product_info/jscript_dynamic_price_updater.php on line 125
Still trying to figure out which part of the line is causing this issue, it is expected to be repeated in later lines and want to fix all at once not one at a time. Side question is, when viewing your page source do you have the javascript/jquery variable: zcJS?Quote:
Originally Posted by mvstudio
Thank you for looking into it.
I believe so. It appears on 2 places in the header
PHP Code:<script type="text/javascript"><!--//<![CDATA[
if (typeof zcJS == "undefined" || !zcJS) {
window.zcJS = { name: 'zcJS', version: '0.1.0.0' };
};
zcJS.ajax = function (options) {
PHP Code:zcJS.timer = function (options) {
var defaults = {
interval: 10000,
startEvent: null,
intervalEvent: null,
stopEvent: null
I was grabbing at some straws with the question but wanted to be sure that the correct portion of the code would be expected to be processed.Quote:
Originally Posted by mvstudio
I think I have identified the cause (okay besides the programming that I added in), which was an attempt to evaluate the result of a function to see if it was empty or not. I have made a change in the master branch to account for a better arrangement, though that entire portion is still under review. I was going to try to use zen_href_link to build the link so that it would be more informative when using a URI rewriter, but because ajax.php itself must be called statically, it doesn't specifically resolve the issue previously described so I incorporated what I did to move things along and perhaps identify other strict processing issues that haven't yet been identified. :)
Again thank you for the notification and patience.
See this commit for proposed resolution of the above: https://github.com/mc12345678/Dynami...0748a66b3e7758
I have good news, and bad news.
The good news, the changes didn't make the site crash completely like before. Bad news, product info pages are blank =(
I keep on getting the error on line 126, after the changes, which would be the beginning of the changes you referenced.
Sorry for reporting such bad news =(
I was checking the file last night and was able to make some progress, I think.
In comparing the file in the plugin with the modifications you suggested, and this file https://github.com/mc12345678/Dynami...ce_updater.php which already contains the modifications, I found an extra line at the bottom of the code on the one on the plugin. In removing that extra line the product info page now downloads. However the ajax loader image stays on a loop. You can see the behavior on the test page here http://www.byvalenti.com/bvostoretem...&products_id=4
No error log files are generated with this behavior.
I hope this info helps you a bit =)
Thank you for looking into it.
Now that have a link to a "problem" page, for one thing there are some significant html validation issues, one of which is considered a fatal error as seen here: https://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.byvalenti.com%2Fbvostoretemp%2Findex.php%3Fmain_page%3Dpro duct_info%26cPath%3D8_9%26products_id%3D4.Quote:
Originally Posted by mvstudio
Another issue may be related to the loading of jquery 1.7.1 as what looks like the main jquery to be loaded.
From my device, I couldn't see the entire page and the css essentialy wasn't loaded.
Recommend addressing the validation issues before attempting to further work with javascript/jquery related code.
The validation issues was on my to-do list, after installing all the plugins the site needed.
Anyways all the validation issues have been resolved. The jquery 1.7.1 is part of the zx Slideshow plugin.
Thank you!
I didn't see a css file for the plugin. The templates folder only contains a jscript and sideboxes folders.Quote:
From my device, I couldn't see the entire page and the css essentialy wasn't loaded.
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.Quote:
Originally Posted by mvstudio
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:
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.Quote:
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 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.
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. :)Quote:
Originally Posted by mvstudio
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. =)
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).Quote:
Originally Posted by mvstudio
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/bvostoretem...&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.Quote:
Originally Posted by mvstudio
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:
to:Code:var imgLoc = "replace"; // 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. :)Code:var imgLoc = ""; // Options are "replace" or , "" (empty)
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:
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...PHP Code://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
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).Quote:
Originally Posted by izar74
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
I also added a class #productOFS in stylesheet.css so to have more control over the display of the image.PHP Code:<!--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">
Sounds like a plan. :)Quote:
Originally Posted by izar74
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...
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-pageQuote:
Originally Posted by Lordzoabar
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.