UPDATE: This issue is now fixed in the Commerce Extended Quantity module:
https://www.drupal.org/project/commerce_xquantity
This patch is dimmed as outdated and not recommended for using:
https://github.com/drupalcommerce/commerce/compare/8.x-2.x...drugan:quan...
After applying the patch run updates then go to admin/commerce/config/order-item-typesYOUR-TYPE/edit/form-display and change the widget to Commerce number field. Do it for both default and Add to cart display modes. See more on the #6.
Problem/Motivation
The quantity on the Add to cart form is an HTML input field of type 'number' and has the widget at the right side to click on it and increase or decrease the value without need to type it in.
The problem is that the quantity field has default '#step' property set to 0.01, which gives 1.01, 1.02, ..., when you try to use the widget. Well, I can imagine an online store offering goods measured in float quantities but it is a bit weird behavior for a regular commerce site that just wants the quantity to increment in whole numbers.
Proposed resolution
Ideally, the change should be applied to core but as the issue is still being considered as a feature request (See issue: https://www.drupal.org/node/2816859), an ideal resolution would be to add a new 'Commerce number field' that will be configurable so that user can set HTML properties. The available settings on the field widget settings form will be as follows:
- Minimum/maximum allowed for the field
- Default value for the field
- Step value for the field
- Prefix/Suffix value for the field
Skip to this comment with solution suggested.
Remaining tasks
User interface changes
A new 'Commerce number field' that will be configurable so that the user can set the HTML properties mentioned above when they click on the gear icon. User can set all number field settings for each of the form display modes individually.
API changes
Data model changes
Code History
The latest version of the code and further history and discussion on the issue is currently found here: https://github.com/drupalcommerce/commerce/pull/525
Comment | File | Size | Author |
---|---|---|---|
#79 | add-to-cart.jpg | 26.68 KB | trigdog |
#78 | 1q1.png | 13.13 KB | freelylw |
#58 | Capture du 2017-07-10 19-13-48.png | 136.94 KB | zenimagine |
#56 | quantity1.png | 22.55 KB | bojanz |
#46 | make_the_quantity_field-2794909-46.patch | 6.89 KB | mglaman |
Comments
Comment #2
drugan CreditAttribution: drugan commentedComment #3
drugan CreditAttribution: drugan commentedComment #4
mglamanLinking to PR: https://github.com/drupalcommerce/commerce/pull/481
Failures look odd given the change. Also, isn't this configurable on the line item's add to cart form display, the step count?
Comment #5
drugan CreditAttribution: drugan commentedNo, you can only configure a placeholder for the quantity field on the line item's add to cart form display.
The '/cart' view actually resolve this issue on the line #102 here:
modules/cart/src/Plugin/views/field/EditQuantity.php
And it works there.
By the way, the #3 patch only resolves the 'step' issue, still leaving the possibility to set up negative values.
I have another suggestion for this issue and made a new patch and PR:
https://github.com/drupalcommerce/commerce/pull/507
Comment #6
drugan CreditAttribution: drugan as a volunteer commentedThis solution totally relies on the #step property of quantity field on a particular order item. The step need to be set up on the form display mode field settings page.
The quantity is a decimal type number field which at most could be 12 digits length and have up to 3 optional digits after decimal sign. This allows us to overload this field and create 4 different number formats. Example: N - integer, N.N, N.NN and N.NNN decimal types. That is cool because now we can sell things not only **per item** basis but **per dimension** basis too and have them in the same shopping cart together.
Deficiencies. First, for now the "Default" and "Add to Cart" form display modes MUST to have identical settings, especially #step setting. It could be missed by some users and cause mess up. Second, developers have thoroughly to consider what the quantity is. I do not recommend do things like this:
round($order_item->getQuantity()).
A helper getQuantityWidgetSettings() is introduced to fetch current order item "Default" mode form display settings and make decisions based on this. Also, the code which needs to count items, such as Shopping Cart Block, have to use getItemsQuantity() method. Other code, such as price or tax calculation does not need to change something as they count real quantity, what ever the type of this number might be.
UPD: In order to have a full effect from this patch you need to manually change Database settings on the quantity field in the commerce_order_item table. Just change precision to 12 and scale to 3 (12,3). It will be better to truncate the table before doing this through site admin interface deleting all existing orders and carts or your DB manager or CLI. Or reinstall the commerce after applying the patch but that is the long story. That is because the patch itself cannot change your DB settings as they are set up during drupalcommerce installation process. And as ever flush caches after applying the patch.
New PR is done.
Comment #7
drugan CreditAttribution: drugan as a volunteer commentedComment #8
drugan CreditAttribution: drugan as a volunteer commentedComment #9
drugan CreditAttribution: drugan as a volunteer commentedA new version of the patch is done. I'd recommend to revert #6 and apply this #9 patch.
Comment #10
drugan CreditAttribution: drugan as a volunteer commentedThe renewed version of this patch mirrored from the latest commit on this PR. Some discussion on the drupalcommerce quantity field concept may be followed on the PR.
Also, if you want to have per form display mode configurable number widget without installing drupalcommerce you could use this patch. It makes the actual core number field configurable.
Comment #11
klagler CreditAttribution: klagler commentedI used the core patch to fix this issue, thanks again.
Any idea why this isn't already included in drupal core ?
Comment #12
drugan CreditAttribution: drugan as a volunteer commented@kragler
The number widget patch is not included in the core because this is not a bug, just a feature request. As there is no user feedback on the request then lead drupal core maintainers won't even start discussion on this. And they are right there because the request may appear as specific one, appropriate only to a few users. Remember that any new code introduced may introduce new bugs and no one wants to have them just because of the new **feature**.
Note that even on the drupalcommerce variant of extended number widget (current issue) the discussion just only now has started (thanks you) despite the urgent need to resolve order item quantity field issue.
Let us wait and see. In the beginning of March drupalcommerce will have its first release candidate and therefore more users.
#2845500: Release 2.0-RC1
But I think that a drastic increase of a number of users will start only when drupalcommerce gets its first prepacked version without need to install it through command line interface.
Comment #13
Munavijayalakshmi CreditAttribution: Munavijayalakshmi at Valuebound commentedComment #14
iampumaCurrently implemented the following, to alter the `Add to cart` form:
Assumes you have the quantity field.
Comment #15
drugan CreditAttribution: drugan as a volunteer commented@Munavijayalakshmi
Please, elaborate to what version you need the patch to be re-rolled.
Today I've applied the patch cleanly to this HEAD:
Comment #16
mglamanI don't know why that person changed that. Especially since our patch work is on GitHub PRs and reviews mostly there.
Comment #17
shabana.navas CreditAttribution: shabana.navas at Acro Commerce commentedComment #18
shabana.navas CreditAttribution: shabana.navas at Acro Commerce commentedI can confirm that this patch works, as a new 'Commerce number field' is added and we can configure the html properties mentioned in the resolution for each of the display modes like 'Add to cart'.
Definitely would like to see this be committed.
Comment #19
Frank HH-germany CreditAttribution: Frank HH-germany commentedHello, the patch is so long.
What I noticed is:
In the cart, which is compiled through a view, the quantity input works in whole numbers.
On the other hand, all settings in order-item-type are not included in the product page.
This means that even the inline output of the label remains. Also, the assigned class, which I need to replicate Omege kickstart on Bootstrap3, is not accepted.
I think the integration is wrong somewhere. Missing semicolon, etc.
Small cause, great effect. ;-)
Comment #20
bbuchert CreditAttribution: bbuchert as a volunteer commentedI'm having the same issue as @Frank HH-germany. https://www.drupal.org/node/2873310 The increments are applied to the cart but not to the product page.
Comment #21
drugan CreditAttribution: drugan as a volunteer commented@Frank HH-germany @bdichgans
What I see from your screenshots you are trying to configure the quantity field on the Manage display tab. The current issue has nothing to do with the field formatter, i.e.- with quantity value displayed on a page which can't be edited by a customer. Instead, it applies to the quantity field form widget, i.e- the value and prefix/suffix displayed on the Add to cart form (see #6 screenshot). So, to make this solution work you need to do the following:
Also, you may consider to apply the following:
#2816859: Allow the 'step' to be configured as a NumberWidget setting
The solution is targeted at 8.4.x drupal version but applies to 8.3.x too. What it does is basically the same but on the core level, not drupalcommerce. In this case you can use the standard Number field widget. The difference is that you'll don't see the effect on the cart page (if this diff not applied). Also, the standard cart block may display wrong quantity value.
Comment #22
Frank HH-germany CreditAttribution: Frank HH-germany commentedHi Drugan,
Would not it be easier to set the value "step" to "1"?
I would only know where I find the file, in which the "step value" stands.
Because I change that with Firebug, it goes the way it should go.
<input data-drupal-selector="edit-quantity-0-value" class="form-number form-control" id="edit-quantity-0-value" name="quantity[0][value]" value="1"
step="0.01"placeholder="" title="" data-toggle="tooltip" type="number">
I really do not see an example where one might need a step of 0.01.
Comment #23
drugan CreditAttribution: drugan as a volunteer commented@Frank HH-germany
You see 0.01 step because the current quantity field is of decimal number type. It is the smallest step for the field with the precision == 10 and scale == 2. If you need other value for the step just follow up #21 guide.
Why not use integer number filed type instead of the decimal and therefore avoid all the complexity related?
That was initially decided by the lead drupalcommerce developers to use decimal type for the quantity field because it makes this field versatile (given this .diff is applied). For example, your products may be counted per item basis (t-shirts) and per dimension basis (fiber cable sold by length) and exist all together in the same shopping cart/order!
Comment #24
agoradesign CreditAttribution: agoradesign commented@Frank HH-germany
You could also try this module: https://www.drupal.org/project/commerce_quantity_increments
Its primary use case is to be able to restrict certain products to be only available in certain increments, like 5, 10, 15,etc. However it defaults to 1. So you shouldn't have to do any edits on product variations after enabling the module
Comment #25
Frank HH-germany CreditAttribution: Frank HH-germany commented@drugan
Yes, but only per meter, inch, zoll, yards, elle, mile, liter, barrel, wight etc. Waht ever
Never by 0,5 from a given product. That is so silly.
Hi, i wish me a half cable or 0.01 from a Windows 10. Ha Ha.
By the way. When i implement the diff, I can never update again or I must constantly repeat this extensive steps.
Since it is easier times briefly in the relevant file the one value to change. Only one would have to know where this file is.
@agoradesign
Thanks for the link, i will test this.
Comment #26
agoradesign CreditAttribution: agoradesign commented@Frank HH-germany
You're welcome.
I don't think at all that this is silly. There are definitely use cases, where it should be possible to e.g. buy 0,5 meter. In 99% use cases you'll want full integers of course, but Commerce must be able support both. So in the long run it's important to serve better defaults.
regarding the "never update again" thing: you should never manipulate any shipped file (core or contrib). You can patch the patch file with command line, or better define it in your projects's composer.json (with the help of cweagans/composer-patches library, which is part of all recommended default Drupal/Drupal Commerce composer.json skeletons)
+ before needing to manipulate shipped files, you have in Drupal quite often the chance to implement a workaround in a custom module. Like here, where you still could implement hook_form_alter() for the cart form and set the step attribute properly
Comment #27
Frank HH-germany CreditAttribution: Frank HH-germany commented@agoradesign
Das Modul habe ich jetzt ausprobiert.
Läuft super.
Danke.
---
The module I have now tried.
Running
Thank you.
Comment #28
agoradesign CreditAttribution: agoradesign commentedgern geschehen :)
Comment #29
Frank HH-germany CreditAttribution: Frank HH-germany commentedVieleicht hast Du ja noch n Trick 17 auf lager, mit welchem asich folgendes in Drupal realisieren lässt?
Ich würde gern für meine erstes Theming-/Distriprojekt auch dieses Gimmick noch mit einbauen...
Comment #30
agoradesign CreditAttribution: agoradesign commentedOff-topic hier in Commerce --> continue in #2874603: Drupal 8 and SVG
Comment #31
agoradesign CreditAttribution: agoradesign commentedsorry, wrong issue
Comment #32
Eric HeydrichIf I install the patch, I have to update the quantity field. I use drush entity-updates -y but it's not allowed to update an existing entity. Could you provide an update hook?
Comment #33
drugan CreditAttribution: drugan as a volunteer commented@Eric Heydrich
If you mean the number field patch for the core, then it already has field_update_8004() which could be run by a regular system update. Not tested if it will update the drupalcommerce quantity field but I think that it don't. Because the quantity is not a regular field, instead it is a part of the Content Entity (order item). That's why we don't have access to the field's storage or basic settings such as precision, scale, label, required/optional, default value, etc..
The patch on the current issue does not have upgrade hook for the quantity field at all. I have to explore how to make applying the number field patches easier both for those who already has built a site and who applies it on a clean drupalcommerce system.
Comment #34
drugan CreditAttribution: drugan as a volunteer commentedAdded default .yml configuration files. So, if the patch is applied before installing drupalcommerce site, then all new features are enabled automatically in the installation process. For those who applies the patch on a live site (with existing orders) added commerce_order_update_8301() hook. It updates quantity field storage definition to precision = 14, scale = 4. Also, it changes field widget to Commerce number field on all order item types if the quantity field was enabled on a form display mode. The initial default settings on involved modes are: min = step = default value = 1. Though all the newly after the update enabled quantity field widgets will have: min = 0, step = 0.0001, default value = 1. Set up those values for what you need on the each order item type/form display mode.
The core's number field patch might be used together with the patch above. Just apply it, run updates and change Commerce number field widget to a regular Number field widget. The patch will have more support in the future and additionally might be used to add improved numeric fields to any other entities within drupal site.
How to run the update.
Note that drush may give warnings that field with existing data can not be updated. Ignore it. I didn't find the reason why it complains because commerce_order_item table is truncated before making changes and restored data after the update. Just wait until the update is completed and then check your existing orders/order item types.
ALWAYS BACKUP DATABASE BEFORE RUNNING ANY UPDATES!
Comment #35
drugan CreditAttribution: drugan as a volunteer commentedThere are use cases when you don't want quantity field on an Add to cart form exposed to a customer. But the issue is that if they add the variation to cart and then go to cart page they'll have access to quantity field and able to update the value.
You can fix this by setting step = min = max = default value = YOUR VALUE on the Default form display mode of the order item type for this variation. A customer will see the value in the Shopping cart table but they can't to edit it because browser does not allow them to do it.
Comment #36
Eric Heydrich@drugan Thanks for your work. I installed the new patch on my existing commerce installation. When I try to update the database, I get the following error and the update process stops:
and two warnings:
Before updating the database, at the moment the new quantity field works on add to cart forms, but not in Views. On the cart page view there is still a max-value of 9999, which isn't changeable. Maybe after updating the database it also works in Views?
Comment #37
drugan CreditAttribution: drugan as a volunteer commented@Eric Heydrich
Thanks for the feedback.
As I see you have some custom order item types which don't have quantity field, at least at the moment of running the update. Please, try now. I've added a condition to check for the field existence before attempting any configuration changes.
Did you set max value on the widget?
How it works:
You've created a custom order item type (or using default one) and assign it for the variation type => product type.
You enabled Commerce number field widget on the order item at least on the default form display mode.
You set up at least step setting on the mode(s).
If you've enabled Add to cart form display mode, then a customer will see the quantity field with your settings for the field.
After adding a specific quantity of the product to Cart they go to cart page and see the quantity field(s) with the settings for that particular product type => variation type => order item type => Add to cart form display mode (or default mode).
If you still see 9999 max value on the cart page that means you did not set up max value for the order item type's Add to cart or Default form display mode. 9999 is a fallback value for the cart view. Note that settings on both the Default on Add to cart form display modes should be the same for each order item type.
Or, the patch did not applied properly and modules/cart/src/Plugin/views/field/EditQuantity.php is not modified by the patch.
The patch does not modify anything related to Views. So, if the views or any other code passes quantity field's render array for rendering then you should to see all your settings on the form display. But if it hacks the render array (like EditQuantity.php did) then you may not see the effect from the patch.
I'd recommend to get $order_item object in the context where you don't see your settings and do this:
See modules/cart/src/Plugin/views/field/EditQuantity.php for more info on how it could be done.
Comment #38
Eric Heydrich@drugan I tested the way you described. I thought, if I don't set a max value, there is no maximum. After I set it, now the cart also shows the right max value. Maybe it could be useful to overwrite the fallback value (e.g. set to 0 means no max value).
Thanks for clarifying.
Did you upload a new patch? Database update still stops with error and isn't finished.
Comment #39
drugan CreditAttribution: drugan as a volunteer commented@Eric Heydrich
Can't reproduce your issue.
What I've done:
Installed drupalcommerce site (the latest commit).
Created all the default product/variation with quantity disabled on an Add to cart form.
Added this variation to cart and completed the order.
Created product of custom product type > product variation type > order item type with quantity enabled on an Add to cart form.
Added this variation to cart and completed the order.
Added the default and custom product variations to cart and leaved this order in a Shopping cart state.
So, I had three orders and four order items in total.
Applied this patch.
Checked the order item types' form display modes and quantity fields on the cart and products' view pages. They were the same as before.
Run the mysite.com/update.php.
The update has been completed successfully, the quantity field DB and configuration definitions (precision&scale) were updated as expected.
Checked the order item types' form display modes and quantity fields on the cart and products' view pages. They were also updated as expected.
Restored DB to a pre-update state.
Run the update with drush.
The update has been completed successfully, despite having some error messages on the terminal. Checked all the above. OK.
Applied additionally this patch and changed Commerce number field widget to the Number field on order item types. All worked as expected.
So, please post more info on the environment you are running the update. DB type, are there any additional patches applied, is your commerce installation updated to the latest version, what the order item types/enabled form display modes you have, what the orders/shopping carts exist, etc..
Comment #40
Adrian83 CreditAttribution: Adrian83 commentedThe solution that I went with is the module from #24.
Comment #41
Christopher Riley CreditAttribution: Christopher Riley commentedI installed just the core patch which applies to 8.3 cleanly and so far no issues.
Comment #42
mglamanI'm going to review this today.
Comment #43
mglamanSome initial notes:
Working on an update.
Comment #44
mglamanThe root issue here is quantity step. There is a lot of work here which bloats the scope of the issue, and can be seen in the reference core issue. Here is a patch which brings what we just need: quantity step. In add to cart and cart form.
Comment #45
mglamanUpdating credits.
Comment #46
mglamanUpdated PR: https://github.com/drupalcommerce/commerce/pull/755 and patch.
I need to re-run tests and review entire patch. But this is withint he specific scope of: allow customizing quantity step so it isn't always 0.01. And if step is 1, convert the value to (int) so decimal removed.
Comment #47
mglamanDiscussed with bojanz. This should be part of the view handler settings, not magical loading of form display.
Comment #48
drugan CreditAttribution: drugan as a volunteer commented@mglaman
I can't imagine how you'll decide on the step value without loading form display settings.
Could you to explain please why this algorithm is opposed? The step exposed to a user on the Add to Cart form that is exactly this value should be taken into account. Nothing else.
Comment #49
mglamanBecause these are two different settings. One is in the entity display system, another in Views. In all reality, I wish the cart form used the order item's form display mode. But for the sake of having a default step of 1, the 95% use case, this is the cleanest solution forward. Those needing decimals and a large scale will have to edit in two places.
Comment #50
drugan CreditAttribution: drugan as a volunteer commentedThe quantity field on the Views cart page should be the exact duplication of the quantity field on the Add to Cart form. Otherwise the whole system is broken when user adds an item to a cart with decimal quantity (for example 0.3 of an item ) and then can adjust the quantity only to an integer value on the cart page (for example 1, 2, 3, ...).
I agree on that. Why not to change this line:
... for this one:
That way we'll kill all the issues related to the quantity. The rest of 5% decimal quantity use case could be left for a contrib to solve.
Comment #51
agoradesign CreditAttribution: agoradesign commentedIf you already define the base field as integer, there'd be a lot of more work in contrib. Better would be to leave the decimal storage but to force all quantity input fields (add to cart form, as well as on the cart view) to only allow integers by default - this would be far easier to override in contrib/custom modules
Comment #52
drugan CreditAttribution: drugan as a volunteer commented@agoradesign
Would be the quantity decimal or integer, you need to write an update hook because the current by default scale == 2 can not satisfy all the users of the decimal quantity. For example, a quantity of order item measured in kilograms must have scale == 3. Therefore, it is not an easy task for a contrib in any case.
Comment #53
bojanz CreditAttribution: bojanz at Centarro commentedWe are definitely dealing with edge cases here.
The idea is for Commerce to give a broad base for contrib to extend. Contrib not needing to change the storage (the quantity field) is the primary improvement over Commerce 1.x. I recognize that many sites with decimal quantities will actually need agoradesign's commerce_quantity_increments, and that's fine.
Opened #2892207: Increase the order item quantity scale to discuss increasing the precision/scale of the quantity field.
@drugan, please respond there, I am curious to why you chose "4" instead of "3" as the scale in your original patch.
Loading the order item display(s) from the cart worries me because there is a performance penalty. That's why I suggested to Matt that he drops that approach. However, I can see how it can be very useful to people selling only certain order items with decimal quantities (product A has whole quantities, product B has decimal quantities). Therefore, I suggest a compromise. We add an "Allow decimal quantities" setting to the views field, off by default. When on, we load the form displays and take the quantities. Thus, the performance impact is limited to people who actually have this use case.
Comment #54
bojanz CreditAttribution: bojanz at Centarro commentedComment #56
bojanz CreditAttribution: bojanz at Centarro commented1) Implemented the views handler setting that I requested in #53, and fixed a few bugs along the way.
2) Moved the widget to commerce_order and named it commerce_quantity. No need to make this super generic, better to have room for more meaningful labels/descriptions.
3) Redesigned and rebuilt the widget settings, after discussing it with rszrama and mglaman. Screenshot attached.
The step setting is only shown if "Allow decimal quantities" is checked, and has a dropdown of values to make it more discoverable. The dropdown has 0.1, 0.01, 0.25, 0.5, 0.05, covering the most common configurations. Will be expanded once we increase the precision of the quantity field.
4) Added an update hook. Won't work for people who modified their order item form displays, they'll have to choose the new Quantity widget manually.
Comment #57
Adrian83 CreditAttribution: Adrian83 commentedI updated to the latest dev version of Drupal Commerce, updated the widget on the quantity field at /admin/commerce/config/order-item-types/default/edit/form-display and /admin/commerce/config/order-item-types/default/edit/form-display/add_to_cart, and bingo, the add-to-cart and cart views page quantity fields step in increments of 1.
Thank you!
Comment #58
zenimagine CreditAttribution: zenimagine commentedThe update causes an error when updating the database
Comment #59
Frank HH-germany CreditAttribution: Frank HH-germany commentedAt #58
Some new Updates, some new functions and much too little test before public.
Well, is also still beta, respectively with composer basically dev.
https://www.drupal.org/node/2893323#comment-12162007
This Project grows with testwilling Users...
Drupal is much better then Wordpress but you can change and then you pay a lot of mony for a silly System an the Wordpress-in-Apps...
To day is the only stable version of Commerce 7.x.
I work with this, but i need the newer version 2 and i will help by through with pleasure to a new perfect Commerce-CMS with a verry great comunity.
But you can try to run update.php again.
But before the performance optimizations turn off and delete the cache.
That worked with me very often, actually always worked out.
Because it should be a basic code problem, your page crashes. So also use Backup and Migrate !!!
Comment #60
zenimagine CreditAttribution: zenimagine commentedThank you it works.
Do you know when the "rc" is planned ?
Comment #61
bojanz CreditAttribution: bojanz at Centarro commented@zenimagine
You deleted the config that the update function was trying to update.
That's fine, it just means you'll need to select the Quantity widget manually for your order item types (on Manage form display).
Opened #2893608: ConfigUpdater should not report missing config as a fail to not treat this as an error in the future.
Comment #62
zenimagine CreditAttribution: zenimagine commentedYes i have customize field quantity. thank you for the answer
Comment #64
drugan CreditAttribution: drugan as a volunteer commentedComment #65
rgpublicWow. The GitHub patch from the description just saved my life. Thanks a lot! I tried for ages to get the needed 0.001 precision until I found this patch. I wonder, though, what "For those who are still need this functionality" means. I assume it means: "For those who are not working with the dev-version", right? So this patch is included in future Commerce releases?
BTW: I think the patch contains a small bug, because I cannot change the quantity in the cart anymore. I think in "viewsFormSubmitOverride" the call to "$order_item->setQuantity($quantity);" is missing.
Comment #66
drugan CreditAttribution: drugan as a volunteer commented@rgpublic
Please, revert the patch and download and apply the updated patch again:
https://github.com/drupalcommerce/commerce/compare/8.x-2.x...drugan:quan...
This pull request is not accepted (closed). So, the current patch exists only on my own fork/branch. What you see on the base Drupal Commerce project is the outdated version of the patch.
I am going to move this functionality into a contrib module as soon as I have time for this work.
Comment #67
rgpublic@drugan: Ah, great. Thanks for the updated patch. I find the current situation a bit weird though: It's not easily understandable why a precision like 0,001 doesnt simply work out of the box. You really have to do some research to find the reasons and finally this bug/issue. I wouldnt deem that precision overly exotic. And without the patch, I just get a dropdown list where I can only choose between 0,1, 0,01, 0,25 etc. but I can not enter arbitrary values/precision. This is quite weird IMHO. Not very intuitive. But, whatever, better a contrib module than nothing :-/
Comment #68
bojanz CreditAttribution: bojanz at Centarro commentedTo be clear: Commerce ships with support for decimal quantities by default. You have a Quantity widget setting that allows you to specify the Step.
That was the outcome of this issue.
A more complex version of this functionality was rejected, but check what Commerce gives you before hunting for old patches.
Comment #69
rgpublic@bojanz: I understand, but without the patch the "step" is just a dropdown-list with prefilled values (I'm using Commerce 8.x-2.1) . I couldnt have 3 floating point digits like "1.234" as a quantity value. And even if I used hook_form_alter to set "#step" manually, the quantity was always truncated. The patch at least makes it possible to really get 3 digits of precision for the quantity field. I might be wrong but I dont see any other way to achieve this result.
Comment #70
bojanz CreditAttribution: bojanz at Centarro commentedYes, we're limited to two decimals until #2892207: Increase the order item quantity scale is fixed.
Comment #71
jeffdavid CreditAttribution: jeffdavid commentedIn order to get the full effect of this patch, you need to manually change the database settings in the Quantity field in the trade_order_item table. Just change the resolution to 12 and size to 3 (12,3). It would be best to truncate the table before doing so through the webmaster interface by deleting all current requests, vehicles, or a bear manager. 70-243 Dumps Or re-install the trade after applying the patch but this is a long story. This is because the patch itself can not change your bear settings as it is set up during the DrupalCom installation process.
Comment #72
drugan CreditAttribution: drugan as a volunteer commented@jeffdavid
Actually, the patch has implemented update hook:
commerce_order_update_8201()
. After applying the patch you can look at it in the modules/order/commerce_order.install file.Just run updates visiting http:\\example.com/update.php page or through drush:
drush updb --entity-updates
Note that drush may emit an error like: "The field is not empty, so it cannot be updated". Ignore it. I did not find the reason for it despite all the quantity instances were updated successfully.
In the end of successful update you should see this message:
The order item quantity field definition has been successfully updated.
Otherwise this one:
The attempt to update order item quantity field is failed. To update the field manually go to commerce_order_item table in the site's DB and edit quantity field structure changing its Length to 14,4. Then flush caches and set Commerce number field widget for each of the order item type's enabled form display modes.
Do exactly what it says.
Thanks for testing the patch. By the way, if you need similar functionality beyond the Drupal Commerce you may use this:
#2816859: Allow the 'step' to be configured as a NumberWidget setting
Looking for a breach in my timeout to move this functionality into a contrib. Unfortunately, as most of developers I have to do the sponsored work first and only then all the rest.
Comment #73
drugan CreditAttribution: drugan as a volunteer commentedThis issue is now fixed in the Commerce Extended Quantity module:
https://www.drupal.org/project/commerce_xquantity
Comment #74
freelylw CreditAttribution: freelylw commentedI had a fresh install commerce latest dev, but still with this issue
"The problem is that the quantity field has default '#step' property set to 0.01, which gives 1.01, 1.02, ..."
Any way I can solve this problem without install a extra module ? Thank you
Comment #75
bojanz CreditAttribution: bojanz at Centarro commented@freelylw
You don't need any module. Just make sure your Quantity field is using the "Quantity" field widget (the add to cart form display). Right now it probably isn't.
Comment #76
freelylw CreditAttribution: freelylw commented@bojanz thanks
if I am right, I can only see the setting for the quantity field in here" admin/commerce/config/order-item-types/default/edit/form-display "
Its using the "Quantity" widget, but the problem still the same.
Comment #77
bojanz CreditAttribution: bojanz at Centarro commentedThe widget has a "Allow decimal quantities" option. Make sure it's disabled.
Comment #78
freelylw CreditAttribution: freelylw commentedyes,"Allow decimal quantities" option is disabled. the problem still the same. please see below my screen image. thanks
Comment #79
trigdog CreditAttribution: trigdog commented@freelylw Make sure you are on the "Add to Cart" form display. Your screenshot looks like you are on the default form display.
Comment #80
chipway CreditAttribution: chipway at Chipway commentedWe met this issue recently.
After setting both our customized order item and default order item with the same quantity config (quantity and no decimal) it was solved. In case it may help some one.