WooCommerce store customisation without touching the core

What WooCommerce customisation is and when it makes sense

WooCommerce customisation means changing how a WordPress store’s pages look and behave without building a new shop. It usually covers the product page, categories, the cart and the checkout: layout, colours, fonts, element order and the mobile view.

The work is done with CSS (styles that control the look) and JavaScript (scripts that change page behaviour in the browser). The WooCommerce core, the database and the order logic stay untouched. It makes sense when the store works and sells, but needs to look or behave differently from what the theme offers.

Who it suits and who it does not

It suits you if:

• you run a WooCommerce store and want to change its design, not the whole system,
• some pages do not match your brand or work poorly on mobile,
• you want a clearer cart or checkout.

It does not suit you if you want a WooCommerce store built from scratch: the webrocks offer is customisation of an existing store. Nor is it for backend work such as a custom payment gateway, a stock integration or price calculation. If your store runs on Shoptet, see Shoptet customisation.

How the customisation works

1. Brief. Which pages and elements should change and why. A screenshot or a ready design helps.
2. Current state. Block or classic theme, block or shortcode cart and checkout, and plugins that affect the design.
3. Where the code lives. With block themes, CSS can go into Additional CSS in the Site Editor (Appearance → Editor → Styles). With classic themes, Additional CSS is in the Customizer (Appearance → Customize). Larger changes go into a child theme, a theme that modifies its parent without editing the parent’s code.
4. Live preview. You see the change on your own store through a link before it goes live. You can check it on desktop and mobile.
5. Deployment. Once approved, the change goes live and is checked on the main pages.

What you get

• A finished design change in CSS and JavaScript, stored so that plugin and theme updates do not delete it.
• A live preview link before deployment.
• A short note on what changed, where the code is and what to check after major updates.

Classic or block cart and checkout

WooCommerce has two versions of the cart and checkout. The classic one is a page with a shortcode, customised through PHP hooks (points in the code where a custom function can be attached) and template copies in a child theme. The block version is built from the Cart and Checkout blocks in the WordPress editor.

Since WooCommerce 8.3 (November 2023), the Cart and Checkout blocks are the default for newly created stores. According to the same announcement, existing stores kept their previous checkout after the update. So customisation starts by checking which version your store runs.

What this means in practice:

• Many classic hooks do not work on blocks. According to the hook alternatives reference, the block cart and checkout do not support, for example, woocommerce_before_cart, woocommerce_before_checkout_form or woocommerce_review_order_before_payment. A snippet from the internet may therefore do nothing on a block checkout.
• Checkout fields are changed differently. According to the same reference, editing core fields through woocommerce_checkout_fields does not work on blocks. Adding custom fields is handled by the separate Additional Checkout Fields API, which goes beyond design work.
• CSS is written for a specific version. The block checkout is built from blocks, the classic one is a page with a shortcode. Styles are therefore written and tested for the version the store actually uses.
• Blocks can be configured in the editor. According to the WooCommerce documentation, some changes need no code; the rest is done with CSS.

You can switch back to the classic version by transforming the block into “Classic Shortcode”, always for both the cart and the checkout together, as described in the cart and checkout customisation guide. It is a decision, not a fix: plugins depend on the checkout version too. According to the same documentation, extensions that are not compatible with blocks may not work as expected in the block checkout; a payment gateway, for example, may not appear.

What to watch out for

• Changes made directly in plugin or theme files disappear. According to the WooCommerce documentation, an update deletes the old version and replaces it. Code therefore goes into a child theme or into Additional CSS, which the WordPress documentation says preserves changes when the theme updates.
• WooCommerce template copies in a child theme go out of date. They do not update with WooCommerce, System Status flags them as outdated and, per the documentation on outdated templates, they must be updated by hand.
• A child theme is not a cure-all. According to the WordPress documentation, it lets you update the parent theme without losing changes, but extensive changes in a child theme become hard to maintain over time.
• Design changes will not make a slow store faster. If the problem is loading speed, start with a website speed audit. If you do not know what holds customers back, a UX audit helps.
• Measurement is separate. Whether GA4 counts purchases correctly is a job for GA4 ecommerce tracking.

How much WooCommerce customisation costs

WooCommerce customisation has no fixed price in the price list. The indicative hourly rate in the price list is from 500 CZK/hr and the price depends on scope and complexity.

The price goes up with:

• more page types to change (product page, category, cart, checkout),
• checkout changes that need testing across shipping and payment options,
• a page builder or several plugins that affect the design,
• a missing brief that first has to be clarified.

A clear brief or ready design, a single page and a clean theme bring it down. Discuss the scope through the contact form and you get a reply within 24 hours.

Frequently asked questions

Will a WooCommerce or theme update overwrite the changes?

Changes stored in Additional CSS or a child theme are not deleted by parent theme updates, and since they are not in plugin files, plugin updates do not delete them either. WooCommerce template copies in a child theme need checking after an update.

How do I customise the WooCommerce cart and checkout?

First check whether they run on blocks or the classic shortcode. On blocks, use the block settings and CSS; many classic PHP hooks do not work there, as the hook alternatives reference shows. On the classic checkout, hooks and classic CSS work.

Do I need a child theme?

Not for a few lines of CSS; Additional CSS is enough. A child theme pays off for larger changes and custom JavaScript.

Does webrocks build WooCommerce stores from scratch?

No. The offer is customisation of a running store. For a new, simpler website without a shop, see business website development.