Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shipping Method Selection Conflict with Local Pickup Block #399

Open
1 of 2 tasks
Tracked by #47947
mikejolley opened this issue Jan 30, 2023 · 1 comment
Open
1 of 2 tasks
Tracked by #47947

Shipping Method Selection Conflict with Local Pickup Block #399

mikejolley opened this issue Jan 30, 2023 · 1 comment
Labels
priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. type: bug The issue is a confirmed bug.

Comments

@mikejolley
Copy link
Contributor

Describe the bug

WooCommerce Blocks has a dedicated block for selecting Local Pickup during checkout. There is a dedicated P2 about this functionality here for reference.

Due to the way subscriptions splits carts into multiple carts to handle recurring billing, there is a conflict when it comes to shipping method selection. This screenshot shows the behaviour you see:

Screenshot 2023-01-30 at 11 28 34

To Reproduce

  1. Go to Settings > Shipping > Local Pickup. Enable it and create some pickup locations.
  2. Ensure another shipping method, such as a flat rate, is also enabled.
  3. Add both subscription and regular products to your cart.
  4. Go to checkout.
  5. Select Local Pickup.
  6. See how the rates are not updated for recurring carts (see above screenshot).

Expected behavior

When you select Local Pickup, the shipping method for the recurring carts should also switch to Local Pickup.

Actual behavior

When you select Local Pickup, the shipping method for the recurring carts remains as default and cannot be changed.

Product impact

  • Does this issue affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
  • Does this issue affect WooCommerce Payments? yes/no/tbc, add issue ref

Additional context

A potential/partial solution to keep recurring and regular carts in sync was created here #264 however this is no longer applicable because we're not passing a null package ID. The action would receive package ID 0 (when local pickup is used, only one package is supported).

Therefore the logic in subscriptions needs to be either:

  1. A local pickup rate ID was returned, so set all recurring carts to local pickup.

or

  1. Create (via slot fills) an interface to select shipping methods (or pickup) for each recurring package separately.

cc @senadir

@mikejolley mikejolley added the type: bug The issue is a confirmed bug. label Jan 30, 2023
@opr
Copy link
Contributor

opr commented Mar 3, 2023

Hey folks, I have pushed some changes on add/blocks-local-pickup which can be used to kick start the work on integrating with WC blocks.

Please note the PR in WC blocks to add LocalPickupSelect is still under review, so no guarantee it will be merged yet.

To summarise the changes so far on that branch:

  • ef832a0 - this commit introduces a new component, PickupControl which is used to render the pickup options for a package. It is a wrapper for LocalPickupSelect from WC Blocks which allows you to add your own class name and styling for anything rendered in this slot/fill.
  • 70923e9 - adds SubscriptionsPickupRecurringPackages which is an analogue to SubscriptionsRecurringPackages (you may want to rename the SubscriptionsRecurringPackages component in index.js to make it more obvious that one refers to shipping and one refers to local pickup) - it renders a PickupControl, described above.
  • dd1b652 - prevents collectable rates showing up in the regular recurring shipping selector.
  • a56a514 - ensures the SubscriptionsPickupRecurringPackages is rendered in the WC Blocks local pickup section.

Let me know if this is a good approach, or if you need help with anything, I'll be happy to assist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. type: bug The issue is a confirmed bug.
Projects
None yet
Development

No branches or pull requests

3 participants