CONNECTORS

Magnolia BigCommerce Connector

BigCommerce is a highly scalable headless commerce platform, delivering commerce APIs for both B2C and B2B. The extensible architecture is designed to enable out-of-the-box integrations.

The BigCommerce connector, built on the Magnolia Commerce Connector Pack framework, allows you to connect your external BigCommerce platform with your Magnolia instance.

Utilising the connector, you can use BigCommerce content within Magnolia as if it were native to Magnolia. The modules provide access to various components of BigCommerce including the shopping cart management and checkout functionality via REST.

Features

The basic version of connector offers the following functionality.

  • Viewing of Categories and Products
  • Viewing of Product Images
  • REST API for basic shopping cart functionality
  • REST API for basic Checkout functionality
  • Search APIs for accessing products and categories

For more features like support and customised solution, Contact our sales team.  Features for enterprise plan are listed below.

  • Pagination
  • Variants
  • Custom Checkout
  • Customer Fields
  • Support for Promotions/Coupons

Are you looking for

Developer
AyataCommerce

Connector Version
1.0.0

Category
Commerce

Documentation
Download

Licensing

Copyright 2020  Ayatacommerce

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Support Services

How to file a bug?

– Go to our issue tracker on GitHub
– Search for existing issues using the search field at the top of the page
– File a new issue including the info listed below
– Thanks a ton for helping make the connector of a higher quality!
– When filing a new bug, please include:

Descriptive title – use keywords so others can find your bug (avoiding duplicates)
Steps to trigger the problem that are specific, and repeatable
What happens when you follow the steps, and what you expected to happen instead.
Include the exact text of any error messages if applicable (or upload screenshots).
Connector version (or if you’re pulling directly from Git, your current commit SHA – use git rev-parse HEAD)
Did this work in a previous version? If so, also provide the version that it worked in.
OS version
Extensions? Confirm that you’ve tested with Debug > Reload Without Extensions first (see below).
Any errors logged in Debug > Show Developer Tools – Console view

What happens after a bug is filed?

Bug lifecycle

  1. New bug is filed; awaiting review
  2. Triaged in bug review — see below (‘last reviewed’ tag)
  3. Developer begins working on it — bug is tagged ‘fix in progress’.
  4. Developer opens pull request with a fix, which must be reviewed — a link to the pull request appears in the bug’s activity stream.
  5. Pull request is merged, and the bug’s filer is pinged to verify that it’s fixed — bug is tagged ‘fixed but not closed’ (“FBNC”).
  6. Filer agrees that it’s fixed — bug is closed, and its milestone is set to the release the fix landed in

Bug review

We review all new issues on a regular basis. Several things typically happen as part of review:

  • Ping the filer for clarification if needed.
  • If the issue is a feature request, we’ll tag it ‘move to backlog’; the issue will be migrated to our feature backlog at a later date.
  • Add priority labels (high, medium, low, or none ).
  • Add release milestone – typically only if a bug is a “release blocker” or related to features still in progress.
  • Add feature area label, and possibly other category labels like ‘starter bug’ or ‘Mac only.’
  • Depending on priority, milestone, and other workload, a developer may or may not begin working on the bug soon.

     Some bugs may be closed without fixing – see “Hey! My bug wasn’t fixed!” below.

Hey! My bug wasn’t fixed!

Yeah, what’s up with that? There are a number of reasons an issue might get closed without being fixed:

  • Tagged ‘move to backlog’ – It’s not forgotten! Look for a link in the comment thread to our feature backlog. Please vote on the story to help us prioritize it!
  • Tagged ‘fixed but not closed’ – We think it’s fixed. Make sure you have a connector build containing the fix (check the milestone assigned to the bug). If you’re still seeing it, let us know.
  • Duplicate – There’s already a bug for this.
  • Unable to reproduce – We’re unable to reproduce the result described in the bug report. If you’re still seeing it, please reply with more detailed steps to trigger the bug.
  • Out of scope / extension idea – This change probably doesn’t belong in connector core… but it could still make for a great extension!
  • Not a bug / fact of life – This is the intended behavior. If it feels wrong, we should discuss how to improve the usability of the feature.

    If you disagree with a bug being closed, feel free to post a comment asking for clarification or re-evaluation. The more new/updated info you can provide,       the better.