Post /user/me api now manage only one address as default shipping and one address as default billing.

the address is entered only if it has the flag default_shipping or default_billing is set to true, if the flags are absent, the address is not insert.

I have added to UserController.php this code:

if($updatedAdress["default_billing"] == false && $updatedAdress["default_shipping"] == false) { $bAddress = Mage::getModel("customer/address"); $updatedAdress["parent_id"] = $customer->getId(); $bAddress->setData($updatedAdress)->save(); }

Insert please in next version

Thanks

As written in doc/VueStorefrontBridge API specs.md:3307, response body must contain extension_attributes field which is not returned for now by the bridge.

That creates a bug when trying to see a single order from customer history: [Vue warn]: Error in render: "TypeError: this.order.extension_attributes is undefined"

In Magento1 vsBridge, json response is created using json_encode with JSON_NUMERIC_CHECK flag.

Therefore, every string that look like integer is casted as integer.
That's a good thing, but that creates some bugs:

• Fields such as telephone, postcode, ... must be strings according to vsf schema. That's why vsf doesn't validate data.
• Numbers like '06467' will always be returned as '6467'
• cart id is returned as integer but should be string (then order cannot be placed)

In case you use a varnish or other technics the bridge answers would be cached.
So it would be nice if the answers add a "no-cache" header.

i haven't seen a case where it should anything.

Although it should not happen but if vuesf tries to pull the server cart with a cart-token for which magento does not have a quote it returns 200 with and empty cart instead of 500 and the message that there is no cart with this token. This causes serveral problems in the frontend.

we need to update this row to make it work

$shippingMethodCode = $request->addressInformation->shippingCarrierCode . '_' . $request->addressInformation->shippingMethodCode;

In this Article there is written something of an Enterprise Version of this Bridge?
https://divante.co/blog/pwa-magento-1-9-can/

How can i buy it?

If i have a product without shipping, for example a downloaded product, if the customer have a order with this product the api return a php error

<br /> <b>Fatal error</b>: Call to a member function getData() on boolean in <b>/opt/UNI/swreleases/catalogo/releases/20210427155517/app/code/community/Divante/VueStorefrontBridge/controllers/UserController.php</b> on line <b>333</b><br />

1. The "Available commands" section should be renamed to "pushing data to elasticsearch."

2. Docs mention only docker-compose up from vue-storefront-api is needed because we only need elasticsearch running, but that doesn't seem to be true. it seems actually FULL install of vue-storefront-api is needed for vue-storefront to work. Even if you follow https://github.com/DivanteLtd/vue-storefront-integration-boilerplate as an example you can see it requires you to implement /catalog endpoint for elasticsearch which is not provided by the magento1 module within this repository. and vue-storefront needs it, so my guess is: you need more than JUST elasticsearch from vue-storefront-api.

3. Docs doesn't explain how to point vue-storefront-api to magento1 vsbridge, especially when it comes to "magento2" config node.

Please update the docs by trying to setup the whole thing from scratch. The current one doesn't allow to setup working instance on VueSF based on Magento 1.9.X. Not by JUST following the steps exaplained.

The magento1-vsbridge generates a different schema compared to mage2vs. In result you can not retrieve products because the filter parameter for "is_in_stock" does not match. The same is maybe true for the categories.

Here an example: magento1-vsbridge uses a flat schema for products and is_in_stock is saved on the same level as all other attributes in ES. mage2vs however uses a nested object in ES and it looks like this:

          "stock" : {
            "item_id" : 9,
            "product_id" : 9,
            "stock_id" : 1,
            "qty" : 1000,
            "is_in_stock" : true,
            "is_qty_decimal" : false,
            "show_default_notification_message" : false,
            "use_config_min_qty" : true,
            "min_qty" : 0,
            "use_config_min_sale_qty" : 1,
            "min_sale_qty" : 1,
            "use_config_max_sale_qty" : true,
            "max_sale_qty" : 10000,
            "use_config_backorders" : true,
            "backorders" : 0,
            "use_config_notify_stock_qty" : true,
            "notify_stock_qty" : 1,
            "use_config_qty_increments" : true,
            "qty_increments" : 0,
            "use_config_enable_qty_inc" : true,
            "enable_qty_increments" : false,
            "use_config_manage_stock" : true,
            "manage_stock" : true,
            "low_stock_date" : null,
            "is_decimal_divided" : false,
            "stock_status_changed_auto" : 0
          },

VS however generates the following query:

curl 'https://demo.vuestorefront.io/api/catalog/vue_storefront_catalog/product/_search?size=18&from=0&sort=' -H 'Accept: application/json' -H 'Content-Type: application/json' \ --data-binary '{"query":{"bool":{"must":[{"range":{"visibility":{"gte":3,"lte":4}}},{"range":{"status":{"gte":0,"lt":2}}},{"match":{"stock.is_in_stock":true}}]}}}'

So stock.is_in_stock doesn't match any product in Elasticsearch.

The schema definition os magento1-vsbridge, mage2vs, VS and VSAPI needs to be aligned. Otherwise one will always fall apart.

As this module supports modman, it could also support installation with composer.

When a new node index.js new is executed the mapping for Elasticsearch is created from the file node-app/src/meta/elastic.js. All other fields, especially for the products, are created by Elasticsearch's dynamic field mapping functionality (https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic-field-mapping.html). While this works in general some there are some attributes where it doesn't work.

So when the first product which references an attribute has an empty value or "0", which is a default for values stores in catalog_product_entity_int|decimal, is saved in ES, it is trying to "guess" the type for the mapping and assumes an "integer" field. When next product with has a value, lets say "37.5" is saved in ES, it throws an error like this:

response: '{"error":{"root_cause":[{"type":"mapper_parsing_exception","reason":"failed to parse [configurable_children.width]"}],"type":"mapper_parsing_exception","reason":"failed to parse [configurable_children.width]","caused_by":{"type":"number_format_exception","reason":"For input string: \\"37.5\\""}},"status":400}',

Similar situations can happen for multiselects etc. So eelying on dynamic field mapping is not a stable solution as it only will work for some fields.

So a better approach would be to update the mapping from the attributes. From the attributes we can create the correct field mapping as we know which value to expect.

I belive that Divante_VueStorefrontBridge.xml should go to app/etc/modules/, instead it goes to app/code/modules.

Nope, my bad, it's all right.

It would be great to be able to send reviews to Magento1 from VSF.

We would need an extended Magento1 platform in the API and at least one endpoint in the bridge. Depending on what the user should be able to do with its own reviews in his customer account.

We have planned to extend this in the future, because we need it for our implementation.
So, if you are not planning to add this feature (?), I will leave a short note here when I start with it.

Hi,

the AbstractController function _result has the option JSON_NUMERIC_CHECK for json_encode so zip codes like 01234 are missing the leading 0.