Octolize Shipping Packages for WooCommerce - WordPress Plugin

How to Configure Octolize Shipping Packages for WooCommerce to Split Shipping into Packages

Octolize Shipping Packages for WooCommerce is not about showing a nicer list of shipping methods. Its real purpose is to make your order packing logic more precise. In this guide, we'll look at how to connect the plugin to WooCommerce shipping classes, when to enable separate packing for individual products, how to verify the result in the cart, and why the rule order can change the final shipping cost.

This guide is written for a store owner or administrator who already understands the basics of WooCommerce shipping but is dealing with real logistics: fragile items cannot go into the same box as heavy ones, part of the catalog ships from a different warehouse, subscription products need to be calculated separately, and the standard WooCommerce cart groups everything together too broadly in a single shipping calculation.

What follows is not a retelling of the product page, but a practical walkthrough: preparation, rule setup, a furniture store scenario, verification on the storefront, troubleshooting common issues, and a comparison with solutions that handle adjacent shipping tasks.

What problem package-based shipping actually solves

In a standard WooCommerce setup, shipping usually treats the cart as one unified group of products. That works well for a simple store where all items are similar in size, ship with the same carrier, and do not require different handling in the warehouse. But once an order contains different types of products, a single cart starts hiding important details: what should be packed separately, which shipping class should apply, why the shipping cost increased, and which part of the order the warehouse needs to prepare as a separate parcel.

Octolize Shipping Packages for WooCommerce adds an intermediate layer between the products in the cart and the shipping methods. This layer does not replace shipping zones, rate rules, or live rates. Its job is to group products into packages. Once the grouping is done, your existing shipping methods can calculate rates for each package or use package data in their own calculations.

The main mechanism is confirmed in the Octolize documentation: the plugin uses WooCommerce shipping classes as the condition for splitting. The administrator creates a package, selects one or more shipping classes, and specifies whether each product in that class should be packed separately. Everything that does not match a special condition stays in the default package.

Where the plugin is especially useful

This plugin is worth considering in stores where shipping cost depends not only on the address and weight, but also on how the order is physically packed. Typical scenarios include:

• Fragile products need to be shipped separately so they are not mixed with heavy or sharp items.
• Oversized products do not fit into a shared box and need their own shipping calculation.
• Part of the inventory ships from another warehouse, so it cannot be treated as a normal parcel from the main location.
• A subscription product and a one-time purchase end up in the same cart but require different shipping logic.
• The store uses Flexible Shipping or another shipping method where the cost needs to be calculated per package rather than for the cart as a whole.

Key takeaway: this plugin is useful not when you simply need to "add another rate," but when you need to tell WooCommerce which items in the same order must become separate shipments.

Who this plugin is for, and when you may not need it

Octolize Shipping Packages for WooCommerce is a good fit for a store with physical shipping where the administrator already uses shipping classes or is ready to organize the catalog around them. The plugin works especially well in catalogs where classes reflect real packing rules: "Chairs," "Tables," "Fragile," "Accessories," "Pallet Shipping," "Warehouse B."

If the store sells digital products, identical small items, or uses one flat rate for all orders, an extra package layer may be unnecessary. It will not improve shipping on its own if there are no meaningful differences in the catalog that need to be reflected in the packing logic. In that case, it is simpler to keep the default WooCommerce zones and configure one clear shipping method.

What to understand before installing it

This plugin is not a universal rate calculator. It does not create carriers, print labels, measure box dimensions, or choose the best box based on length, width, and height. Its job is narrower: split the cart into packages based on shipping classes. Before installing it, ask yourself three questions:

1. Are there product groups in the catalog that must be calculated separately?
2. Can those groups be reliably expressed through WooCommerce shipping classes?
3. Does your shipping method understand package-based calculation, or at least handle split packages correctly?

If the answer is yes to all three, the plugin solves a specific problem. If what you actually need is complex math based on weight, order total, user roles, delivery schedules, or shipping method visibility, it is better to start with a rate plugin and use Shipping Packages only as an additional grouping layer.

Preparation before installation: classes, zones, and a test cart

Before you install the plugin, do not enable it in a live store and start creating rules blindly. Package logic depends on existing WooCommerce settings, so an error in a shipping class or shipping zone can look like a plugin issue even though the real cause sits one layer below.

Check your WooCommerce shipping classes

In WooCommerce, shipping classes are created under WooCommerce -> Settings -> Shipping -> Classes. The WooCommerce documentation specifically points out that classes group similar products and do not display rates to the customer on their own. Rates come from shipping methods and shipping zones.

For Shipping Packages, classes become the language of the rules. If a product does not have the correct class, it will not be placed into the special package. If a variable product has a class set on the parent product but a different class is overridden on the variation, you need to check the actual variation the customer adds to the cart.

Minimum class map

Before configuring anything, it helps to sketch out a short class map:

• Default package - products with no special logic that stay in the standard shipment.
• Fragile - products that must not be mixed with the rest.
• Oversized - large products that require a separate shipping calculation.
• Warehouse B - products shipped from another warehouse, if that matches your actual logistics.

The names can be anything, but they should be clear to both the administrator and the warehouse team. Avoid creating dozens of nearly identical classes. The more detailed the map becomes, the greater the risk that someone assigns the wrong class to a product.

Check your shipping zones and methods

Shipping Packages works on top of WooCommerce shipping, not instead of it. That means your shipping zones and the methods inside them need to be configured first. WooCommerce matches a customer to only one zone, and the order of zones matters: more specific regions should come first, broader regions later. If a customer cannot see the expected shipping method, check the zone, address, and method before you start reviewing package rules.

Also make sure the selected zone has at least one active shipping method. If the zone is empty, the customer will see a shipping unavailable message no matter how well your packages are configured.

Prepare a test cart

For testing, you need at least three products:

• A regular product with no special class, or with a class that should remain in the default package.
• A product with a class that should be placed into a separate package.
• A product with a different class to verify that the rule is not matching too broadly.

This setup immediately shows whether the split is working, whether the classes are assigned correctly, and whether there is a conflict with your existing shipping rates.

Installation and initial activation

The installation process is the same as for a typical WordPress plugin: the administrator uploads the ZIP file through Plugins -> Add New Plugin -> Upload Plugin, installs it, and activates it. The installation details are covered in Octolize's general documentation for installing WordPress plugins. This guide does not cover purchasing, licensing, or obtaining the paid version, because that is outside the scope of configuring the shipping feature.

After activation, the Octolize documentation says the Shipping Packages item should appear in WooCommerce settings under WooCommerce -> Settings -> Shipping. If it does not appear, first check whether WooCommerce is active, whether the plugin itself is enabled in the Plugins list, and whether the admin menu item is hidden because of user permissions.

First activation without rules

On the configuration screen, there is an Enable/Disable checkbox. It turns on the plugin's functionality and allows shipments to be split into packages. Next to it, you can set the Default package name - the name of the fallback package where products that do not match any special condition will go.

Do not create complex rules right away. First, give the default package a clear name such as Standard package or Default shipment, save the changes, and check the cart without any separate packages. This gives you a baseline for comparison: what shipping looked like before splitting, and what changed after you added the first condition.

Practical check: if shipping disappears or changes unexpectedly immediately after enabling the plugin with no rules in place, the issue is most likely in your base shipping setup, method compatibility, or the test customer's address. Do not add more packages until you understand the starting state.

Configuring package rules: shipping class as the main switch

In Shipping Packages, the Packages table stores your rule set. To create a rule, click Add package, fill in Package name, select one or more classes in the Shipping class field, and save the changes with Save changes. After saving, the package returns to the main table.

One class or multiple classes

If you select multiple classes in the Shipping class field, the Octolize documentation describes that as an OR condition. In other words, the rule will apply if the cart contains a product with any of the selected classes. That is convenient when several classes require the same behavior - for example, when "Chairs" and "Desks" should both be handled as one type of separate shipment.

But this approach comes with a risk: different classes may end up in the same package even though they should not be mixed in the warehouse. If "Glass" and "Heavy" require different boxes, it is better to create two separate packages instead of combining both classes into one rule.

When to enable Product’s separate packing

The Product’s separate packing option means that each individual product with the selected class should be packed into its own package. That is not the same thing as saying "all products in this class belong to a separate group." For example, if a customer adds two identical fragile products, separate packing may result in two distinct packages for those items.

Enable this mode when products physically cannot be combined, even with other products in the same class: glass panels, oversized items, manufacturer-packed single boxes, products with individual packaging, or items where the carrier charges separately. If products in the same class can safely ship together, leave the option off and use regular class-based grouping.

Why rule order matters

The Octolize documentation specifically warns that package splitting takes place according to the order of packages in the table. If the same product matches more than one package, the first matching package in the list will be used. This is critical when classes overlap or when rules were created at different times.

A practical strategy is simple: place the most specific and most costly-to-get-wrong rules at the top, and keep broader rules below them. For example, a rule for fragile products that must always ship separately should be placed above a more general rule for the "oversized items" group if a product could fall into both scenarios through a similar class structure.

Using it with Flexible Shipping and package-based calculation

Shipping Packages can work with different WooCommerce shipping methods, but there is an important detail when it is used together with Flexible Shipping. According to the Octolize documentation, if Flexible Shipping is used alongside Shipping Packages, you need to change the Cart Calculation setting inside the Flexible Shipping method and choose Package value. Otherwise, the rate may continue to look at the whole cart instead of the value of the specific package.

This is one of the most common hidden causes of incorrect results. The administrator can see that the cart has been split into packages, but the shipping cost still looks the same as before or does not match expectations. In that case, the problem may not be the Shipping Packages rules at all - it may be that the shipping method is calculating against the wrong base.

How to think in terms of Input -> Logic -> Output

For each rule, it helps to verify the full chain:

• Input: the product has the correct shipping class, weight, and price, and the customer's address falls into the correct shipping zone.
• Product logic: Shipping Packages places the product into a separate package or leaves it in the default package.
• Output: the shipping method calculates a rate for the package, and the cart shows the final shipping cost.
• Verification: the cart or checkout shows the expected split, and the amount matches your rate rules.
• Failure symptom: the package does not appear, the cost does not change, shipping disappears, or the wrong rate applies.
• Fix: check the product's class, the package order, the Cart Calculation setting, the shipping zone, and WooCommerce debug mode.

This chain is more useful than simply checking whether the plugin is enabled. It shows you exactly which layer is breaking.

Practical example: a furniture store with accessories and chairs

The official Octolize documentation uses a furniture store scenario: products have the classes Chairs, Desks, and Accessories, and for safety reasons chairs ship in a separate package. Below, we will adapt that scenario into a full setup check.

Scenario goal

The goal is to create a clear logic: accessories and desks can ship as a standard shipment, while each chair should be separated. The customer sees an accurate shipping cost in the cart, and the administrator understands which products belong to which package.

Preparation

Before you begin, make sure the following are ready:

• Shipping classes Chairs, Desks, and Accessories.
• A test chair product assigned to the Chairs class.
• A test desk assigned to the Desks class.
• A test organizer or another small product assigned to the Accessories class.
• An active shipping zone and a shipping method that can calculate rates for your test address.

Setup steps

1. Open WooCommerce -> Settings -> Shipping -> Shipping Packages.
2. Enable the plugin using Enable/Disable.
3. Set a clear name for the default package, such as Default package.
4. Click Add package.
5. In the Package name field, enter Separate package for chairs.
6. In the Shipping class field, select Chairs.
7. Enable Product’s separate packing if each chair should ship in its own package.
8. Save with Save changes and return to the packages table.

Verifying the result

First, add a desk and an accessory to the cart. The expected result is that both products stay in the default package, and the shipping cost is calculated as a normal shipment. Then add a chair. At that point, the cart should show a split: the desk remains in Default package, while the chair goes into Separate package for chairs. The final shipping cost should reflect both packages.

If your setup uses Flexible Shipping, make sure the rate calculation is set to Package value. That way, the pricing rule looks at the package contents rather than the cart total.

A real-store nuance

Do not copy this example exactly if your classes describe marketing groups rather than packing logic. A class like "Premium" or "Sale" is rarely appropriate for shipping splits. It is much better to use classes with a physical meaning: "Fragile," "Oversized," "Separate box," "Warehouse B."

Verifying the result on the storefront and in the admin area

Once the setup is complete, do not stop at saving the form in the admin panel. Shipping has to be tested where the customer will actually see it: in the cart and at checkout. If the store uses block checkout, classic checkout, a third-party theme, or a stack of shipping plugins, the front-end result may differ from what you expect.

What to check in the cart

• The customer entered an address that belongs to the correct shipping zone.
• The cart contains products with different shipping classes.
• Products from the special class are placed into a separate package.
• Regular products remain in the default package.
• The shipping cost changes only after a product from the special class is added.
• The package name is understandable to the customer and does not look like an internal technical label.

If the package name is shown to the customer, do not use internal labels like "Rule 1" or "Test split." Name the package in a way that explains the shipment type: "Standard shipment," "Separate fragile items," "Oversized item shipment."

What to check at checkout

The Octolize documentation says the plugins are compatible with both classic and block WooCommerce checkout, but some block checkout cases may have limitations, so you need to check the documentation for the specific plugin. For Shipping Packages, that translates into a simple rule: test both checkout experiences that your site actually uses.

If your theme or builder changes the checkout layout, make sure the customer sees shipping information without clipped text, duplicate blocks, or confusing totals. The plugin controls the packages, but the final presentation is often shaped by the theme, WooCommerce, and the shipping method.

How to use shipping debug mode

Octolize describes WooCommerce Debug Mode as a tool for identifying the active shipping zone and potential conflicts. You can enable it through WooCommerce -> Settings -> Shipping -> Shipping options. In general, this mode should stay off by default and only be enabled temporarily for troubleshooting.

The correct order is: enable debugging, reproduce the test cart, note the active zone and methods, then disable debugging again. Do not leave it enabled on a live site without a reason.

Scenarios where package logic changes the business process

Octolize Shipping Packages for WooCommerce may look like a small plugin, but its impact often goes beyond the number shown in the cart. Once an order is split into logical packages, it changes how the warehouse works, how customer support responds, and how shipping margins are controlled.

Fragile and oversized products

If a fragile product is mistakenly calculated together with standard accessories, the store may undercharge for shipping or send the order in an unsafe way. A package based on the "Fragile" class helps separate those items in advance. For products that cannot be combined even with other items of the same type, Product’s separate packing should be enabled.

Different warehouses and shipping origins

The official product page mentions warehouse-dependent splitting through shipping classes. In practice, this is not a full warehouse management system, but a way to reflect in shipping that part of the order must be calculated separately. If the store needs inventory control by warehouse, order routing, and shipping documents, a separate warehouse solution will be required. But for shipping calculations tied to something like "Warehouse B," classes and packages may be sufficient.

Subscription products

The product page states support for subscription products. This is useful when a single order mixes products with different shipping rhythms, such as a one-time purchase and a subscription item. The guide should not promise that this automatically solves every WooCommerce Subscriptions scenario, but package logic can still be used to keep those items out of the same shipping calculation.

Combining it with rate rules

If the store uses Flexible Shipping PRO or a similar rate system, package logic helps keep those conditions separate. For example, accessories may use a low-cost rate, chairs may have a separate charge, and desks may follow their own rate. Without packages, all of that can collapse into one overall cart calculation that does not reflect the physical packing process.

Safe improvements without editing code

For this product, there is no need to add PHP hooks or edit templates unless there is precise documentation for your specific case. It is safer to improve the configuration and the testing process. Shipping code is especially risky: a small mistake can hide a shipping method or change the order total. That is why the suggestions below are limited to reversible improvements that do not touch WordPress core, WooCommerce, the theme, or the plugin itself.

Create a rule map for your team

Create an internal document with three columns: shipping class, Shipping Packages package, and expected cart behavior. This helps managers assign products consistently instead of guessing. It is especially useful when several people are adding products to the catalog.

Use test products for regression checks

Keep a few test products in drafts or in a private category: one regular product, one fragile product, one oversized product, and one warehouse-based product. After updating WooCommerce, the theme, or plugins, add them to the cart and verify that the package logic still behaves the same way.

Do not mask a bad class structure with more rules

If a rule is not working, do not create a second similar package "just in case." Start by checking the product's class. Duplicate rules with identical conditions are risky because the table order determines which package matches first.

How to design rules that will not break as the catalog grows

The most common mistake in package-based shipping is configuring rules for one current order instead of for the future structure of the catalog. Today the store may have ten chairs and five desks, but next month it may include bundles, variations, promotional sets, and products with similar names. If the rules depend on arbitrary classes, the administrator will quickly lose control.

It is better to think of Octolize Shipping Packages for WooCommerce as a small logistics classification system. First, you describe the real reasons why items need to be split. Then you translate those reasons into shipping classes. Only after that do you create the packages. This order may feel slower, but it reduces conflicts because every package ends up with a clear purpose.

Start with the logistics rule, not the plugin

For each future package, write the rule in plain language. Not "create a Chairs package," but "each chair ships separately because the packaging does not allow combined shipment." Not "add Warehouse B," but "products from the secondary warehouse must not be mixed with products from the main warehouse when shipping is calculated." A rule phrased this way immediately tells you whether you need the Product’s separate packing option, whether multiple classes can be grouped together, and what the package should be called.

If a rule cannot be explained without internal jargon, it is probably a poor fit for shipping. For example, a "VIP" class may be useful for discounts, but it says nothing about packing. For package logic, classes work best when they describe the physical side of shipping: size, fragility, warehouse, packing method, or shipment group.

Keep a single source of truth for the product

In WooCommerce, each product can have one shipping class, while variations can have their own classes. That means you should decide in advance where the final decision is stored. For simple products, it is straightforward: the class is assigned on the product itself. For variable products, it is safer to verify the variations directly, because different sizes or configurations may require different shipping treatment.

A good practice is to add a separate step to your product publishing workflow: "Shipping class verified." This is not a plugin setting, but it is what protects your Shipping Packages rules from accidental mistakes. If a product is created without a class, it will go into the default package even if it should logically ship separately.

Test mixed carts, not just single products

A single product rarely shows the full problem. For each rule, create three tests: the special product by itself, the special product together with a regular one, and the special product together with another special class. The first test shows that the class is recognized. The second shows that the default package still behaves correctly. The third shows whether the rules conflict.

If the third test sends a product to the wrong package, do not rush to change your rates. Start with the package order and the class overlap. This is where the Octolize warning usually shows up in practice: the first matching package in the table takes priority.

Track changes after updates

Shipping depends on several layers: WooCommerce, the theme, checkout, shipping methods, rate plugins, and Shipping Packages. After updating any one of those layers, it is useful to rerun a short regression scenario. That takes much less time than investigating a customer complaint from someone who could not place an order or saw a strange shipping total.

You can keep a minimum regression scenario in the administrator notes:

1. Clear the cart and add a regular product.
2. Verify the standard shipping method for the test address.
3. Add a product with a separate class.
4. Check that a separate package appears and that the final total changes as expected.
5. Add a second special product and verify the package order.
6. Open checkout on both desktop and mobile.

The best sign of a good setup is not the absence of complex rules, but predictability. The administrator should know in advance which package will appear when a product is added, and the warehouse team should recognize the package names as real packing actions.

Common issues and troubleshooting

Problems with Shipping Packages almost always fall into one of four areas: the product does not have the right class, the package rule is configured incorrectly, the shipping method is not calculating by package, or WooCommerce selected a different shipping zone. The best way to troubleshoot them is by symptom.

The package does not appear in the cart

Symptom: a product with special shipping logic has been added to the cart, but shipping still looks normal and no separate package is visible.

Possible cause: the product does not have the correct shipping class, the class is assigned to the wrong variation, the plugin is disabled through Enable/Disable, or the rule was created for a different class.

What to check: open the product in the admin area, review the shipping tab, then open the package rule and compare the selected class. For a variable product, check the exact variation.

How to fix it: assign the correct class, update the product, clear the cart, and rebuild the test from scratch. If the rule was changed several times, do not rely on the customer's old cart.

The shipping cost does not change after splitting

Symptom: the package appears, but the final shipping cost is the same as before the setup.

Possible cause: the shipping method is calculating against the full cart rather than the package. For Flexible Shipping, the Octolize documentation recommends selecting Package value in Cart Calculation.

What to check: the settings of the shipping method you are using, the cost rules, the active zone, and the test address.

How to fix it: switch the calculation to package value where supported, then repeat the test with two carts: one without the special product and one with it.

The wrong package was applied

Symptom: the product was placed into a separate package, but not the one you expected.

Possible cause: multiple packages use overlapping classes, and the first matching package in the table captures the product before a more specific rule can apply.

What to check: the order of packages in the Packages table and any repeated conditions.

How to fix it: move the more specific rule higher, remove duplicates, and check whether classes are being grouped with an OR condition in cases where you actually need separate packages.

The customer sees a "no shipping available" message

Symptom: after configuring packages, checkout shows no shipping methods or WooCommerce displays a shipping unavailable message.

Possible cause: the address does not fall into the correct zone, the zone has no active methods, the shipping method does not support the current conditions, or the package received values for which no rate is configured.

What to check: turn on Debug Mode briefly and verify which zone is active. Then review the methods inside that zone.

How to fix it: configure the zone, add or enable a shipping method, and verify the rate for the separate package. If the problem started after adding a new rule, temporarily disable that rule and return to the last working configuration.

Packages work in the cart but look strange at checkout

Symptom: everything looks clear in the cart, but at checkout names are clipped, totals are duplicated, or the display looks inconsistent.

Possible cause: the theme, block checkout, or a third-party plugin is changing how shipping is rendered. Octolize indicates general compatibility with classic and block checkout, but for some block-based cases it recommends checking the documentation of the specific plugin.

What to check: the active checkout type, the theme settings, checkout optimization plugins, and the display on mobile.

How to fix it: start by renaming the packages with shorter labels. If that does not help, disable conflicting checkout enhancements in a test copy of the site and identify which layer is changing the output.

When Octolize Shipping Packages for WooCommerce is the right choice

This plugin is worth using when the real packing logic of an order does not match the way WooCommerce treats the cart by default. It is especially useful for stores with fragile, oversized, warehouse-based, subscription, or otherwise logistically different products. The strength of the product is its simple connection to shipping classes: assign a class to the product, create a package, and verify the result in the cart.

You should not expect it to act as a rate builder, live rates engine, label printing system, or box selection algorithm. Those are separate tasks. But as a layer that tells shipping logic "these items must be calculated separately," Octolize Shipping Packages for WooCommerce fills an important gap between the catalog and the shipping calculation.

Before going live, run one short test: one regular product, one product with a special class, one mixed order, a cart check, a checkout check, and then a debug mode check. If the result matches your actual logistics, you can download the latest version of Octolize Shipping Packages for WooCommerce and roll the setup out to the live site using a careful test scenario.

An Octolize video specifically about package splitting in WooCommerce was identified in the documentation as a training resource, but the page did not expose an embed ID in the available HTML. For that reason, no video block was added to the guide - it is better not to insert a random YouTube iframe than to show a video that cannot be reliably matched to the product.