Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Hello,
The idea is to get checkout panes exportable, so that a feature can contain settings about checkout panes (page in which one pane appears, weight, collapse settings).
I will provide a patch soon.
Regards,
David
Comment | File | Size | Author |
---|---|---|---|
#33 | commerce_features-n1973602-33-interdiff.txt | 1.94 KB | DamienMcKenna |
#33 | commerce_features-n1973602-33.patch | 6.81 KB | DamienMcKenna |
Comments
Comment #1
David Stosik CreditAttribution: David Stosik commentedSoon meaning immediately. ^^
I used the "faux-exportable" pattern, as it felt like I would not be able to use the normal way.
That means that in-feature checkout panes are written to database when the feature is enabled or reverted.
Any comment or advice is welcome.
This patch was developed by Alethia INC. and sponsored by The Japan Association for Language Teaching (JALT).
Comment #2
David Stosik CreditAttribution: David Stosik commentedPatch still works on 1.0-rc1. :)
Thanks for your help.
Comment #3
dysrama CreditAttribution: dysrama commentedHi
This sounds very good indeed, and just what I need, but after applying the patch I see no changes in features? No new area or anything.
A guideline to steps to take to make this patch work would be appreciated.
Comment #4
sarvab CreditAttribution: sarvab commentedThe latest version of features requires the commerce_checkout_panes call here to accurately reflect the panes saved to the DB by resetting the static cache. I've submitted a patch over at commerce and am updating the patch here to make this work with features 2.0
The only difference is:
The issue + patch required in commerce https://drupal.org/node/2137553
Comment #5
bojanz CreditAttribution: bojanz commentedAlso, commerce_checkout_panes() returns both the panes from the database and the panes that are already in code (commerce_checkout_pane_info). We need only the db ones, so that will require writing a custom function.
Comment #6
logaritmisk CreditAttribution: logaritmisk commentedDidn't know about this module and this patch so I made my own features implementation, but now I have tried to merge my code with this patch and it seems to work. Install/revert works like a charm and I have tested against Commerce 1.8 and 1.9.
Comment #7
sarvab CreditAttribution: sarvab commentedHere is a rebuild of the latest patch that includes the new commerce_checkout_panes_reset call to ensure up-to-date panes on revert.
Also the hooks hook_features_enable_feature and hook_features_disable_feature were added back in too.
Comment #8
discipolo CreditAttribution: discipolo commentedfor some reason the patch from #7 didnt apply all lines for me. so i rebuilt it again
Comment #9
lucastockmann CreditAttribution: lucastockmann commentedI successfully tested the patch from #8. (With latest dev)
U have to clear the cache, after that everything works as expected.
Use:
drush fe [feature_name_here] %commerce_checkout_pane%:%%
to export your settings.Comment #10
joelpittetSeems to do the trick. Marking as RTBC.
I exported most of my checkout panes to code. Made some changes and updated the feature. And deployed it successfully to staging.
Maybe a follow-up would be to save some of their config forms too?
Comment #11
mqannehwith patch #4
enabling the features generates a PDO exception
duplicate primary key
I checked the table and found that the checkout panes settings is inserted, so the problem is that the feature is trying to insert the settings 2 times
with patch #8
this problem was solved
Comment #12
dmsmidt+1 for getting #8 in, works like a charm.
Comment #13
joelpittetI've reverted this patch as it doesn't seem to update the features well when changes are made. Feel free to mark it as RTBC if you feel different.
Comment #14
BR0kENHere is the working patch, used on my project :)
P.S. We need to enable automated testing for this project.
Comment #15
BR0kENSorry, I've accidentally remove necessary code. Brought it back.
Comment #16
m1r1k CreditAttribution: m1r1k at Propeople (now part of FFW) for Propeople (now part of FFW) commentedYou have removed two manual dependencies:
+ $export['dependencies']['features'] = 'features';
+ $export['dependencies']['commerce_checkout'] = 'commerce_checkout';
Features are clever enough to add them selves as a dependency, when I am not sure about commerce_checkout.
PHP_EOL will use "\r\n" if we will update feature on windows - do we need this modification?
Comment #17
BR0kENfeatures
as dependency for feature.commerce_checkout
will be added automatically.Comment #18
BR0kENComment #19
m1r1k CreditAttribution: m1r1k at Propeople (now part of FFW) for Propeople (now part of FFW) commentedComment #20
DamienMcKenna+1, thanks for all of the effort to make this work!
Comment #21
DamienMcKennaComment #22
rooby CreditAttribution: rooby commentedI think that using the pane title is problematic because they are more likely to be less useful in an administration situation. For example the title may be empty or multiple panes may have the same title.
As an example the Commerce Views Pane module will give an empty title if the view has no title.
Instead I think we should use the pane name like this.
Comment #23
BR0kENAgree with you, @rooby, but want to use title anyway.
Comment #24
XanoDocblocks must be added for these constants to explain what they are for.
Nice solution.
commerce_checkout
must be added as well.This prevents us from exporting any chckout pane configuration stored by other modules, since
commerce_checkout_panes()
runs all data (even that from the DB) throughhook_commerce_checkout_pane_info_alter()
. Is this really what we want?Can't we do this by simply removing the override records from the DB?
Comment #25
ruloweb CreditAttribution: ruloweb commentedHi all,
just updated the patch #23 to work on last dev, which allows payment export as well.
Thanks!
Comment #26
joelpittet@ruloweb does it address the feedback in #24? Could you provide an interdiff?
Comment #27
BR0kEN@joelpittet, no, it doesn't.
@Xano,
1. I don't understand why constants should be documented when they are have understandable names.
3. Agree, this is potential issue.
4. Yep. Any alterations should be in code.
5. This should be as is.
P.S. Damn, let's have this merged! Half of year we're talking about nothing and do nothing. I'm very disappointed in Drupal community because it ready to do something when maintainer interested in this.
Comment #28
Ronino CreditAttribution: Ronino as a volunteer commented#27 works for me, thanks!
Comment #29
DamienMcKennaI'm hitting a problem with #27 this when it's used in an installation profile, the site ends running commerce_checkout_pane_save() on a commerce_fieldgroup_pane that's already in the database. More details shortly.
Comment #30
DamienMcKennaSo the problem is that commerce_checkout_panes_features_revert() is being triggered twice on the same process execution - the first time via hook_features_rebuild(), the second via hook_features_rebuild().
Comment #31
DamienMcKennaBoth hook_features_rebuild() and hook_features_rebuild() are triggered by features_modules_enabled(), so it's something in this patch that's misbehaving.
Comment #32
DamienMcKennaSo it turns out that there was no need to add hook_features_enable_feature().
Comment #33
DamienMcKennaThis changes all occurrences of $module_name with the shorter $module, for consistency sake.
Comment #34
DamienMcKennaComment #35
geek-merlinPatch #33 applies well and does what it announces here.
Comment #36
mglaman#33 looks good. I'd like a few other issue subscribers to test, then will commit.
Comment #37
mglamanTagging for sprint, see if some AcroMedia contributors can give it a run.
Comment #38
pontus.froden CreditAttribution: pontus.froden as a volunteer commentedConfirm patch #33 works.
All on checkout panes from dev site was transferred to staging without any problem.
Changed the order on dev some more times and everything was transferred to staging when pushed.
Votes up for commit :)
Comment #40
mglamanThanks everyone :) Committed!