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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drugan created an issue. See original summary.

drugan’s picture

wrong

drugan’s picture

mglaman’s picture

Status: Needs review » Needs work

Linking 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?

drugan’s picture

No, 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

drugan’s picture

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

settings

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.

cart

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.

drugan’s picture

Status: Needs work » Needs review
drugan’s picture

Issue summary: View changes
drugan’s picture

A new version of the patch is done. I'd recommend to revert #6 and apply this #9 patch.

drugan’s picture

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

klagler’s picture

I used the core patch to fix this issue, thanks again.
Any idea why this isn't already included in drupal core ?

drugan’s picture

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

Munavijayalakshmi’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll
iampuma’s picture

Currently implemented the following, to alter the `Add to cart` form:

Assumes you have the quantity field.

/**
 * Implements hook_form_FORM_ID_alter().
 */
function xi_helper_form_commerce_order_item_default_add_to_cart_1_form_alter(&$form, &$form_state, $form_id) {
  // The quantity field should have increments of 1.
  $form['quantity']['widget'][0]['value']['#step'] = 1;
  // The miminum quantity allowed is 1.
  $form['quantity']['widget'][0]['value']['#min'] = 1;
}
drugan’s picture

Status: Needs work » Postponed (maintainer needs more info)

@Munavijayalakshmi

Please, elaborate to what version you need the patch to be re-rolled.

Today I've applied the patch cleanly to this HEAD:

commit d82e7e9a45f5dbdd5e9fc5708b95f9691021a7cd
Author: Matt Glaman
Date: Fri Mar 24 13:50:20 2017 -0500

Issue #2863830 by mglaman: Disabled coupons still apply

mglaman’s picture

Status: Postponed (maintainer needs more info) » Needs review
Issue tags: -Needs reroll

I don't know why that person changed that. Especially since our patch work is on GitHub PRs and reviews mostly there.

shabana.navas’s picture

Title: Change HTML step property of the quantity field to 1 » Make the quantity field configurable to include HTML properties such as 'Step' property
Issue summary: View changes
shabana.navas’s picture

Status: Needs review » Reviewed & tested by the community

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

Frank HH-germany’s picture

FileSize
92.86 KB
116.76 KB

Hello, 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. ;-)

bbuchert’s picture

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

drugan’s picture

@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:

  1. First, apply this diff.
  2. Go to admin/commerce/config/order-item-types/default/edit/form-display and enable Quantity field.
  3. Choose Commerce number field as the widget.
  4. Click at the gear icon and set up what you need on the widget.
  5. Go to admin/commerce/config/order-item-types/default/edit/form-display/add_to_cart and repeat 3 and 4 steps for this display mode.

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.

Frank HH-germany’s picture

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

drugan’s picture

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

agoradesign’s picture

@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

Frank HH-germany’s picture

@drugan

(fiber cable sold by length)

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.

agoradesign’s picture

@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

Frank HH-germany’s picture

@agoradesign

Das Modul habe ich jetzt ausprobiert.
Läuft super.

Danke.

---

The module I have now tried.
Running

Thank you.

agoradesign’s picture

gern geschehen :)

Frank HH-germany’s picture

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

<style type="text/css">
svg {
  background-color: #e6f2f7;
} 
 
.land {
  fill: #fffbf0;
  stroke: #e7c157;
  stroke-width: 0.4;
}
 
.land:hover {
  fill: #dfac20;
  stroke:#333;
}
 
.info {
  opacity: 0;
  font-size: 8px;
  fill: white;
  pointer-events: none;  
}
 
#ACT:hover ~ .ACT,
#ACT:focus ~ .ACT,
#NSW:hover ~ .NSW,
#NSW:focus ~ .NSW,
#NT:hover ~ .NT,
#NT:focus ~ .NT,
#QLD:hover ~ .QLD,
#QLD:focus ~ .QLD,
#SA:hover ~ .SA,
#SA:focus ~ .SA,
#TAS:hover ~ .TAS,
#TAS:focus ~ .TAS,
#VIC:hover ~ .VIC,
#VIC:focus ~ .VIC,
#WA:hover ~ .WA,
#WA:focus ~ .WA {
  opacity: 1;
  transition: all 0.5s linear;
}
 
.headline {
  opacity: 1;
  font-size: 16px;
  fill: #3983ab;
}
</style>
<h1>Beispiel: interaktive Landkarte - 2</h1>

<main><svg height="560" viewbox="0 -20 300 280" width="600" xmlns="http://www.w3.org/2000/svg"> <desc> Karte von Australien</desc> <defs> <symbol id="tooltipp"> <path d="M2,2 h70 a3,3 0 0,1 3,3 v10 a3,3 0 0,1 -3,3 h-45 l-6,10 l-2,-10 h-14 a3,3 0 0,1 -3,-3z" fill="#666" stroke="black" stroke-width=".25"> </path></symbol> </defs> <g class="AUS" fill="#d3d3d3" id="Australia"> <text class="headline" x="0" y="0"> Australien</text> <text class="headline" x="0" y="20">Bundesstaaten</text> <a class="NSW" id="NSW"> <path class="land" d="M271 130L270 130 270 131 269 131 268 131 268 132 268 133 269 133 268 134 268 134 267 135 266 134 266 134 265 134 264 135 264 136 263 136 263 135 263 134 262 134 262 133 261 132 260 132 259 132 258 132 257 132 257 132 256 131 255 131 254 132 253 131 251 131 251 131 250 132 249 132 249 133 248 133 248 134 247 134 194 134 194 179 194 179 194 180 195 179 197 180 198 180 200 180 202 180 204 182 204 184 205 185 205 184 207 183 207 183 209 183 210 184 211 187 212 189 213 189 215 189 217 191 217 192 219 193 220 194 222 194 221 192 222 192 223 192 223 192 225 192 227 192 228 192 229 193 230 193 231 192 232 192 233 193 235 193 236 193 237 192 238 192 239 192 239 192 241 192 241 194 241 195 242 196 242 197 242 198 250 202 252 202 253 203 253 203 253 204 253 204 254 203 254 201 255 201 255 201 255 200 254 200 254 199 254 198 254 198 255 197 256 193 255 191 256 190 255 190 256 189 256 188 257 188 258 184 260 184 259 183 260 182 260 183 260 183 260 182 259 182 260 182 259 181 260 181 261 179 260 179 261 178 261 177 263 175 262 175 263 175 262 174 263 174 263 173 263 174 262 173 263 173 263 173 263 173 264 171 264 171 263 172 263 171 263 171 263 171 263 171 264 170 264 171 264 170 265 169 264 169 265 169 266 167 265 168 265 167 266 167 266 166 266 167 267 166 266 165 267 165 267 166 269 164 269 164 268 165 267 165 268 164 268 164 269 164 269 164 269 164 270 163 272 162 272 160 271 160 271 161 270 160 271 160 271 160 272 159 273 157 275 151 275 147 276 143 277 142 277 139 277 138 277 139 277 138 279 135 278 135 279 134 279 133 278 132 278 130 278 130 277 130 276 130 276 130 275 131 274 130 273 131 272 130 271 130zM246 186C246 186 247 186 247 186 248 186 248 187 248 187 248 187 248 187 247 188 247 188 246 189 246 190 246 190 246 191 245 191 245 191 245 191 245 190 244 190 244 189 244 188 244 188 244 187 244 187 245 186 245 186 246 186z" id="NSW-mainland"></path> </a> <a class="NT" id="NT"> <path class="land" d="M125 13L127 14 129 13 130 11 131 12 131 11 131 11 131 9 130 9 129 9 129 10 129 11 129 9 128 10 128 10 128 11 128 10 128 10 127 10 126 10 126 11 126 11 125 10 125 10 125 10 125 10 125 10 125 9 123 8 124 11 123 11 124 11 123 11 124 10 123 10 122 11 123 11 122 11 122 12 122 12 122 13 122 12 122 12 121 12 121 13 121 13 125 13 125 13zM114 34L114 117 173 117 173 44 173 43 171 43 168 41 167 41 167 41 166 41 166 41 166 40 163 39 162 37 159 35 159 36 159 35 158 35 157 34 157 33 158 32 159 30 160 29 161 28 162 26 161 26 160 26 160 24 161 24 161 24 160 24 161 23 161 23 161 23 162 22 162 23 162 22 163 22 163 21 164 23 163 23 164 23 165 21 164 21 165 21 164 20 165 20 165 19 165 20 165 19 166 19 166 18 166 17 166 17 166 18 168 17 166 15 166 16 166 16 165 16 165 14 164 14 165 13 162 15 164 16 163 17 162 17 162 17 161 18 161 17 161 17 161 16 161 16 161 16 161 15 160 16 159 16 159 16 161 14 158 15 158 15 157 15 156 16 157 16 155 16 156 16 153 15 153 14 152 15 149 14 149 16 149 14 149 14 148 14 148 13 147 14 146 13 147 13 146 12 144 13 145 13 144 13 144 12 143 13 143 12 142 12 141 10 140 10 140 10 140 10 139 11 137 9 137 10 137 8 136 9 136 9 135 8 135 10 136 10 135 10 135 9 134 8 134 9 133 9 133 9 133 10 134 10 134 10 134 10 135 10 135 11 136 11 138 10 138 11 138 11 138 11 138 11 138 11 138 11 138 12 139 12 139 12 138 13 139 13 139 14 138 15 139 15 138 15 137 15 137 17 137 16 136 16 136 15 135 16 134 16 131 16 130 16 130 14 129 16 128 15 128 17 127 17 126 17 128 18 127 18 127 18 127 19 126 18 126 18 126 18 126 17 125 17 125 18 125 18 126 19 125 19 125 20 124 18 123 19 124 19 123 19 123 20 122 21 122 22 123 24 123 23 121 25 120 24 120 24 120 24 119 26 120 26 119 27 119 28 119 28 118 28 119 29 118 29 118 29 118 29 117 30 117 31 117 31 118 31 118 32 119 31 119 32 120 31 119 32 118 33 119 33 119 33 119 33 119 33 119 33 120 33 119 34 121 33 121 33 120 33 121 34 120 34 119 34 119 34 119 34 119 34 119 36 118 36 118 34 117 34 117 35 116 34 116 34 116 34 116 34 116 35 116 35 116 36 116 36 116 36 116 36 115 37 116 36 115 35 115 35 115 34 115 35 115 34 114 34zM164 29L165 30 167 30 167 29 167 29 166 29 166 28 166 28 166 27 167 27 167 26 167 27 166 27 166 26 166 26 165 26 165 26 164 27 164 28 164 29 163 30 164 29z" id="Melville-Island"></path> </a> <a class="QLD" id="QLD"> <path class="land" d="M205 5L204 6 203 7 202 7 202 8 202 11 201 11 201 13 202 13 201 13 201 14 201 15 202 14 201 15 201 15 201 16 200 14 199 16 200 16 199 16 198 18 199 18 199 17 200 17 199 18 200 18 201 18 200 19 201 19 201 19 201 20 200 19 200 20 198 21 199 23 199 23 199 23 199 23 200 24 199 24 198 27 199 29 198 31 199 35 198 39 197 41 197 42 196 46 194 49 194 51 192 53 188 54 188 53 187 53 185 52 184 51 183 51 182 49 181 48 179 47 175 47 173 44 173 117 194 117 194 134 247 134 248 134 248 133 249 133 249 132 250 132 251 131 251 131 253 131 254 132 255 131 256 131 257 132 257 132 258 132 259 132 260 132 261 132 262 133 262 134 263 134 263 135 263 136 264 136 264 135 265 134 266 134 266 134 267 135 268 134 268 134 269 133 268 133 268 132 268 131 269 131 270 131 270 130 271 130 272 130 273 131 274 130 275 131 276 130 276 130 277 130 278 130 278 130 279 129 278 129 277 126 277 124 276 123 275 124 276 123 275 123 276 122 275 121 276 121 275 120 275 120 276 121 276 119 275 120 276 118 275 118 276 116 275 116 276 112 276 112 275 112 275 113 275 112 274 112 275 111 274 111 274 109 274 109 273 109 274 109 274 108 272 107 272 107 271 105 271 104 271 104 270 104 271 104 269 103 269 103 268 102 267 99 266 99 267 98 266 99 266 98 266 98 266 99 265 99 265 99 264 99 264 99 261 95 261 96 260 95 260 95 260 93 260 93 260 90 260 90 260 89 260 88 260 88 259 88 259 87 260 88 260 87 259 86 259 87 259 86 259 86 258 87 259 88 259 88 259 89 256 86 255 85 255 85 254 86 255 88 255 89 255 88 253 87 252 88 253 87 252 87 252 86 252 86 251 86 252 86 251 83 251 80 251 81 250 80 250 80 250 79 249 79 249 78 249 78 250 77 249 76 248 77 248 76 247 76 247 75 247 75 246 75 246 74 246 73 246 73 246 73 246 73 247 73 248 73 246 71 246 72 246 71 245 71 245 70 244 70 244 70 244 71 244 71 243 70 243 70 243 69 242 69 241 69 240 67 240 67 240 69 239 68 238 67 239 67 237 65 237 66 236 66 235 64 234 65 234 65 233 64 231 63 230 62 230 59 229 59 228 57 229 53 228 53 228 51 227 49 228 48 227 48 224 45 224 44 224 44 224 42 224 41 223 39 223 38 224 37 224 36 223 37 223 36 224 34 223 34 223 34 221 33 221 32 219 32 218 29 217 30 216 30 215 31 214 31 213 31 213 28 211 26 212 24 211 22 211 20 210 20 211 18 210 18 210 17 208 17 208 15 210 14 208 14 208 14 207 13 207 10 206 7 205 7 205 7 205 7 204 7 205 6 205 6 205 5zM276 104L276 105 275 107 275 107 275 109 274 110 275 111 277 106 277 105 277 103 276 104zM184 46L184 46 185 45 185 46 186 45 185 44 183 45 182 46 183 47 184 46z" id="QLD-mainland"></path> </a> <a class="WA" id="WA"> <path class="land" d="M114 156L114 117 114 117 114 34 113 34 112 33 111 33 110 33 111 34 111 35 110 34 111 35 111 35 110 35 110 35 110 36 109 34 109 35 110 38 110 38 109 37 108 36 108 38 108 38 108 37 108 37 108 37 108 35 109 34 108 34 109 34 109 33 109 33 108 32 107 32 105 29 104 28 104 27 103 27 103 28 103 27 102 28 102 27 102 28 101 27 100 26 100 27 99 26 100 27 100 28 100 28 99 28 99 28 99 29 99 28 98 30 98 28 97 29 98 27 96 28 96 29 97 29 96 30 96 29 95 29 96 28 95 28 96 28 95 28 94 28 94 28 94 28 94 28 95 29 95 30 95 30 94 31 95 31 94 31 94 33 93 32 93 31 92 31 92 31 92 32 92 30 92 30 92 29 92 32 91 31 90 32 90 32 90 32 90 31 89 32 90 32 88 33 89 34 90 34 89 34 90 35 90 34 91 35 90 36 91 36 90 36 89 35 89 36 88 34 87 35 88 36 86 36 87 36 87 37 88 36 87 37 87 37 88 37 88 37 89 37 88 38 89 39 88 38 88 38 87 37 86 37 86 37 86 37 85 38 85 38 85 38 84 38 84 38 83 39 84 39 83 39 84 42 84 41 84 41 85 41 84 41 85 40 86 40 85 40 86 40 85 41 85 42 85 42 84 43 85 43 84 43 84 42 83 44 85 44 86 44 84 44 83 44 83 44 83 45 82 45 83 45 82 44 82 44 80 43 81 44 80 44 81 44 80 44 80 44 79 43 79 43 79 43 80 43 79 43 79 43 78 43 78 43 78 43 78 43 78 44 79 44 79 44 78 44 79 44 79 44 78 44 77 44 79 45 77 45 77 46 78 45 78 46 77 46 79 47 79 48 80 47 80 47 81 47 80 48 80 49 79 49 80 50 79 49 78 49 79 50 78 50 78 51 78 52 77 51 76 49 75 48 75 46 75 46 74 46 74 45 75 45 74 44 74 44 72 46 73 47 71 47 71 47 72 48 71 48 71 48 70 49 69 49 70 50 69 50 68 52 69 54 69 55 70 56 70 56 67 59 66 59 66 60 66 60 65 60 65 61 64 63 62 66 56 69 54 69 53 69 52 70 51 70 50 70 49 69 49 70 49 70 49 70 48 69 48 70 46 72 42 72 42 72 40 73 40 73 40 73 39 74 38 75 38 74 37 75 35 75 35 74 34 75 33 75 33 74 33 73 33 73 32 75 32 75 31 75 29 76 29 75 29 76 27 77 26 79 25 79 24 80 20 82 18 83 18 84 18 84 17 84 17 85 17 86 17 86 17 86 17 86 16 87 16 87 15 87 15 86 15 86 14 85 15 82 14 83 12 88 13 91 12 92 13 95 10 98 10 101 12 104 11 105 12 106 13 107 15 112 16 112 16 113 15 113 16 115 14 116 13 115 13 112 13 113 12 114 12 112 11 109 10 111 10 111 10 110 11 114 13 115 13 117 12 118 11 116 11 118 11 115 11 116 10 113 10 116 9 115 9 113 9 115 8 114 14 122 15 126 15 127 15 129 17 132 18 133 18 134 20 136 21 139 20 143 20 144 21 147 25 156 26 159 27 158 27 159 26 159 26 160 25 161 26 162 25 164 25 169 23 172 22 172 21 171 21 175 21 178 22 177 23 177 25 178 27 181 30 182 30 181 31 182 30 182 31 183 32 182 33 183 36 183 38 184 39 183 40 184 41 183 40 183 40 182 41 182 40 183 42 183 42 182 43 182 44 181 46 180 46 179 47 178 46 178 49 179 49 178 50 178 50 177 51 178 50 177 53 174 54 174 57 174 58 174 63 173 66 174 67 173 68 175 69 175 70 174 71 174 72 174 74 173 75 174 75 175 77 174 78 174 81 171 82 168 82 167 86 165 94 161 96 161 99 161 102 161 109 159 114 156z" id="WA"></path> </a> <a class="VIC" id="VIC"> <path class="land" d="M87 44L86 45 86 44 86 44 87 44zM253 204L253 203 253 203 252 202 250 202 242 198 242 197 242 196 241 195 241 194 241 192 239 192 239 192 238 192 237 192 236 193 235 193 233 193 232 192 231 192 230 193 229 193 228 192 227 192 225 192 223 192 223 192 222 192 221 192 222 194 220 194 219 193 217 192 217 191 215 189 213 189 212 189 211 187 210 184 209 183 207 183 207 183 205 184 205 185 204 184 204 182 202 180 200 180 198 180 197 180 195 179 194 180 194 179 194 208 195 208 197 210 197 211 198 211 198 211 200 210 202 211 204 210 212 215 215 211 217 210 219 210 219 208 218 209 217 208 218 208 221 206 222 209 221 210 219 210 221 212 222 211 223 211 223 209 224 209 225 211 224 211 224 212 225 213 227 213 227 213 226 213 227 215 228 214 229 215 229 214 230 216 231 217 231 214 230 215 230 213 232 213 234 213 238 208 241 207 238 208 240 207 239 207 239 206 240 207 242 206 242 206 251 205 253 204z" id="vic-mainland"></path> </a> <a class="SA" id="SA"> <path class="land" d="M194 208L194 179 194 179 194 134 194 117 173 117 173 117 114 117 114 156 114 156 121 155 122 155 126 156 129 154 133 156 136 159 138 159 137 158 138 158 139 158 142 160 144 160 144 160 144 159 145 160 145 159 147 162 147 162 147 163 148 162 149 162 150 164 149 165 149 164 148 164 149 165 148 166 149 166 149 167 150 168 149 167 150 168 151 168 152 168 151 168 152 168 152 168 153 170 153 171 156 174 157 179 157 179 157 179 158 179 157 180 156 179 157 179 156 178 156 178 155 179 156 179 159 182 160 181 161 183 161 180 160 181 160 181 161 179 161 178 162 179 162 177 165 174 168 172 167 173 167 172 168 172 169 172 171 168 172 166 173 167 173 162 174 165 174 167 175 167 173 169 174 171 172 174 171 175 171 176 171 177 171 178 171 178 171 179 171 182 170 182 168 182 167 185 169 185 171 183 172 184 173 184 172 183 174 181 174 179 175 176 178 181 178 181 178 181 178 181 177 185 175 188 178 188 179 187 180 187 184 189 180 187 183 189 185 192 184 190 185 190 186 193 185 192 187 197 187 198 186 199 187 200 186 201 188 203 190 206 190 207 192 208 194 208zM173 189L173 188 172 188 172 187 165 189 165 190 166 191 168 191 169 191 171 191 172 191 172 190 175 190 175 189 174 188 173 189z" id="SA-mainland"></path> </a> <a class="TAS" id="TAS"> <path class="land" d="M214 221L214 222 214 225 214 225 214 226 215 225 215 222 214 221zM240 224L240 225 241 225 242 227 244 226 243 225 243 226 243 225 243 224 243 224 241 222 240 224 240 224zM239 251L239 252 240 252 239 253 240 253 240 253 240 252 241 253 241 251 240 252 239 251zM243 239L243 237 244 236 243 235 244 233 242 231 241 231 240 232 239 232 238 233 237 233 235 234 235 233 233 234 234 235 234 235 233 234 232 235 232 235 231 234 230 235 225 232 223 232 223 231 223 232 222 231 222 232 219 230 219 232 219 233 220 237 221 239 221 240 223 242 223 244 223 244 224 246 225 246 224 247 224 246 222 244 223 248 224 248 225 251 226 252 227 254 227 254 227 254 227 253 228 254 230 254 229 255 228 254 228 255 227 255 228 256 230 256 232 256 232 256 233 257 234 257 235 256 234 255 235 255 235 254 234 254 235 254 234 253 235 252 235 253 235 253 235 253 235 253 236 254 236 251 237 252 237 250 236 249 237 251 238 250 237 252 238 251 238 250 239 250 238 249 239 249 239 250 240 250 241 248 240 247 241 247 241 245 241 245 242 243 243 243 242 243 243 242 242 243 243 243 243 245 244 244 243 243 243 239zM241 228L243 228 244 229 244 228 244 227 241 228z" id="King-Currie-Island"></path> </a> <a class="ACT" id="ACT"> <path class="land" d="M246 186C246 186 247 186 247 186 248 186 248 187 248 187 248 187 248 187 247 188 247 188 246 189 246 190 246 190 246 191 245 191 245 191 245 191 245 190 244 190 244 189 244 188 244 188 244 187 244 187 245 186 245 186 246 186z" id="ACT-territory"></path> </a> <g class="info ACT" transform="translate(225,155)"> <use xlink:href="#tooltipp"></use> <text x="5" y="12">Canberra</text> </g> <g class="info NSW" transform="translate(200,120)"> <use xlink:href="#tooltipp"></use> <text x="5" y="12">New South Wales</text> </g> <g class="info NT" transform="translate(130,20)"> <use xlink:href="#tooltipp"></use> <text x="5" y="12">Nord Territorium</text> </g> <g class="info QLD" transform="translate(200,10)"> <use xlink:href="#tooltipp"></use> <text x="5" y="12">Queensland</text> </g> <g class="info SA" transform="translate(150,95)"> <use xlink:href="#tooltipp"></use> <text x="5" y="12">Südaustralien</text> </g> <g class="info TAS" transform="translate(210,200)"> <use xlink:href="#tooltipp"></use> <text x="5" y="12">Tasmanien</text> </g> <g class="info VIC" transform="translate(200,170)"> <use xlink:href="#tooltipp"></use> <text x="5" y="12">Victoria</text> </g> <g class="info WA" transform="translate(30,40)"> <use xlink:href="#tooltipp"></use> <text x="5" y="12">Westaustralien</text> </g> </g> </svg>

<p>Fahren Sie mit der Maus über die einzelnen Bundesstaaten.</p>
</main>
agoradesign’s picture

Off-topic hier in Commerce --> continue in #2874603: Drupal 8 and SVG

agoradesign’s picture

sorry, wrong issue

Eric Heydrich’s picture

If 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?

drugan’s picture

Assigned: Unassigned » drugan

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

drugan’s picture

Assigned: drugan » Unassigned

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

  1. Through UI: go to http://your-site.com/update.php
  2. With drush: drush updatedb --entity-updates

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!

drugan’s picture

Issue summary: View changes

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

Eric Heydrich’s picture

@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:

Error: Unsupported operand types in commerce_order_update_8301() (line 75 of [ROOT_PATH]/modules/contrib/commerce/modules/order/commerce_order.install) #0
[ROOT_PATH]/core/includes/update.inc(178): commerce_order_update_8301(Array) #1
[ROOT_PATH]/core/includes/batch.inc(252): update_do_one('commerce_order', 8301, Array, Array) #2
[ROOT_PATH]/core/includes/batch.inc(95): _batch_process() #3
[ROOT_PATH]/core/includes/batch.inc(77): _batch_do() #4
[ROOT_PATH]/core/modules/system/src/Controller/DbUpdateController.php(186): _batch_page(Object(Symfony\Component\HttpFoundation\Request)) #5
[internal function]: Drupal\system\Controller\DbUpdateController->handle('start', Object(Symfony\Component\HttpFoundation\Request)) #6
[ROOT_PATH]/web/core/lib/Drupal/Core/Update/UpdateKernel.php(110): call_user_func_array(Array, Array) #7
[ROOT_PATH]/core/lib/Drupal/Core/Update/UpdateKernel.php(73): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request)) #8
[ROOT_PATH]/update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #9 
{main}.

and two warnings:

Notice: Undefined index: quantity in commerce_order_update_8301() (line 73 of /www/htdocs/w01418d9/paketseiten/unveroeffentlicht/sgvht/web/modules/contrib/commerce/modules/order/commerce_order.install) #0 /www/htdocs/w01418d9/paketseiten/unveroeffentlicht/sgvht/web/core/includes/bootstrap.inc(552): _drupal_error_handler_real(8, 'Undefined index...', '/www/htdocs/w01...', 73, Array) #1 /www/htdocs/w01418d9/paketseiten/unveroeffentlicht/sgvht/web/modules/contrib/commerce/modules/order/commerce_order.install(73): _drupal_error_handler(8, 'Undefined index...', '/www/htdocs/w01...', 73, Array) #2 /www/htdocs/w01418d9/paketseiten/unveroeffentlicht/sgvht/web/core/includes/update.inc(178): commerce_order_update_8301(Array) #3 /www/htdocs/w01418d9/paketseiten/unveroeffentlicht/sgvht/web/core/includes/batch.inc(252): update_do_one('commerce_order', 8301, Array, Array) #4 /www/htdocs/w01418d9/paketseiten/unveroeffentlicht/sgvht/web/core/includes/batch.inc(95): _batch_process() #5 /www/htdocs/w01418d9/paketseiten/unveroeffentlicht/sgvht/web/core/includes/batch.inc(77): _batch_do() #6 /www/htdocs/w01418d9/paketseiten/unveroeffentlicht/sgvht/web/core/modules/system/src/Controller/DbUpdateController.php(186): _batch_page(Object(Symfony\Component\HttpFoundation\Request)) #7 [internal function]: Drupal\system\Controller\DbUpdateController->handle('start', Object(Symfony\Component\HttpFoundation\Request)) #8 /www/htdocs/w01418d9/paketseiten/unveroeffentlicht/sgvht/web/core/lib/Drupal/Core/Update/UpdateKernel.php(110): call_user_func_array(Array, Array) #9 /www/htdocs/w01418d9/paketseiten/unveroeffentlicht/sgvht/web/core/lib/Drupal/Core/Update/UpdateKernel.php(73): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request)) #10 /www/htdocs/w01418d9/paketseiten/unveroeffentlicht/sgvht/web/update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #11 {main}.
Notice: Undefined index: settings in commerce_order_update_8301() (line 75 of [ROOT_PATH]/modules/contrib/commerce/modules/order/commerce_order.install) #0
[ROOT_PATH]/core/includes/bootstrap.inc(552): _drupal_error_handler_real(8, 'Undefined index...', '/www/htdocs/w01...', 75, Array) #1
[ROOT_PATH]/modules/contrib/commerce/modules/order/commerce_order.install(75): _drupal_error_handler(8, 'Undefined index...', '/www/htdocs/w01...', 75, Array) #2
[ROOT_PATH]/core/includes/update.inc(178): commerce_order_update_8301(Array) #3
[ROOT_PATH]/core/includes/batch.inc(252): update_do_one('commerce_order', 8301, Array, Array) #4
[ROOT_PATH]/core/includes/batch.inc(95): _batch_process() #5
[ROOT_PATH]/core/includes/batch.inc(77): _batch_do() #6
[ROOT_PATH]/core/modules/system/src/Controller/DbUpdateController.php(186): _batch_page(Object(Symfony\Component\HttpFoundation\Request)) #7
[internal function]: Drupal\system\Controller\DbUpdateController->handle('start', Object(Symfony\Component\HttpFoundation\Request)) #8
[ROOT_PATH]/core/lib/Drupal/Core/Update/UpdateKernel.php(110): call_user_func_array(Array, Array) #9
[ROOT_PATH]/core/lib/Drupal/Core/Update/UpdateKernel.php(73): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request)) #10
[ROOT_PATH]/update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #11
{main}.

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?

drugan’s picture

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

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.

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.

Maybe after updating the database it also works in Views?

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:

$settings = $order_item->getQuantityWidgetSettings();

See modules/cart/src/Plugin/views/field/EditQuantity.php for more info on how it could be done.

Eric Heydrich’s picture

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

drugan’s picture

FileSize
157.64 KB
111.37 KB

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

Adrian83’s picture

The solution that I went with is the module from #24.

Christopher Riley’s picture

I installed just the core patch which applies to 8.3 cleanly and so far no issues.

mglaman’s picture

Assigned: Unassigned » mglaman

I'm going to review this today.

mglaman’s picture

Status: Reviewed & tested by the community » Needs work

Some initial notes:

  • This patch adjusts the scale (to 4 decimals.) I'd prefer that to be a separate issue
  • This adds a new method to the entity for interacting with the entity form display, which it shouldn't be aware of.
  • The cart form needs to respect the order item's default form display for quantity

Working on an update.

mglaman’s picture

Status: Needs work » Needs review
FileSize
7.54 KB

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

mglaman’s picture

Updating credits.

mglaman’s picture

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

mglaman’s picture

Status: Needs review » Needs work
+++ b/modules/cart/src/Plugin/views/field/EditQuantity.php
@@ -88,18 +88,27 @@ public function viewsForm(array &$form, FormStateInterface $form_state) {
+      /** @var \Drupal\Core\Entity\Display\EntityFormDisplayInterface $form_display */
+      $form_display = commerce_get_entity_display('commerce_order_item', $order_item->bundle(), 'form');
+      $quantity_component = $form_display->getComponent('quantity');
...
+      if ($quantity_component['settings']['step'] == 1) {
+        $quantity = (int) $quantity;
+      }

Discussed with bojanz. This should be part of the view handler settings, not magical loading of form display.

drugan’s picture

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

mglaman’s picture

The step exposed to a user on the Add to Cart form that is exactly this value should be taken into account. Nothing else.

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

drugan’s picture

Because these are two different settings. One is in the entity display system, another in Views.

The 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, ...).

But for the sake of having a default step of 1, the 95% use case, this is the cleanest solution forward.

I agree on that. Why not to change this line:

$fields['quantity'] = BaseFieldDefinition::create('decimal')

... for this one:

$fields['quantity'] = BaseFieldDefinition::create('integer')

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.

agoradesign’s picture

If 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

drugan’s picture

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

bojanz’s picture

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

bojanz’s picture

Title: Make the quantity field configurable to include HTML properties such as 'Step' property » The quantity "step" must be configurable on the widget level
Assigned: mglaman » bojanz

  • bojanz committed 8becee9 on 8.x-2.x authored by mglaman
    Issue #2794909 by drugan, mglaman, Frank HH-germany, agoradesign,...
bojanz’s picture

Status: Needs work » Fixed
FileSize
22.55 KB

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

Adrian83’s picture

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

zenimagine’s picture

The update causes an error when updating the database

Frank HH-germany’s picture

At #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 !!!

zenimagine’s picture

Thank you it works.

Do you know when the "rc" is planned ?

bojanz’s picture

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

zenimagine’s picture

Yes i have customize field quantity. thank you for the answer

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

drugan’s picture

Issue summary: View changes
rgpublic’s picture

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

drugan’s picture

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

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?

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.

rgpublic’s picture

@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 :-/

bojanz’s picture

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

rgpublic’s picture

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

bojanz’s picture

Yes, we're limited to two decimals until #2892207: Increase the order item quantity scale is fixed.

jeffdavid’s picture

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

drugan’s picture

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

drugan’s picture

Issue summary: View changes

This issue is now fixed in the Commerce Extended Quantity module:

https://www.drupal.org/project/commerce_xquantity

freelylw’s picture

I 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

bojanz’s picture

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

freelylw’s picture

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

bojanz’s picture

The widget has a "Allow decimal quantities" option. Make sure it's disabled.

freelylw’s picture

FileSize
13.13 KB

yes,"Allow decimal quantities" option is disabled. the problem still the same. please see below my screen image. thanks

11

trigdog’s picture

FileSize
26.68 KB

@freelylw Make sure you are on the "Add to Cart" form display. Your screenshot looks like you are on the default form display.

chipway’s picture

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