I still have not been able to reproduce this issue in a default store that has just DPU installed, regardless of tax included or not, without a change in base price nor with a special, a sale, or both.Quote:
Originally Posted by Calljj
Printable View
I still have not been able to reproduce this issue in a default store that has just DPU installed, regardless of tax included or not, without a change in base price nor with a special, a sale, or both.Quote:
Originally Posted by Calljj
Well, so I can not use DPU anymore, or will it penalize me?
a 400 error as identified in RFC 2616 is identified as:Quote:
Originally Posted by diamond1
I would say that response is appropriate for the information needed in order to provide an appropriate response. The Official Google Webmaster Blog discusses 404 errors, which this condition is not really the issue as the "page" exists, but nothing can be done by going to just that page, being authorized does not help. And from the other side, the server isn't exactly having a problem, but it doesn't know or can't process what was provided. On a "day-to-day" operation, this has no effect, but on someone trying to develop something, it can be discouraging if 400 is the response. :)Quote:
10.4.1 400 Bad Request
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
Basically, there should be no reason to stop using software that uses ajax style calls and identifies that crawlers shouldn't be concerned with the returned content. That is unless there is something specific being returned that is intended to be the content indexed... That is a different story and would have to be handled differently.
There's also this article (https://support.google.com/webmaster.../6062602?hl=en) that discusses how to block (i.e. exclude) URLs from being indexed by Google.
Hello, the problem is not how to block the problem are all errors reported on google webmaster, I can not tell the bot google not follow the link and returning a 400 error damaging all the SEO. the ideal would have been a nofollow. Why did you do this? if the crawlers should not be interspersed with this you have to find another way that I think will damage the sites that are using DUP. Please find a solution to avoid making google angry.
Er, actually that's what that blog posting was saying. You can guide the Google spider to bypass the ajax.php accesses so that they won't be included in your report by updating your site's robots.txt file.
Disallow: *.php$
Hello, how to write the rule for all the php files Disallow: *.php$ you tell me what would be the right rule for the robots.txt file? how can I get rid of errors on google webmaster? would not it also be right to write on the DPU readme to put in the robots.txtx the dissallow?
So can you just confirm for me.Quote:
Originally Posted by mc12345678
1) you set up a product with zero value priced only by attributes.
2) you set up 3 attributes, priced at 10, 20, 30 (without the 'plus' sign infront in attribute manager).
3) you go to products price manager, and add a special price of "10%".
then on the website the original price (and of course sale price) changes when you select different atrributes?
I pretty confident it wont. I don;t think becuase of dpu, i think becuase of the way zen handles special prices, with products of zero value and priced by attributes.
for example, if you had everything setup as above, if you deleted the top attribute priced at 10, then the new attribute is assigned the sale price of the one deleted! This obviously then changes the overall disocunt on the new lowest attribute to be much more than intended!
original:
Attachment 18030
10% discount:
Attachment 18031
Because zen converts the "special price" discount to an actual numerical value. Then that value then becomes the minimum used for that product, no matter the attributes.
After deleting top attribute, price of second attribute gets changed to the value of the deleted one.
Attachment 18032
You can see this, buy then adding the attributes back in again, using same values as deleted, and everything returns to normal once more.
Been using DPU for years and really like it for my store which uses attributes to price printing. The only thing I would like to see change is for the price that is displayed on the product page to display the same way in the shopping cart instead of as a price break down in the cart. This seems to confuse many of my customers when they see the price differently in the cart and I personally believe many abandon the cart as a result. Is this feature doable?
Price display on the product page:
Attachment 18109
And here it is in the cart as a price break down rather than one price like on the product page:
Attachment 18110
Anyone got a solution for this? An option in the Dynamic Price Updater box in the admin to toggle this feature on/off would be a great asset. I think writing the code is above my pay grade though.
Thanks,
John
Surely doable, but confused about how the two difference in charges are generated. It looks like some sort of combination of product on the product page that then get added individually to the cart instead of each of the attributes being a sub-feature of the product with the total price displayed.Quote:
Originally Posted by GoldBuckle
Otherwise it seems to be a feature of the shopping cart template that is being used.
I say this as for example in a demo cart, products_id of 1 and 2 each have attributes that affect the price of the final purchase; however, when the product is added to the cart, then the total price is shown and not the individual price of each of the attributes.
While from that the display of prices can be modified, there doesn't seem to be as much of a need by using javascript on the shopping cart unless you are looking for the prices to change based on entering/modifying the quantity of the items when looking at the shopping cart.