Closed (fixed)
Project:
Commerce Features
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
12 Jan 2012 at 15:05 UTC
Updated:
4 Aug 2015 at 21:44 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
pcambraFeatures integration for Shipping is in the scope of this module, could you please specify what components you can't export?
Comment #2
Everett Zufelt commentedI am using commerce_flat_rate, the services that I have created for this shipping method, and the associated rules, do not appear to be exportable.
Comment #3
hazaShould we change the title to "Commerce flat rate exportable with commerce features" ? or something like that ?
here is a patch to allow commerce_flat_rate (and only that) to be exported in commerce_features.
Comment #4
hazaForgot to reset the shippings_services when we rebuild the features (the methods don't show unless we clear cache)
Comment #5
pcambraI'd rather see a generic shipping export instead of having a file per service.
Comment #6
bojanz commentedThis is #4 + the same fix I added to other files in #1572330: Don't cause excessive cache and menu rebuilds.
I will reroll to address feedback soon.
Comment #7
hazaAnother try. Changed the default hooks used, from 'commerce_flat_rate_default_services' to 'commerce_shipping_service' and also add a key in the export that is generated to be able to identity this export as a features one. (that will help in an other path for commerce_shipping to not throw some code if we are importing a features - but not sure this is a correct approach)
Comment #8
glennpratt commentedThis is just a re-roll of #6 because I couldn't get it to apply to rc1 or dev. Works fine.
I couldn't get #7 to show my shipping rates for export in a quick test, sorry I don't have any insight - it easily could have been my mistake.
Comment #9
poniesApplied #8 to dev and tried to export two flat rates. The components weren't exported. I'm using features 2.x.
Comment #10
pcambraComment #11
fearlsgroove commentedIt'd be a great start to supporting config management shipping generally if this approach would track all shipping method rules as well.
Comment #12
guguss commentedDuplicate.
Comment #13
guguss commentedWorks fine.
Ready to be Committed !
Comment #14
nadavoid commentedI can confirm that #8 works for me too.
Comment #15
introbay commented#8 works for me too.
Comment #16
sharpbites commentedAny plans on making commerce shipping rules components exportable?
Comment #17
roland.molnar commentedI have tried the patch #8 but ran into a problem when using in conjunction with commerce_free_shipping.
By default, it exports the rate's callbacks like this:
But if I enable commerce_free_shipping module and turn on free shipping calculation for the flat rate service, and export it using features, the 'rate' callback will change from 'commerce_flat_rate_service_rate_order' to 'commerce_free_shipping_rate_callback'.
Installing the feature module with this setup will cause a infinite loop, calling commerce_free_shipping_rate_callback( ) on the /checkout page.
I am not sure if the problem is with the exporter or the module commerce_free_shipping.
Comment #18
paulihuhtiniemi commentedI can export flat rate service initially, but after that I can't update that service anymore. For example, changing base rate via UI is impossible.
Comment #19
Anonymous (not verified) commentedExporting the flat rate works, but features doesn't seem to recognize when the config has changed. If you recreate the feature anyway it does reflect the changes though (e.a. it exports correctly).
Also, reverting needs to happen through drush with the --force argument because features doesn't recognize the config has changed.
Comment #20
carletexThe name of the default hook and the function mismatched. Also, the rules componentes were being exported for unexisting shipping services.
Comment #21
mqannehpatch #8 worked for me
Comment #22
grisendo commentedPatch #8 doesn't work correctly as #17 #18 #19 report. It doesn't work for me also.
#20 explains why, and proposes a new patch, which works for me.
So, reverting back to "Needs review" and let's go all to test the patch at #20
Comment #23
Anonymous (not verified) commentedPatch #20 did the job for me, thanks guys..
Comment #24
meecect commentedLooks good, but is it possible to include the flat rate description or title in the exportable in the features display instead of the display name (or in addition to the display name) ? Right now I have a bunch of shipping rates based on location, but they all have the same display name 'standard shipping', and then I have a bunch of similar rules for 'express shipping'. In the feature creation page, all these rules look the same.
I think this is a common use case, because the consumer just wants to see 'standard shipping' or 'express shipping', but the rules may be more complicated and the developer probably should see the rate 'title' on the features page. I don't necessarily want the shipping rate name shown to the user to be 'standard shipping to AFO/APO', 'standard shipping to continental US, except Virginia', etc.
Comment #25
meecect commentedIt looks like the service name is set on line 32 of commerce_flat_rate_services.features.inc
changing it to:
fixes it for me.
There are a few options:
$service['title'] => title in admin interface
$service['name'] => machine name
$service['display_title'] => user-facing name
It seems to me like $service['title'] is the appropriate one to use here, since the feature creation page is an admin-centric page and should use the admin-centric name.
Comment #26
a.milkovskyI can confirm that #20 works. Thanks! +1 for RTBC
Comment #28
mglamanThanks everyone! It's in.