Or if you have plenty, bulk actions   ... View more

Not possible as far as I am aware of. Though they could have returned a more meaningful response status than 200 OK when you're trying to do something that's not supported. ... View more

Most likely because you have it published on your app channel. Check the product where you are seeing that onlineStoreUrl is null and you will probably find that it is published for your app name that you are using for Storefront API access.   You would need to unpublish it for your app channel and only have it in unpublished state for the Online Store like so ... View more

What is the problem you are having?   Pasting in a bunch of PHP code (which originally included your access token to your Admin) is not the best way to ask a question or state a problem Have you checked you are able to POST a new product via a client such as Postman or Insomnia to make sure your API keys, scopes etc. are in good order and eliminate issues there If #2 works fine, then the issue is in your PHP code and unless someone here is proficient in PHP (mostly PHP questions go unanswered) then I advise you to ask on a more general forum such as StackOverflow Best wishes! ... View more

@sabaraouf wrote: Can you please explain why does this query return unpublished products? What is the URL you are querying? /admin/api/graphql.json  or  /api/graphql   ... View more

When using Storefront API you always only get published resources. This is for Storefront API (but also works for Admin) { collectionByHandle(handle: "foo-collection") { products(first: 5) { edges { node { title } } } } } Will only return products in that collection that are published i.e. to the Online Store channel and publication date is less than now. Not sure what you are trying to accomplish, but if it is anything to do with fetching data for a storefront to show, then I wouldn't advise you to use the Admin API at all. Even if, you will run into the issue of access denied etc. which all boils down to publications_read and publications_write scopes not being available (the entire publications stuff seems in a very wonky state API wise) and AFAIK Shopify haven't voiced any statement yet. The most you can do is check whether the products are published on the current publication, but since that will be tied to your app's channel, it's sort of useless for most common use cases (below query is for GraphQL Admin API) { collectionByHandle(handle: "foo-collection") { products(first: 5) { edges { node { title publishedOnCurrentPublication } } } } } ... View more

If you mean the images found in Settings > Files then yep, while that's the place to add them and use for themes, it's not accessible via any API. I did mention you'll run in to snags building out a store with API only 🙂   So you're essentially on your own here and would need to use one of the cloud store providers + CDN.   Edit - plus the joy of doing all the image optimisation, resizing etc. ... View more

The first query you are running is for GraphQL Admin API - Storefront API does not have a query filter of published_status. For Storefront API, it is either published to that channel and thus queryable or it isn't and thus you won't be able to query it no matter what. Do not confuse Admin APIs and Storefront API - the GraphQL schema is different. ... View more

Nope, not missing anything. The discrepancies between requested and actual cost are unavoidable. So as you already touched upon, the best course of action is to optimise your queries. You can use request header  X-GraphQL-Cost-Include-Fields set to true to get more granular insight over how cost is distributed over your query and fields.   Generally, I prefer using REST API when going deep in to a resource hierarchy (e.g. order response returns everything and your mother in law) even though it's wasteful - it's simply affordable. GraphQL for anything that can't be done in REST API or when not querying beyond 1 connection. ... View more

@rusbaraja You can't use a percentage based compare price difference and thus there is no workaround using conditions because unless Shopify add this condition type, we're out of luck.   Best wishes! ... View more

Hi,   Using REST Admin API, not aware of any way though I may not be aware of it. The crux here is that the query filter isn't available on the orders endpoint as it is through the Admin UI so you cannot do    GET /admin/orders?query=&reference_location_id=<LOCATION_ID>   Using GraphQL Admin API you can (though by golly, that's one expensive query)   { orders(first:5, query:"reference_location_id:<LOCATION_ID>", reverse: true) { edges { cursor node { id name fulfillments(first: 10) { location { name } fulfillmentLineItems(first: 50) { edges { node { lineItem { sku } } } } } } } } } It will only return orders where one of the fulfilment locations is equal to the reference_location_id but the fulfillments will still have both if they were split fulfillments so you'd need to beware of that.   Hope this helps! ... View more

Speaking of "solutions" I find the tutorials and samples for React + node apps great but they are introductory and outdated (to some extent).   If you are really curious to see where Shopify are going internally, start gitstalking their devs 😂 Some awesome stuff happening in the sources if you peek in to work done by Chris Sauvé aka lemonmade, Mallory Allen aka TheMallen, Thomas Kelly aka t-kelly to name a few (shout out to y'all if any happen to read, admire your works and efforts). You will stumble across gems like perfect-app, quilt, theme-scripts, web-foundation, and even more up to date examples such as the React app from Unite '18 or a spin on the reviews app written in React. Browsing through the shopify scope on npm, you will find even more published but unreleased packages of interest e.g. sewing-kit. Whether you want to dig around that deep and use stuff that may or may not be for public but definitely isn't supported or documented is up to you, but it shows you how Shopify devs work, where they're heading and it's just plain good learning.   Best wishes! ... View more

Depends what you are testing for.   When testing your React components, Jest and snapshot testing are perfectly fine. You do not need to test these in the app provider context and if you do, you can always mock the provider.   When testing app state you definitely want to use mocks. This does depend on your React app architecture, but I'll assume you aren't building stateful components and the state is mutated via React context, Redux, MobX or whichever you prefer. Much of the state may of course depend on data sources such as the GraphQL API - again, mocks! That is one of the foremost advantages of GraphQL in that it lends itself so nicely to mocking. No need to touch real endpoints ever as long as you have the latest schema and are aware of some snags. Same goes for REST API though that will require hand-crafted mocks for lack of any API spec such as OAS, RAML et al.   If you have your state mutators, say reducers, further abstracted to use a service layer, then I'd test the service layer (which does the actual API calls) using Jest or Ava (I prefer Ava for that, but it really is just a matter of preference which varies greatly among us JS hipsters). And again, you distinguish between unit tests and integration tests. I mostly write unit tests with a lot of mocking simply because running proper integration tests against Shopify APIs is nigh to impossible due to the fact you cannot remotely set most of the store settings that will affect behaviour. Major PITA!   Finally we arrive at e2e tests where you can take advantage of test runners such as Cypress. Again, I would avoid doing these integration tests against a real installed instance of your app. It is more likely you will want these e2e tests to be run upon each PR merge to trunk. Once you do tag a release and initiate deployment (which in itself is a terrible automation experience on Shopify for apps) you would run the same e2e tests on your dev store with your app. Runners such as Cypress will allow you to login to your dev store but it is another PITA setting all that up and I've had transient issues where it would fail (hello too many logins and Captcha) so you must factor those nu(is)ances in.   Now as for the classical node + React: why do they run on separate ports? I understand that your express server may be on one port and your webpack dev server (or whatever you're using) might be on another, but do take note of "dev server" so this is really only for local dev IMO and even there it's not really a smart choice other than being a quick and dirty convenience approach. If you still insist on that, setup a reverse proxy on your express. What I prefer and what I do is have a static middleware to serve my build destination folder - so while I can serve my React UI with a dev server if need be, I typically just have my build pipeline transpile to the dest, and with static middleware and HMR setup serve it via koa (another preference of mine and one you might also wish to look in to as Shopify are also moving away from express judging by their more recent github projects and activity).   Hope some of this made sense :) ... View more

In regards to your last point, is this going to be addressed by the developer? Or do you mean simply sit tight and wait until it's eventually addressed? Well the original question was posted 3 weeks ago. No response from Shopify staff. The question/answer I link to in my first reply regarding the same issue was posted 6 weeks ago. No response from Shopify staff. The issue of inventory levels not being location aware in Liquid or Storefront API has been raised a few times throughout late 2018 since introduction of multi-location and Shopify have responded with "currently not possible".   Not taking a stab at Shopify or Shopify staff here. This is how it is anywhere else and I do feel Shopify is doing a grand job a cut above their competitors.   So my view is - support staff cannot address this issue and to be fair it's not within the scope of their duties / expectations. The more tech savvy staff do frequent the forums and answer / provide feedback what's up & coming or acknowledge shortcomings that they pass on to developers. Developers also frequent the forums but much less so - which is good, otherwise they wouldn't be developing :-D Regarding this specific issue / feature, we must remember that multi-location was one of the biggest changes introduced to the Shopify platform in recent years and it was only made public to all merchants around September 2018 IIRC? In other words, this is still hot off the press and will be improving over time. What timeframe that is... hard to tell... looking around the forums even way back to 2013, some feature requests have been hanging around ever since.   So yes, sit tight and wait or take matters in your own hands and get the job done. As with anything else I suppose. ... View more

Hello,   Most definitely orders/updated event. I have just tested it quickly to make sure and the webhook request is sent when either email or shipping address are changed.   How are you currently testing your webhook handler? I suggest you start with a mock handler service first - requestcatcher or requestbin for instance.   Best wishes! ... View more

It should be so simple yet it isn't because it cannot be done without an app or private app.   Context - multi-location was introduced but a few gaps were left. Most notably the ability to access inventory levels per location through Liquid or Storefront API. As you all are already aware, you only get the aggregate inventory.   One approach would be to use an external inventory management service, pay a handsome monthly fee, forgo all the Shopify managed inventory features and pray the 3rd party inventory system can integrate real-time stock status in your storefront without costing you an arm and a leg.   Another approach would be to seek cheaper apps that aren't full inventory management systems, but can do what you need as I am sure you aren't the first who'd like this sort of feature. I don't know of such apps and don't use any so I cannot judge or give recommendations in this regard.   Alternatively, you can go the custom route and setup webhook notifications for the inventory_levels/update (or orders/create, products/update as either are triggered when an order is placed and either can be used to get current inventory of line items > inventory items > inventory levels @ locations). You'd handle the webhook by updating the product metafield with it's "current" inventory levels per location. Once in the product's metafield, you can easily access that using vanilla Liquid to display in your storefront. In fact, Shopify even mentions this much here (though do not mention how that metafield info is kept up to date).   Yet another variation would be to use periodic polling of inventory levels to do the same as above albeit without webhooks. Webhooks aren't guaranteed to arrive or arrive in order. Polling on the other hand is very wasteful. SUmmary - it depends and requires careful consideration. Ultimately, the "inventory levels per location" for storefront display purposes using the approach I suggest here would not be absolutely real-time and would not necessarily be absolutely accurate i.e. they'd merely be informative rather than definitive.   And last but not least, you may all decide to wait for an official reply by a Shopify developer which is fair enough by me.   Best wishes! ... View more

Technically it is possible. But if you're going to use that from a browser client, you may as well share your admin credentials here or on Facebook.   The Shopify Admin APIs are not meant to be used fro within browser clients because that poses a massive security risk whereby you are sharing the Admin API key and password openly in a script that can easily be viewed by anyone using your site or web app. Even if you protect your app or site with authentication, it is still at high risk of being compromised.   So while yes, it is technically possible to do it - I won't even go on to show how because this is an absolute no-go use case.   Instead, please have a look at how to create a Shopify app or private app if you need some custom app functionality for creating products in your / customers' store.   Best wishes! ... View more

Hello!   Unfortunately the greeting above will be the only good news - filtering by order_notes (as they're called in REST API) or customAttributes (as they're called in GraphQL API) isn't possible no matter how you slice and dice the APIs. ... View more

Speaking of commercial theme support - I believe it would be time to chastise theme vendors who do not support their themes. The amount of questions here, not only yours, concerning commercial themes is alarmingly high and I firmly believe it is not a cost to be borne by the community. It sort of ticks me off that unsuspecting customers buy a product, in this case a theme, only to get ignored or served sub-standardly by the vendor who raked in the cash and let others do their support and fixes. Not cool and I'd call out that vendor in a review! ... View more

I'd be careful consulting the Bootstrap 4.x documentation. Your theme uses Bootstrap 3.1.1 and there were quite a few changes between 3.x and 4.x.   But the basic concepts of a grid system remain. The first and foremost bit that needs changing is the row that holds your logo. From the screenshot that I attached in my first reply showing a snippet from the Ella theme where the logo is contained, you will notice this structure   <div class="row"> <h1 class="header-logo col-xs-12 col-sm-4">...</h1> <div class="header-panel-bottom col-xs-12 col-sm-8">...</div> </div> Now you could change that to be   <div class="row"> <h1 class="header-logo col-xs-12 col-sm-2 col-sm-offset-5">...</h1> <div class="header-panel-bottom col-xs-12 col-sm-5">...</div> </div> That is most likely in a Liquid file called header.liquid as @Ninthony  already mentioned.   That would still not pull your logo to centre because the header-logo class overrides the grid's offset class so you'd need to edit your Assets / theme-styles.css.liquid and find this bit of code (it might be a little different because there may be variables in it, but the class should be called .header-logo)   .header-logo { margin: 15px 0 22px; } And change that for (substitute the variables if there were any instead of the values below) but without the margin-left so we allow the grid's margin to work   .header-logo { margin-top: 15px; margin-right: 0px; margin-bottom: 22px; } That will centre your logo but now leaves very little room to breathe for the content to the right (cart, user etc) so upon resizing before it jumps to mobile breakpoint, you will get some "stacking". I am pretty sure that's not what you'd like but the solution to that... well... get a coder or learn HTML, CSS, Bootstrap ;-)   Best wishes! ... View more