ajrsoftware / wpclothes2order Goto Github PK

After checking the basket for valid C2O items & the posting is done, we need a way to show in the admin UI that the order has taken place and to show if it was successful or failed.

We check for products on order if they're in the 'product_cat' taxonomy provided by WC but are also within the taxonomy term 'clothing'. We programmatically insert that term, so we must ensure that the term exists before checking the basket items if they're related to that term.

@see htmlburger/carbon-fields#1079

As C2O stock availability changes, we need to reach out their endpoint & re sync their stock count with local WC products.

Example:
01/01/2022 -> C2O have 5 tops, 5 trousers & 5 ties available.
02/01/2022 -> C2O have 5 tops, 4 trousers & 5 ties available.

In the example situation above, C2O have less stock so our local store must up their it's stock available to reflect this to disallow over selling items. There will always be times were the store owner will need to reconcile issues with C2O as their API is not kept up-to-date per transaction.

What needs implementing:

WP-Cron to fetch stock results & sync with local product stock availability

• C2O only expose an endpoint to a .csv which contains their stock, this needs parsing

New group of options in the WPC2O settings screen

• Admin can select the frequency which the plugin will fetch stock results to sync (24 hours min edit that is some time after 3:30am)

Within the order history tab of the plugin options, for each order, the user should be able to toggle to see the full API request sent to Clothes2Order.

Involves:

• Storing the full API request in the database, currently we do not save the full request, only produce a new request & send it, then mark the order as processed.
• Adding a this field regardless of the response from C2O, even if the request fails, we still store it as this feature is mostly useful for debugging.
• Including new UI that will allow this toggle.

Discussed in #95

The Clothes2Order API requires certain bits of data per product ordered, so those pieces of data need to be available on the product object when running a basket to send on the payload.

We also need a way for the API keys to be inserted in the admin so they can be available globally.

We can add metadata to a WC order, so when the basket runs & a 200 response is given from the API, we can take some information that is sent back, add that as order metadata so it is shown within the order UI.

If a product variation has been given for example the term 'tops' & has a certain position selected, then if later changed to 'hats' and also has positions selected, then we need to check for old out of term positions & remove them from their meta as not to over bloat the DB.

The overall POST payload can send multiple products, so we need a way to create a payload by passing in certain data, such as:

$product->newPayloadItem(string $name, string $size, string $position);

Having the acf fields saved as json will force all acf fields to save into the plugin & not separately, so moving from the UI setup to php registration would be the ideal solution.

WordPress.org uses svn to publish plugins. We can automate this process by writing a release script that puts the source code of this plugin in a ready state to publish up to svn.

Discussed in #89

Discussed in #107

1. C2O API key
2. C20 API Endpoint
3. C20 Product Category (product_cat) term to auto-register

Different product types can accept different logo widths, for example a 'top' can have a logo placed in different locations, top back, top chest, left sleeve etc.

Based on the product & the logo location, depends on the possible widths.

Thankfully this information was used in the 0.1.0 alpha version as ACF options, so this logic needs to be encapsulated into code / constrained so only valid values are posted to the API.

Let's start by documenting the variations & have those variations visible in the plugin settings. This way these constants can be accessed & used per product.

As we wish to allow users to have complete control over their WPC2O API options, we require a separate settings screen that for now will take the shape of:

WP admin main menu -> WPC2O -> Options screen:

Options screen:

• Full order history (fetched from C2O on page load, transient in place to cache this request)
• Stock sync (Allows manual re-sync of #21
• Select logo positions globally, i.e all checked by default, but maybe disable specific locations & default logo upload (.jpg)
• Select logo creation type, i.e print | embroidery & default widths
• Select delivery method, i.e standard

Whilst the plugin is activated, check if the the required fields of the WC plugin options are set.
If they are now, exit init of the plugin. These options are required for our plugin to work.

Hi,

I am new to coding and don't have much php knowledge...

Through their docs I can see that in the JSON file example there is an array that contains information about the print position, width, a link for the image to be printed etc...

But I don't understand how the plugin collects all these information. I mean where should I put those information in order for the plugin to collect them and send the information through the api. Should I create new fields in product page?

Discussed in #83

Now that we have included a way to use radio buttons instead of checkboxes, there doesn't seem to be a good way to have this happen for just sub-terms of the 'clothing' term in the taxonomy.

We may have to let this slide or revert to using the wp intended way of using checkboxes.