Razzi 2.4.2 – Multipurpose WooCommerce WordPress Theme

I used Razzi for a small fashion store that had been dragging around a half-dead Flatsome setup since 2019. The client wanted a cleaner catalog, quick-view, Ajax cart, better mobile filters, and “something like Zara, but not expensive.” Yeah, that sentence already hurt.

First impression: Razzi looks good out of the box. The shop layouts are polished, the product cards don’t look like they were designed by a backend intern, and the demo import actually got me close enough without spending half a day rebuilding sections in Elementor.

But of course, after ten minutes in DevTools, the honeymoon was over.

What I liked without pretending everything is perfect

The strong part of Razzi is the WooCommerce layer. Product archive layouts, sticky add-to-cart, variation swatches, off-canvas cart, wishlist-style UI bits — all the usual ecommerce toys are there.

Most visual stuff is configurable from:

• Appearance -> Customize -> Shop
• Appearance -> Customize -> Header
• Appearance -> Customize -> Typography
• Razzi -> Theme Options
• Elementor widgets for home page blocks

The header builder is decent. Not amazing, but decent. I built a desktop header with logo/search/account/cart in about 15 minutes. Mobile header took longer because, naturally, the spacing looked fine in preview and stupid on an actual iPhone.

The annoying performance bits

I opened Chrome DevTools, Network tab, disabled cache, and Razzi was loading multiple font weights I never asked for. The client only used 400 and 600, but the page pulled extra Google Fonts garbage.

I fixed it in Appearance -> Customize -> Typography, then double-checked the rendered <link> tags in the page source. Still had one leftover font request from an Elementor section. Classic.

The DOM also gets chunky on product grids. If you enable quick view, wishlist, compare, badges, hover image, and countdowns all at once, your archive page becomes a nested div lasagna. Looks nice, scrolls slightly drunk on mid-range Android.

My advice: don’t enable every shiny toggle. In Customize -> Shop -> Product Catalog, keep only what the store actually needs.

Builder vs PHP: where the fun stops

You can change homepage sections, banners, sliders, and product blocks in Elementor. Fine.

You can change catalog columns, product card buttons, sale badges, breadcrumbs, and header layout in Customizer. Also fine.

But once you need custom markup around the product loop, welcome back to PHP land.

I had to touch:

• header.php for a tracking snippet placement the client’s CRM insisted on
• woocommerce/content-product.php for custom badge logic
• woocommerce/single-product/meta.php to clean up ugly SKU/category output
• functions.php in the child theme for extra hooks
• inc/classes/class-theme-setup.php only to inspect what the theme was registering, not to edit directly

Do not edit the parent theme unless you enjoy losing work during updates. Make a child theme, override Woo templates there, and sleep like a semi-normal person.

The JS problem that wasted my evening

Here’s the dumb one. After enabling JS delay in WP Rocket, product variations stopped updating price and image. No console explosion, just silent broken behavior. My favorite kind of bug. Very healthy for blood pressure.

In DevTools Console I saw variation events not firing after selecting size/color. The fix was boring but effective: exclude these from delay/minify:

• jquery-core
• jquery-migrate
• wc-add-to-cart-variation.js
• wc-single-product.js
• the main Razzi frontend script handle

After that, variations worked again, Ajax cart stopped acting possessed, and I could finally close the laptop without wanting to throw it into traffic.

GPL note for other devs

The package I worked with was distributed under GNU GPL terms. No product key was needed for runtime use, and the theme features I needed — including demo import — were available out of the box. I also used it on staging, local, and production without domain-count nonsense.

The tradeoff: don’t expect automatic vendor updates from the dashboard. I usually update manually before deploy:

1. Backup database and /wp-content/themes/razzi/
2. Test the new zip on staging
3. Upload through Appearance -> Themes -> Add New -> Upload Theme
4. Or replace files via FTP/SFTP if the dashboard upload complains
5. Re-save permalinks and clear object/page cache

Boring process, but boring is good when a shop takes real orders.

Stuff that made me swear

Razzi has too many overlapping settings. Sometimes a button color comes from Customizer, sometimes Elementor, sometimes a WooCommerce widget style, sometimes a CSS variable buried in the theme stylesheet. Pick a lane, please.

The mobile menu also needed CSS surgery. I added this in the child theme stylesheet because the off-canvas panel was too wide on small phones:

@media (max-width: 480px) {
  .mobile-menu-panel {
    width: 88vw;
  }
}

Tiny fix, but the default felt clumsy.

Would I use Razzi again?

Yeah, probably. Annoyingly, Razzi gets enough right that I can forgive the mess. For a WooCommerce store where the client wants modern ecommerce UI without paying for a fully custom frontend, it’s workable.

Just don’t install it, import a demo, stack five optimization plugins on top, and act shocked when Ajax cart breaks. Test like an adult.

Dev pain FAQ, because someone will ask

Why does Ajax cart break after optimization?

Usually delayed JS. Exclude jquery-core, WooCommerce cart scripts, and the main Razzi frontend script from delay/minify.

Can I redesign product cards without PHP?

Small changes, yes. Deep markup changes, no. Override woocommerce/content-product.php in a child theme.

Why is the mobile menu spacing weird?

Customizer gets you halfway. For exact widths/padding, use child theme CSS and test on real devices, not just browser resize.

Is Razzi too heavy for big catalogs?

Not if you disable extra product-card effects. Quick view, hover images, compare buttons, and badges all add DOM weight fast.