Customising a WooCommerce Store with Elementor Without Breaking the Theme

When you customise WooCommerce with Elementor, the easy part is the design. The hard part is changing how the store behaves without breaking something the next time WordPress, WooCommerce or Elementor updates.

I recently did a round of changes on a live store for a single-product hair oil brand in Pakistan. It runs WooCommerce, Elementor Pro and the Hello Elementor theme, with the newer block-based checkout and Cash on Delivery. The client wanted a lot of small changes, and the store had to keep taking orders the whole time.

Here's how I approached it, what I changed, and what I'd tell anyone doing the same.

My one rule: never edit the theme files

The quickest way to customise a WordPress site is to open the theme's functions.php or style file and start adding code. It's also the quickest way to lose your work. The next theme update overwrites those files, and one typo in PHP can take the whole site down.

The usual answer is a child theme, and that's still a good option for bigger projects. For this store I used a code snippets plugin instead (WPCode), because it suited the kind of changes we needed:

• Every change is its own snippet, with a clear name like "Cart page mobile fixes"
• I can switch one snippet off without touching the others
• Nothing lives inside the theme, so updates don't wipe anything
• The client can see a list of every customisation in one place

By the end, the store had about a dozen snippets. Each one does exactly one job.

How I keep snippets from causing trouble

A snippets plugin is only safe if you're disciplined with it. These are the habits I stuck to:

• Scope everything to the page it's for. If a style is only meant for the product page, it starts with body.single-product. That way it can't leak into the cart or the homepage.
• Move things, don't rebuild them. If WooCommerce already outputs something (an order summary, a message, a form), I reuse that output instead of recreating it. Less code, and it keeps working when WooCommerce changes its markup slightly.
• Deactivate instead of delete. When a newer snippet replaced an older one, I switched the old one off but kept it. If the new approach caused a problem, going back took one click.
• Clear the cache every time. The store runs LiteSpeed Cache. Half of "my change isn't working" moments are just cached CSS or JavaScript, so I purged after every change.

The changes I made, and how

These are real changes from this project. None of them touch the theme.

1. Opening the cart drawer after "Add to cart"

The header already had Elementor Pro's Menu Cart widget set to a side drawer. The client wanted the drawer to slide open as soon as someone added the product.

The catch: the product has two options (one bottle or two), which makes it a variable product. On this setup, adding a variable product reloads the whole page instead of using AJAX, so the usual "added to cart" event never fires.

The fix was a small JavaScript snippet. When the product page loads, it checks for WooCommerce's success message. If it's there, it opens the drawer. It also listens for the normal AJAX event, in case the setup changes later. Because Elementor sometimes finishes loading after my script runs, the snippet retries a few times before giving up.

This replaced an earlier snippet that only moved the success message under the button. That one is now switched off, not deleted.

2. Getting rid of the WooCommerce purple

WooCommerce buttons turn purple on hover by default, which clashed with the brand's gold. A short CSS snippet keeps the "Add to cart", drawer and "Proceed to checkout" buttons gold in every state, and hides the duplicate success message on the product page now that the drawer opens instead.

3. Fixing the cart page on mobile

On phones, the cart page had two problems. The cart totals box sat at 48% width because of an old float rule, and the small "×" to remove an item was easy to miss and easy to tap by accident.

A mobile-only CSS snippet made the totals full width, stacked the coupon and update buttons, and replaced the "×" with a clear "Remove" text link at the bottom of each item. One lesson here: I couldn't test this properly by resizing a desktop browser. The client's own phone screenshots were the real test.

4. A cleaner order confirmation

After checkout, WooCommerce shows a plain "order received" page. The client wanted something that felt more finished.

Instead of building a new page, the snippet takes WooCommerce's own order summary and shows it inside a centred popup, with "Track your order" and "Continue shopping" buttons. The URL stays the standard order-received address. That matters, because payment confirmation, order emails and analytics all rely on it. The change is purely visual.

5. Shipping prices based on the customer's city

The store used to charge one flat shipping rate. Delivery inside Karachi is cheaper, so the client wanted Rs 200 for Karachi and Rs 400 everywhere else.

A PHP snippet hooks into WooCommerce's shipping rates and sets the price based on the city. To make the price clear before checkout, a small popup asks "Where are you shopping from?" on the first visit and shows the delivery charge as soon as a city is picked. On the checkout page, it fills in the city and province for the customer, but only if those fields are empty. It never overwrites an address a returning customer has already saved.

One thing that caught me out: the block checkout uses different field IDs from the old shortcode checkout, so code written for one doesn't work on the other. Check which one your store uses before copying any snippet from a tutorial.

6. Order tracking without a plugin

The client was entering courier tracking numbers by hand and messaging customers on WhatsApp. I added two fields to the order screen, "Tracking number" and "Tracking link". When a number is entered, or the order is marked Completed, the customer automatically gets a branded email with the number and a tracking button.

There's also a simple "Track your order" page where customers type their order number. Because order numbers can be guessed, that page only shows the order status, date and tracking details. No name, address, phone number or items.

7. Moving the star rating up the product page

The Elementor product template had the star rating far down the page, well below the price. Rather than rebuild the template, a few lines of JavaScript move the rating widget to sit right under the price. I also styled the review form so it matches the rest of the site.

What I'd tell anyone customising WooCommerce with Elementor

A few lessons from this project that apply to almost any store:

• Elementor handles the layout, code handles the behaviour. Don't fight Elementor to do things it wasn't built for. Let it design the page, and use small, focused snippets for logic like shipping rules or emails.
• Know your checkout type. Block checkout and classic checkout behave differently. Many snippets online only work with the classic one.
• Test with real orders. I placed a test order, checked the emails and tracking, then cancelled it. That's the only way to be sure the full flow works.
• Keep the standard WooCommerce flow intact. Change how things look, but keep the URLs, emails and order data where WooCommerce expects them. That's what keeps your store working through updates.
• Watch the snippet count. A dozen focused snippets is fine. If you find yourself heading towards thirty, it's time for a proper child theme or a small custom plugin.

All these extra scripts also have a cost. Every snippet you load is something the browser has to download and run, which is why I keep them scoped to the pages that need them. If your store already feels slow, read my guide to fixing a slow WooCommerce store first, and my notes on Elementor 4 performance are worth a look too.

If you'd like changes like these on your own store, that's exactly what I do in WooCommerce development. For ongoing updates and checks after the work is done, there's website maintenance. And for WooCommerce's own guidance on building and changing stores, the WooCommerce theme development docs are the official reference.