From #2761041: [META] Commerce Shipping 8.x:
Each remote API has this concept, though its naming varies.
This plugin type was initially called “box”, which I liked. However, turns out that no API uses the “box” naming, and not every package type is a box (envelopes, cylinders, tubes are technically not boxes). So we chose “package type”, which is how Fedex, UPS, eBay, Postmaster refer to it. Shipwire also has something similar (packaging type).
I’m not married to the package type naming. USPS uses “container” which felt too generic, Postmen uses “box type”.
Ryan also suggested “packaging”, which sounded a bit too verby to my non-native ears, but I’m open to other opinions.
So, shipping methods define their package types in YAML. You can see a sample list here. There is also a need for users to be able to define their own custom package types. For that we’d need a config entity that uses a plugin deriver to expose that data as plugins (like menu links in core). This too can be done as a followup.
Each shipping method instance has a default package_type setting that’s used by the default Packer.
I'll see if I can reuse the box plugin type code from https://github.com/smmccabe/commerce_shipping
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | interdiff2.txt | 7.97 KB | bojanz |
| #6 | interdiff.txt | 1012 bytes | bojanz |
| #6 | 2826050-6-package-types.patch | 20.7 KB | bojanz |
| #3 | 2826050-3-package-types.patch | 13.04 KB | bojanz |
Comments
Comment #2
bojanz commentedTurns out that the box code from https://github.com/smmccabe/commerce_shipping doesn't have units on the dimension values, which makes them not very useful.
I'll clean up and post the physical module port to drupal.org, then recreate the package types to rely on the units provided by it.
Comment #3
bojanz commentedPhysical has a very decent port now. Will tag RC1 tomorrow.
Time to get back to Shipping. Here are the package types.
Comment #5
bojanz commentedComment #6
bojanz commentedHere's the final patch, along with the interdiffs of the two commits I squashed into it.
I was also asked how I'd do a package-type-per-store.
We need to expose those package types through the PackageTypeManager, but avoid having them show up in the cached plugin definitions (10k stores => 10k new cached definitions, it would blow up). So that requires overriding getDefinitions() and/or getDefinition() and wrapping the parent call.
I'd set a custom ID in the packer plugin: $shipment->package_type = 'mysite_custom_' . $store_id;
Then I'd override PackageTypeManager::getDefinition(), add an if for the 'mysite_custom_' prefix, load the store, construct a definition for the store package type. This way the plugin technically exists, but we avoid the getDefinitions() cache. Exposing each store's package type as a plugin would explode the cached definition size when there's too many stores.
Comment #7
googletorp commentedThis looks good, great job Bojanz.
Comment #9
bojanz commentedCommitted, thanks everyone.