When creating items in Big Commerce from the API, if sku provided is a string of numbers and if there are leading zeroes, the leading zeroes will be trimmed. For example sku "01234" will become "1234".
<skus>
<sku>01234</sku>
<upc>01234</upc>
<cost_price>17.9800</cost_price>
<inventory_level>1</inventory_level>
<options>
<option>
<product_option_id>4778</product_option_id>
<option_value_id>2113</option_value_id>
</option>
</options>
</skus>
I was wondering if anyone has encountered this before and managed to do some work-around. Please let me know.
Thanks
Related
im probably having this issue due to my lack of my experience with the liquid and the shopify platform in general.
Here's my issue:
In the current theme im working on, when a product is added to card it is always adding the smallest available size. Im not 100 % confident this is the code that is actually doing it but im fairly positive it is.
onclick=" Shopify.addItem('{{ product.variants.first.id}}', 1);
Currently when this code is fired the products smallest size (assuming its the first) is added to the cart.
I tried to take a look at the shopify API documentation for product.variants but it seems the theme or store is not using the latest version since I cant find any references to this first property.
What I would like if for there to be control in terms of product size when the add to cart action is triggered. Instead of adding the smallest size always it can persay add product.variants.{SIZE}.id instead (Not actual code just a guess)
If anyone could point me in the right direction of proper documentation for something like this or if you've had a similar question I would greatly appreciate it!
this is easy :)
yes this is the code sending the product to the cart and this theme don't support product variants. You should add the variants support.
some theory:
Variants is an array.
variants.first is a liquid function for easily take the first element of the array, check the liquid docs for more details.
The important part is, to add an item you need to send the variant id. always is the variant id.
now the magic:
you need to iterate on product.variants, keep on someplace the variant id and finally pass the value to the function.
onclick=" Shopify.addItem('{{ product.variants.first.id}}', 1);
by
onclick=" Shopify.addItem( {{ variant.id }}, 1);
you can use wherever you want, you can use select, or even got for a pure js / ajax solution using the cart API
extra detail the 1 is the qty, you can set it dinamic too.
I don't know your desing, so on psedo-code with multiple buttons you can do:
{% for variant in product.variants %}
<button onclick="Shopify.addItem('{{ variant.id }}', 1)">
{{ variant.title }}
</button>
{% endfor %}
Almost all themes, free or paid, have proper functioning code to handle changes in variations. When a customer selects a variant, via a change in a select element or perhaps the click of a radio button, the existing code should update the currently selected variant properly. Your example of an onclick set to the first variant is probably one the most primitive modes of operation, and as you see, less than satisfactory.
As a beginner, your best bet is to download the Debut theme from Shopify and study the basics of how variant selection work from the position of working code. Only then could you hope to be able to mod your own themes.
I recently upgraded from Solr 6.6 to 7.1 and cannot query Double fields for any value anymore using
q: test_d:*
(zero results although the field is set). However,
q: test_d:[* TO *]
works. This seems to affect all numeric field types (tested for Integers, Floats and Doubles). For String, Text, Boolean fields the single asterisk works just fine like before.
Is it possbile to reconfigure Solr to have the old behavior or do I have to rewrite all queries and introduce a switch for numeric field types? Until now, no field value type differentiation was needed (which is good!).
Minimal Working Example
Use the example-DIH-solr core supplied with the Solr distributable, push the document
{"id":"foo","test_b":true,"test_i":42,"test_f":42.0,"test_d":42.0}
and use
q: test_b:*
q: test_d:*
q: test_i:*
q: test_f:*
Only the query for the Boolean field will yield a result.
Double field definition changed. To restore the old behaviour you can use / change this:
<dynamicField name="*_d" type="double" indexed="true" stored="true"/>
and add back the double field type definition to the schema:
<fieldType name="double" class="solr.TrieDoubleField" precisionStep="0" positionIncrementGap="0"/>
This worked in the past but most likely per accident - see https://issues.apache.org/jira/browse/SOLR-11746 for a bug report / solr issue to track this.
Shopify is automatically adding some sort of quantity adjusters on my cart page.
I can't find anywhere in the template code that these are getting added.
Anyone know how to remove these up and down arrows?
search your template for input elements, with the type = "number" and some name with the word quantity in them. That would be what you change to input type="text" to get rid of the numbers.
The data that I'm getting only contains the SKU numbers. I am trying to figure out how I can link these SKU numbers to the product variants in Shopify without the actual product id number.
Example data:
<Inventory ItemNumber="100B3001-B-01">
<ItemStatus Status="Avail" Quantity="0" />
</Inventory>
<Inventory ItemNumber="100B3001-B-02">
<ItemStatus Status="Avail" Quantity="0" />
</Inventory>
<Inventory ItemNumber="100B3001-B-03">
<ItemStatus Status="Avail" Quantity="-1" />
<ItemStatus Status="Alloc" Quantity="1" />
</Inventory>
<Inventory ItemNumber="100B3001-B-04">
<ItemStatus Status="Avail" Quantity="-1" />
<ItemStatus Status="Alloc" Quantity="1" />
</Inventory>
Here's a delightful, condescending discussion from Shopify employees in 2011 asking why you can't just store the Shopify ID everywhere. The "stock-keeping unit" is a universal systems integration point and, in every system I've seen, each SKU uniquely maps to a product because words have meaning, but apparently not at Shopify.
Three years later, you seem to have two options.
One is to create a Fulfillment Service and provide a URL where Shopify will call you asking for stock levels on a SKU; this is probably the simplest solution, provided you have a Web server sitting somewhere where you can expose such a callback.
The second is to periodically page through all of the Products and store a mapping of the Shopify ID to a SKU somewhere, consulting your map when you need to do an update. Because most of our integrations are cron jobs and I'd like to keep them that way, I periodically ask for the products that have changed since the last run, and then update my mapping.
As David Lazar points out in his comment, the ability to find a product based on its SKU is not currently supported in the Shopify API.
EDIT: This is an unreliable option that I once used as a last resort. I wouldn't recommend using this but I will leave it here in case as someone may find it helpful.
You can use this API endpoint:
/admin/products/search.json?query=sku:abc123
I have only used it in the browser though, and I can't find any documentation for it. And it may stop working at any time.
You can use
*.myshopify.com/search?view=json&q=sku:SKUID
Graph query on Shopify works for me:
I've been looking for a solution to this problem for some time.
I'm using CF9's cfpdf to populate pdf fields.
One field is a "title" field and one particular title must be
followed by a registered trade mark symbol.
The registered trade mark symbol must be superscript.
Does anyone have any possible solutions?
Thanks so much for your time.
Code snippet:
<cfpdfform
action="populate"
source="#var.workFiles##var.ID#.pdf"
destination="#var.workFiles##var.ID#.pdf" overwrite = "true">
<!--this is the value that could contain the registered trademark -->
<cfpdfformparam name="title" value="#trim(var.title)#">
There might be a shortcut, but try something like this:
<cfset symbol = charsetEncode(binaryDecode("c2ae", "hex"), "utf-8")>
...
<cfpdfformparam name="title" value="XYZ Corporation#symbol#">
To expand on Leigh's answers, I was also having issues with character encoding, specifically the £ sign. which was being shown as A£.
I resolved the issue the same way, by looking for the hexicecimal representation of the £ symbol at http://www.utf8-chartable.de/ (c2a3 for the £ sign) and using the charsetEncode(binaryDecode("c2a3", "hex"), "utf-8") part from Leigh's answer with the correct hex code.