Skip to content

7.x#195

Draft
nfourtythree wants to merge 64 commits into6.xfrom
7.x
Draft

7.x#195
nfourtythree wants to merge 64 commits into6.xfrom
7.x

Conversation

@nfourtythree
Copy link
Contributor

Description

New version of the plugin supporting that latest methodology of integrating with Shopify's custom app system.

Other improvements

  • Customisable base URL for webhooks
  • Native fields for viewing Shopify data on edit product screens
  • Variant data being represented as a model (rather than an array)
  • Meta fields being returned on variants

@nfourtythree nfourtythree self-assigned this Jan 19, 2026
AugustMiller and others added 30 commits February 18, 2026 23:33
This is a bit of housekeeping, and a bit of soul-searching. I had a heck of a time reasoning about when and why Shopify was producing errors, so I figured it was worth expressing the variety of message structures that we may get back from the API.
- Network/connection or "client" errors, in Guzzle-land (not specific to Shopify) are caught and re-thrown with a generic message.
- API consumers (things that call `Api::query()` can basically catch a single kind of error and decide what to do
- Those queries no longer have to worry about unpacking and handling various response structures (like `userErrors`), or the root element in each response named the same as the original query or procedure.
- We now throw on any session issue before querying, rather than relying on individual consumers.
- We no longer throw on “empty” or missing `data` keys in responses (they're just returned verbatim, and it's up to the consumer to decide whether that’s “bad”)
- If you really need to perform a low-level, unopinionated query, use `Api::getGqlClient()` directly.
- Webhook setup and messaging has been improved
  - Filter webhooks by environment/URI at the API level, rather than in the controller
  - Simplified how we detect and repair "missing" webhook topic subscriptions
  - We now use a template and natural form requests and success/failure response handlers for the webhook management view
  - Moved away from deprecated `endpoint` and `callbackUrl` fields when creating and fetching webhooks, in favor of the plain `uri` field
- Bulk operation handling is no longer concerned with API response structure, errors, etc. (per above)
  - For stores that use bulk GQL *mutations*, we now look for specifically bulk *query* operations (one mutation and one query can run in parallel)
- ?!?!
…ooks

This was made easier with the introduction of GIDs (`admin_graphql_api_id`) in most/all webhooks.
Howdy, stranger! If you're reading this and would like to start a support group for Shopify developers, let me know… they have it pretty rough.
… the fields (i.e. `MetaField`s) retrieved from the API.

Of course, this is sort of a mess to parse (programmatically) given the number of `node` and `edges` keys, as well as numerically-indexed field names.
My idea was that this could be triggered from other places… so the event class name is generic; the event name itself is specific to products, though!
[ci skip]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants