CoCart Pro v1.0.0-rc.5 Release Notes

A minor release for CoCart Pro just to patch a few things until the next big update for CoCart Pro is released.

Those who are on there free trial will not get this update. If you like CoCart Pro activate your subscription and the update will be added to your account.


  • Fixed: Forced the formatting of the returned applied coupons to return as an array always even if a coupon was deleted at some point.
  • Dev: Disabled experimental WordPress auto update features.
  • Dev: Disabled plugin review and beta notice temporarily until new admin notice system in CoCart v3.0 is supported.
  • Dev: Removed the use of cocart_getting_started_doc_url filter no longer used in the core of CoCart.
  • Dev: Updated dependencies used for developing CoCart Pro.
  • Compatible with WordPress 5.7
  • Compatible with WooCommerce 5.1

    New Minimum Requirements
  • WordPress 5.4
  • WooCommerce 4.3

Tutorial: Disable Load Cart from Session

As the only feature in CoCart that does not use the REST API, some developers requested that they have the option to disable it.

A new filter cocart_disable_load_cart was introduced so that you can do just that.

add_filter( 'cocart_disable_load_cart', function() { return true; });

Once the filter is set to true. “Load Cart from Session” will no longer be available.

Force API Permissions

When using a REST-API, sometimes you don’t want all the routes to be available for public use and while CoCart is designed for the public, you may need a reason to restrict public use for certain routes.

Maybe you don’t support guest customers on your store so you need to restrict all the public routes.

Forcing API permissions doesn’t mean that only administrators or shop managers can access them. It’s not forced by user role. It just means that the routes can not be used unless the API is requested while being authenticated.

How do you force API permission?

It’s actually pretty easy. All you need to do is apply a filter based on the method of the routes you want to force permission on.

There are no parameters required. Just return an array of the API routes you wish to force permission on.

Filter name: cocart_api_permission_check_{method}

Replace {method} with get, post, put, delete or options. See example.

add_filter( 'cocart_api_permission_check_get', function() {
  return array(
} );

This also works with the previous CoCart API and CoCart Pro. Just return the version of the API followed by the route. That’s it.

Basic Authentication with CoCart

The core of CoCart needs to have all the basic requirements for any developer to have the base of the API ready to work out of the box for their development and authentication is one of them.

With CoCart v3, basic authentication is now built in and works like a charm.

Considering your web host allows authentication. If not, a little configuration to your .htaccess file will do the trick.

Simply add this to your .htaccess file and the authentication header will pass.

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1]

As for security, basic authentication is recommended to be used on secure sites that have SSL enabled, so if you or anyone attempts to use the API on the site without it being secured. Then it will simply fail.

Unless you are testing on a local or development environment, CoCart will not allow you to authenticate via the basic method.

In addition to being able to authenticate via basic method. Unlike the basic authentication plugin provided by WordPress (which is also outdated a little), CoCart identifies email addresses as a username.

curl -X POST \
  -u \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "35",
    "quantity": 1

This is helpful should the customer forget the username they created or was assigned when registering as a customer and use their email address (along with their password) instead.

Oh and one more thing. Should it not be possible to authenticate the right way using the headers, you can authenticate the user via URL.

Please keep your sites secure! ?

Improving the session table

One question I get asked from time to time is “Why does CoCart have it’s own session handler / database table?”

The reason for this is the default session handler is not designed to support guest customers outside of the site. It’s designed for the purpose of handling session requests with your browser.

Although guest customers were given a unique generated ID, this could only be tracked using the cookie WooCommerce stores on your device when browsing the store.

This does not help for a headless architect/setup when handling the cart outside of the site. So a new session handler was created in order to support guest customers for better tracking.

But why a new session table?

Well to begin with it was only experimental to test the new session handler but after sometime developing the new handler, I decided to keep it place for future developments.

This would allow me to alter the session table after without interfering with WooCommerce default session table structure.

This secures CoCart by making sure it still works should WooCommerce decide to change how their session table is structured in the future.

Now for the improvements

Although small, these additions I think are a great help to store managers and developers.

The new additions to the session table are “Cart Source” and “Cart Created“.

Now carts can be identified if they were created via CoCart or WooCommerce with the date and timestamp for when the cart was created the moment the first item was added to the cart.

I think this is a great addition and with that a new free add-on will be available that will allow you to view carts in session from your WordPress dashboard.

Screenshot is a work in progress.

This is something users have been asking for and it has defiantly helped me with testing CoCart during it’s development.

Hope you like the new additions and add-on coming soon.