CodeCanyon WooCommerce Product - WordPress Plugin

Guide to CodeCanyon WooCommerce Product: setting up Producter for WooCommerce and Elementor

In this guide, CodeCanyon WooCommerce Product refers to WooCommerce Product Widgets for Elementor by Merkulove, which is also called Producter in the documentation and demo. The guide below does not repeat the product listing. Instead, it shows how to use this widget set in practice: prepare WooCommerce products, display product data in Elementor, build a product page, verify the result, and quickly identify why some data may not appear.

The core idea behind the plugin is simple: instead of relying on a rigid product template defined by your theme, you assemble the product card from Elementor widgets. This is especially useful when a store already runs on WooCommerce, but the default product page does not fit the brand, landing page, promo page, or a catalog with a custom layout.

There are two important limitations to keep in mind. First, the plugin does not replace WooCommerce as the system that manages products, prices, stock, and attributes. It displays existing data and gives you styling control in Elementor. Second, not every widget behaves the same way in every context: most blocks can work on a regular page by selecting a specific product, while Product Data Tabs is designed for a product page and the current product context.

To keep this guide practical, we will cover more than installation. We will also look at the underlying data flow: where the price comes from, why the additional attributes block may not appear, how to avoid breaking the product SEO heading, how to check responsiveness, and what to do if your theme, cache, or an outdated WooCommerce template causes conflicts.

When Producter solves a real store problem

Producter is useful when you need more than a standard theme template to present a product. For example, a store may want a promo page for a single product: a large gallery on the left, the discounted price beside it, a short description below, stock status and rating underneath, and technical specifications moved into a separate block. Without a widget set like this, site owners often end up editing PHP theme templates or installing a heavyweight store builder. Producter addresses a narrower need: it takes specific WooCommerce data and gives the designer control over where and how that data appears in Elementor.

According to the official product page and documentation, the plugin adds 9 widgets: Product Images, Product Stock, Product Rating, Product Data Tabs, Product Meta, Product Short Description, Product Additional Information, Product Price, and Product Title. This is not a full checkout system, not the cart, not catalog filters, and not an archive builder. So expecting it to deliver a complete turnkey store would be the wrong assumption. Its strongest use case is visually assembling product fragments on a product page or on a regular page that features one selected product.

This approach works well for agencies and store owners who already understand product structure. If images, pricing, sale data, stock, SKU, categories, tags, short description, attributes, and tabs are properly filled out in WooCommerce, Producter becomes a visual layer on top of that data. It does not force you to rebuild your product database or store critical commercial values outside WooCommerce.

There is also a downside. If the store is empty, products are set up inconsistently, some items have no images, attributes are not marked as visible on the product page, and sale prices are typed manually into the description text, Producter will not fix that automatically. It will display whatever WooCommerce provides. That is why a good implementation starts not with dragging widgets into place, but with reviewing your product data first.

Who this plugin is a good fit for

Producter is worth considering if you work with Elementor and WooCommerce, want control over the product page without editing theme files, build separate landing pages for products, or need precise styling for individual product blocks. It is especially useful when the default WooCommerce widgets in Elementor Pro are logically close to what you need, but you still want more granular control over where and how the image, price, stock, metadata, or additional information is displayed.

A practical example would be a clothing or accessories store where the product card needs a more editorial feel: a large photo, a prominent sale indicator, a short description that reads like a selling paragraph, a separate stock block, and a clean SKU line for support. Another scenario is a technical store where Additional Information needs to appear next to the price because shoppers compare specifications before reading a long description.

The plugin also works well for curated and promotional pages. The documentation confirms that several widgets can work on a regular page: if the block is not placed inside the current product page, you select the desired product in the settings. That makes it possible to build something like a "product of the week" page, where the image, price, rating, and short description are pulled from a real WooCommerce product rather than copied by hand.

Who should choose a different tool

If you need your entire store handled through one visual builder - archives, filters, quick view, wishlist, compare, checkout, cart, account pages, and a large template library - Producter may be too narrow. In that case, it makes more sense to look at ShopEngine, JetWooBuilder, WooLentor, or Elementor Pro WooCommerce Builder, because those tools cover broader areas of the store rather than only individual product data blocks.

If the site does not use Elementor, Producter is not a practical choice either. The widgets were built specifically for Elementor, and the main workflow happens inside its editor. For a classic theme without a builder, it is usually simpler to rely on native WooCommerce hooks, blocks, theme templates, or specialized extensions for the specific task.

Another case is a strict, high-traffic store where visual builders are prohibited by internal development standards. In that situation, the decision belongs to the team responsible for performance, caching, and long-term maintenance. Producter is not presented as a source of heavy business logic, but any additional Elementor layer should still be tested on a real catalog, especially if the page includes many images, tabs, and dynamic widgets.

What to check before installation

Before installing Producter, make sure your WooCommerce data is ready for visual output. The plugin uses real product data, so the weak point is often not the widget itself but the product: missing gallery images, inventory tracking turned off, no attributes, empty SKU, reviews disabled, or the test product not published. The more carefully your products are filled out, the more predictable the widgets will be.

Start by checking three required dependencies: WordPress, WooCommerce, and Elementor. The CodeCanyon page lists compatibility with Elementor, Elementor Pro, WooCommerce, and WPML, and the official Producter documentation explicitly says Elementor and WooCommerce are required. If you are building a true Single Product template through Elementor Theme Builder, Elementor Pro is usually important because of how Elementor templates work, not necessarily because Producter itself requires it.

Next, open several real products and make sure they represent different states. One product should be standard, another discounted, a third should have multiple images, a fourth should include attributes and an SKU, and a fifth should have reviews or at least a test rating. This is not just for appearance. You need this set to test all Producter branches. If the template is only tested on one ideal product, it may fall apart on the first item that has no gallery or no attributes.

Preparing product data

For Product Images, the main product image and the gallery both matter. WooCommerce separately documents the product image, catalog images, and thumbnails, and also recommends sufficiently large source files. If a product has only one small photo, Producter will not turn it into a convincing carousel. For a page with a large visual block, it is better to standardize image style, check gallery order, and remove duplicates in advance.

For Product Stock, WooCommerce inventory settings matter. If global inventory tracking is disabled or the product does not manage stock quantities, the widget may show only a general status or fail to deliver the result the manager expects. WooCommerce Products Inventory settings include logic for manage stock, stock quantity, holding unpaid orders, and availability statuses. Producter does not manage inventory. It only displays the information WooCommerce already has.

For Product Additional Information, attributes matter. In WooCommerce, attributes help describe a product and create variations, but for them to appear in additional information, they must be filled in and visible on the product page. If attributes exist only as internal variation data or are not marked for public display, the visual block for additional details may appear empty.

Checking the theme and WooCommerce templates

Your theme can affect WooCommerce templates, button styles, tabs, the gallery, container width, and review behavior. WooCommerce official System Status documentation specifically recommends checking theme status, WooCommerce support, and outdated template overrides. It is useful to do this before implementing Producter, otherwise any visual conflict may be incorrectly blamed on the new plugin.

At a minimum, do the following: open WooCommerce > Status, review the theme and templates section, check for outdated template warnings, and then create a site backup or at least a staging copy. If the issue appears only with the active theme and disappears on Storefront or a default theme, the cause is most likely the theme or its WooCommerce overrides rather than Producter.

Practical check: before installation, make a list of 5 test products in different states: regular, on sale, not on sale, with a gallery, with attributes, with stock quantity, and without an SKU. This set will be useful for setup, responsive testing, and troubleshooting.

What Producter actually adds to Elementor

Producter does not add a new product type or change the WooCommerce model. It adds a widget set to the Elementor panel, and each widget pulls product data and outputs a separate fragment: title, price, image, rating, metadata, stock, short description, additional information, or tabs. The best way to think about it is as a set of "output points" for WooCommerce product data.

The official documentation includes an important detail: Product Images, Product Stock, Product Rating, Product Meta, Product Short Description, Product Additional Information, Product Price, and Product Title can work both on a product page and on a regular page. On a product page, they automatically receive the current product. On a regular page, you need to select a product from a dropdown. Product Data Tabs is different: it only accepts data on a product page.

This difference shapes the page architecture. If you are building a real product template, the widgets should pull the current product and change from product to product. If you are building a promo block on a regular page, each widget must be tied to the selected product. Errors happen when a designer moves a block from a regular page into a Single Product template or the other way around without checking how the data source is selected.

Product Images: gallery and Sale flash

The Product Images widget outputs the product image or image carousel. The Content settings confirm support for product selection on a regular page and a Sale flash toggle. The Style tab includes spacing, background, borders, radius, and shadows for the image, thumbnails, and sale badge. This is often the first block worth designing, because it sets the visual rhythm of the entire product card.

If the product is highly visual - clothing, accessories, electronics, cosmetics, furniture - the gallery should take a prominent place. If the product is digital or technical, the image can be smaller, while the price, specifications, and short description deserve more attention. Only enable Sale flash where a real discount exists and where the badge does not compete with the price. If the page already includes a separate promotional terms block, a duplicate sale label may overload the first screen.

Product Price and Product Stock: a commercial signal near the action

Product Price outputs the product price and supports WooCommerce discount, sale, and scheduled sale scenarios. The settings include alignment and Sale price position, so the discounted price can be placed before, after, above, or below the main price with different alignment options. This is not just a decorative setting. The position of the sale price affects how quickly the shopper understands the savings and the current amount.

Product Stock shows availability and stock quantity. In Content, it offers alignment, before text, after text, and HTML Tag. That means the stock level can be displayed as a quiet line such as "In stock: 18" or as a stronger trust signal near the price. But if WooCommerce inventory is not configured correctly, the widget should not become a source of artificial scarcity. It is better to show an honest status than to manually write phrases that do not match the actual store data.

Product Rating, Product Meta, and additional details

Product Rating outputs the product rating and can display a reviews link. For visual control, the widget includes star size, rating color, review text color, background, borders, shadows, and hover states. This widget works best where reviews help the buyer decide: next to the title, near the price, or above the short description. If a new store has no reviews, the rating may look empty and distract from the purchase, so it is often better to hide it temporarily or leave it out of the first template.

Product Meta handles categories, tags, and SKU. The documentation confirms View options such as Table and Inline, separators as Text or Icon, and labels for Tag Single, Tag Plural, Category Single, Category Plural, SKU, and Missing. This is useful for stores where SKU matters for support, wholesale buyers, or search. In a fashion catalog, the SKU can move lower on the page, while in a technical store it often belongs right next to the title.

Product Additional Information outputs extra details from product data. According to WooCommerce documentation, additional information is tied to attributes, weight, dimensions, and visible product characteristics. Producter includes Show title and alignment/style settings. This is one of the most useful blocks for configurable products: dimensions, material, compatibility, color, capacity, wattage, or kit contents.

Product Data Tabs: a special product-page context

Product Data Tabs outputs WooCommerce data tabs. The official Producter documentation explicitly states that this widget works on a product page and receives the current product. So it should not be treated as a universal block for a regular promo page. If you only need selected product specs on a regular page, Product Additional Information or Product Short Description is usually the more practical choice because those widgets support product selection.

The WooCommerce tabs themselves usually contain Description, Additional Information, and Reviews, but whether they appear depends on the product data and store settings. If a product has no attributes, Additional Information may not appear. If reviews are disabled, the Reviews tab will not produce the expected result either. That is why Product Data Tabs setup begins not in Elementor, but in the WooCommerce product itself.

Installation and the first post-activation check

Installing CodeCanyon WooCommerce Product follows the standard WordPress plugin ZIP workflow. WordPress supports uploading a plugin through Plugins > Add New > Upload Plugin, selecting the ZIP file, installing it, and activating it. If the site is managed by a developer through WP-CLI, WordPress also supports ZIP-based plugin installation by command, but for a typical store owner, the safer path is still the admin dashboard and a staging site.

Before uploading, make sure you are using the installable plugin archive rather than the full package that includes documentation and extra files. This is a common trap with CodeCanyon plugins: the main archive may contain documentation, a license, source files, or a separate installable plugin folder. If WordPress says the archive does not contain a plugin, that does not necessarily mean Producter is broken. Most likely, the wrong ZIP file was selected.

After activation, do not expect a large standalone Producter settings page in the admin area. The documentation describes the main workflow through Elementor: open or create a page, find the WooCommerce Producter widgets near the end of the general section, drag in the widget you need, and configure it in the left editor panel. That is a normal model for an Elementor add-on: the main interface lives inside the page editor.

First smoke test

The quickest test looks like this. Create a draft regular page, open it with Edit with Elementor, find the Product Title or Product Price widget, drag it onto the canvas, and select a specific product in the Products field if that option is available. Click Update and open the preview. If the title or price appears, Producter can see WooCommerce products and the basic integration is working.

Then repeat the same test on a product page or inside a Single Product template. In that context, the widget should pick up the current product automatically. Do not test just one item - check several: a simple product, a discounted product, a product without an SKU, and a product with attributes. This will immediately show which blocks depend on specific data and where fallback text may be needed.

If the widget does not appear in Elementor, first verify that WooCommerce and Elementor are both active, then check the installed plugins list. If Elementor loads slowly or the widget panel freezes, temporarily disable cache and script optimization during testing, use the browser console only as a supporting step, and compare behavior on a default theme. Do not start with reinstalling the plugin. More often, the issue is a dependency, a conflict, or a specific template.

How not to break an already published product page

Do not edit a live product template without a draft. In Elementor Theme Builder, you can create a new Single Product template, assign display conditions later, and test it as a draft first. If the site is already generating sales, the safest order is this: create a staging copy, build the template, test several products, compare the mobile layout, and then apply conditions only to one category or one test product. After validation, you can expand the conditions to the full catalog.

Another safe approach is to start not with a full template, but with a regular page tied to a selected product. This does not replace final testing in the current product context, but it quickly shows how the individual widgets behave: Product Images, Price, Rating, Stock, Meta, and Short Description. A draft like this works well as a practical settings palette.

The core mechanic: current product vs selected product

The most important thing to understand in Producter is where the widget gets its product from. On a WooCommerce product page, there is a current product: WordPress and WooCommerce already know which product post is being opened, along with its images, price, stock, attributes, and tabs. In that context, a Producter widget receives data automatically. On a regular page, there is no current product, so the documentation describes a Products field where you must select a specific product.

This mechanic affects everything: template reuse, errors, moving blocks between pages, testing, and SEO. If you are creating a single polished landing page for one product, selecting the product manually in each widget is fine. But if you are building a reusable Single Product template, manually tying widgets to one product becomes a mistake: all product pages may start showing the same data, or some blocks may lose their purpose.

In practice, it helps to split your tasks into two types from the start. The first type is a "product template," where Product Title, Product Images, Product Price, Product Stock, and the other blocks should change with the current product. The second type is a "manual promo block," where the designer intentionally selects one product and builds a promotional fragment inside a regular page.

Single Product template scenario

In a product template, dynamic behavior matters. You build the structure once: image, title, rating, price, stock, short description, the purchase action through the native Elementor/WooCommerce Add To Cart widget or another compatible block, metadata, and tabs. Then the template is applied to a group of products through display conditions. The shopper opens different products, and Producter inserts the current product data into the same design positions.

Testing here must cover multiple products. Open a discounted product: Product Price should display the correct sale price. Open a product without a sale: the template should not leave an empty space where the sale layout was expected. Open a product without reviews: Product Rating should not generate a strange fragment of text. Open a product without attributes: Product Additional Information and Product Data Tabs should still look controlled instead of rendering as an empty block.

An important SEO nuance concerns Product Title and HTML Tag. A product page usually already has a primary H1 created by the theme or template. If you add Product Title as another large heading, do not create multiple H1s without a real reason. Use the HTML Tag setting deliberately: H2, H3, div, or span may be more appropriate inside a complex page where the H1 already exists. The widget heading should support the page structure, not create competing main headings.

Regular page or landing page scenario

On a regular page, Producter works well for targeted product inserts. For example, you publish an article or landing page and want to feature a single product with its real price, image, and stock. In that case, Product Price or Product Images should not try to use the "current product" because that context does not exist. You select a specific product in Products, and the data is then pulled from WooCommerce.

There is a risk of design desynchronization here. If you add Product Title for one product, Product Price for another, and Product Images for a third, the page may still look neat while showing mismatched data. After setup, always compare the title, image, price, and product link. A simple validation rule helps: "all widgets inside one product block must point to the same product."

It is better not to include Product Data Tabs in this scenario, because the documentation limits it to product pages. If you need to show specs on a landing page, use Product Additional Information or a separate text block instead of forcing tabs to work outside their intended context. That will save time when diagnosing an empty block.

How to think about page structure

Build the page around buyer questions, not around the widget list. At the top, the buyer wants to see what the product is and how much it costs. Nearby, they need visual confidence: photo, gallery, discount, rating. Next come the supporting arguments: short description, availability, specs, SKU, categories, or tags. Lower on the page come the details, reviews, additional tabs, and related blocks. Producter helps you arrange these answers across the screen, but it does not define the information hierarchy for you.

If the product is simple, you do not need to use all 9 widgets. An excessive set of blocks makes the page heavy and noisy. For a basic product, image, title, price, short description, stock, and metadata are enough. For a more complex product with specifications, add Additional Information and Product Data Tabs. For a product where trust depends heavily on reviews, move the rating higher and make the reviews link more visible.

Scenarios for different product types

Producter works best when the widget mix is chosen for the actual product type rather than inserted as the same package into every template. For a physical product, buyers care about photos, stock, and confidence around shipping. For a technical product, specifications, SKU, compatibility, and tabs matter more. For a promotional product, the discount, short description, and fast path to action matter most. The same grid can work for all of these cases, but the priorities within it should be different.

You do not need a separate template for every minor variation if the catalog is large. But it is useful to create 2-3 presentation variants: basic, technical, and promotional. In Elementor Theme Builder, this can be controlled through conditions, categories, or separate templates if that architecture fits the site. In this setup, Producter remains a set of building blocks, while the editor or store developer decides which block matters most in which context.

Physical product with a strong visual presentation

For clothing, accessories, home decor, and cosmetics, the first screen should answer one question quickly: "What does it look like?" Place Product Images in the strongest visual area, with Product Title, Rating, and Price nearby so the shopper keeps the image and the commercial information tied together. Product Short Description can be short, but it should still be specific: material, fit, use case, or one important selling point.

In this scenario, Product Stock helps not only communicate availability but also reduce hesitation before purchase. If the stock count is accurate, display it cleanly. If the store does not track exact quantities, do not fake scarcity. It is better to show a general in-stock status or omit the quantity than create a situation where the widget promises 3 units and the manager later cancels the order.

Product Meta usually should not dominate the first screen of a highly visual product. SKU and tags are useful for support and internal navigation, but buyers typically need photos, price, and reassurance first. Move Meta below the short description or place it in a compact line. Use Additional Information for size, composition, material, care instructions, and compatibility only if those fields are actually filled in as attributes.

Technical product with specs and SKU

For electronics, parts, equipment, and complex supplies, buyers often compare specifications. Here, Product Additional Information and Product Meta are not secondary blocks but key ones. SKU, category, compatibility tags, and attributes such as power, size, material, interface, or package contents help the buyer decide whether the product fits before moving toward purchase.

A strong structure here might look like this: title and short description at the top, price and stock beside them, a compact specs table below, and then tabs with the full description and reviews. Product Images still matters, but it should not crowd out the specs if the product is chosen primarily by technical parameters. For complex products, a split layout works well: visual on the left, price and key data on the right, and a wide Additional Information area below.

Testing the technical scenario should include products with different numbers of attributes. One product may have 5 specs, another 20, and a third none at all. If the design is built only for 5 rows, a long product will break the page rhythm. If it is built for 20, a short product may leave awkward empty space. Decide in advance where the block can collapse, wrap, or be replaced by an explanatory fallback.

Single-product promo page

On a regular page, Producter is convenient for promo scenarios: an article, a landing page, a seasonal collection, or a promotional block at the end of a review. Here the widgets do not function as a universal template, but as a dynamic insert for one selected product. The main rule is simple: every widget inside one promo block should point to the same product.

A strong promo block can be built from Product Images, Product Title, Product Price, Product Rating, and Product Short Description. Add Product Stock if availability matters to the decision. Product Meta and Additional Information only belong here if the product is purchased based on specifications. Do not move Product Data Tabs into a regular landing page, because it is meant for the product page context.

After assembling the promo page, review it like an editor: does the title match the image, is the price manually typed in nearby text, is the discount visible, does the link point to the correct product? If the page promotes a specific product, the whole chain should be unambiguous. This is especially important when the site publishes several similar promo pages and the designer copies sections between them.

Variable products and the limits of Producter

With variable products, some data may live at the parent product level while other data lives at the variation level. WooCommerce separately documents inventory handling for variable products at the product level, variation level, or in a mixed model. Producter displays product data through its widgets, but it should not replace correct variation selection, the purchase button, or WooCommerce Add To Cart logic.

If a product comes in different sizes, colors, or configurations, test how price, stock, and attributes behave after a variation is selected. Producter may display the general price and specs nicely, but the purchase action must remain compatible with WooCommerce. Do not hide required variation fields behind decorative blocks, and do not create a situation where the buyer sees a price but cannot tell which size or color is selected.

For variable products, the most useful principle is "native purchase flow first, visual enhancement second." First make sure the core WooCommerce variation selection and add-to-cart logic works. Then add Producter blocks around it: image, title, price, stock, meta, short description, and additional information. If the design makes variation selection harder to understand, roll back part of the styling and restore clarity.

Multilingual store and Producter labels

The CodeCanyon page lists WPML compatibility and the presence of a .pot translation file. That does not mean translation will configure itself without verification. Producter displays WooCommerce data, so on a multilingual site you need to test translated products, categories, tags, attributes, Meta labels, and custom before/after text separately.

For Product Meta, the labels matter especially: Category Single, Category Plural, Tag Single, Tag Plural, SKU, and Missing. If the site is bilingual, do not leave English labels on a Russian page or vice versa unless they are real UI labels that should remain unchanged. Check how WPML or your translation tool handles widget strings. If a string is not available for translation, add it through the string translation mechanism used in your stack.

For product data, the correct order is this: translate the WooCommerce product first, then categories, tags, and attributes, and only then test the Producter template on each language version. Do not try to translate specifications only in Elementor if they are supposed to remain part of the product database. Otherwise, filters, search, product cards, and the product page may start showing inconsistent wording.

Publishing, rollback, and template maintenance

Once Producter is configured successfully, there is one final stage that is often underestimated: publishing and maintenance. The product page directly affects sales, support, and customer trust. So a new template should be released as a store interface change, not treated as just another decorative content block.

The best publishing order is this: staging, test products, limited Elementor condition, public frontend check, cache clearing, validation of several purchase scenarios, and only then rollout to the catalog. If the store is large, add a short rollback plan: which old template to re-enable, which conditions to remove, which cache to clear, and who verifies the result. That plan takes only a few minutes, but it greatly reduces risk if a problem appears with the price, stock, or tabs.

Before enabling it for the full catalog

Create a simple internal checklist, not in HTML but for yourself or your team: product, state, what was tested, and the result. Include products in different conditions: on sale, not on sale, without SKU, with a long title, with variations, with multiple images, with attributes, without attributes, with reviews, and without reviews. Producter should behave predictably in every case.

Pay special attention to the purchase action block, even though Producter itself is not a checkout plugin. The customer should see the product, price, and add-to-cart path as one coherent flow. If you use the native Elementor Add To Cart widget or another compatible widget, it should not be visually separated from the price so strongly that it looks like it belongs to a different product.

After publishing

After enabling the display conditions, open several products from the public catalog without logging into the admin area. Check the desktop and mobile layouts, the price, stock, gallery, SKU, tabs, reviews, and add-to-cart behavior. Then clear the cache and repeat the check. If the site uses a CDN, validate the real public URL, not just the admin preview.

It is a good idea to keep a short log of the first changes: what was changed in the template, which products were checked, which CSS tweaks were added, and where those tweaks live. This becomes useful after Producter, Elementor, WooCommerce, or theme updates. If the price suddenly looks different a month later, the log will help you determine what came from Producter settings and what came from the theme or global CSS.

Detailed widget setup after installation

Producter configuration is built around three Elementor tabs: Content, Style, and Advanced. Content defines the logic: which product to use, whether to show a sale label, which text to place before or after a value, whether to enable a link, and whether to show the title. Style controls the appearance: spacing, typography, color, background, borders, radius, shadows, and hover states. Advanced handles standard Elementor wrapper settings such as positioning, classes, responsiveness, and additional section options.

A good setup process moves from meaning to styling. First decide which blocks the buyer actually needs, then place them on the page, then verify the data, and only after that refine colors, spacing, and hover states. If you start with visual styling first, it is easy to end up with a beautiful layout that fails on real products with long titles, different prices, empty SKU fields, and many attributes.

Product heading: Product Title

Product Title lets you display the product name and configure alignment, before/after text, HTML Tag, and a product link. For a Single Product template, check whether it duplicates the H1. If the theme already outputs an H1 above the content, Product Title inside Elementor is often better as H2, H3, or a regular block, especially when it does not sit at the very top of the page. If Producter is used on a regular page as a promo block, a link to the product can be helpful, but the link should not pull the buyer away before they have seen the price and key details.

Use Before and After text carefully. They work well for short clarifications such as "Model:" or "Series:", but not for promotional phrases. If a long phrase constantly appears before the title, the heading becomes harder to read on mobile. It is better to move that explanation into a separate text block.

Image and gallery: Product Images

Product Images is best configured with real photos in place. Enable Sale flash only after testing both a discounted product and a product without a discount. Set radius, spacing, and background so the sale badge does not cover an important part of the image. If the gallery includes thumbnails, check the spacing between them and the mobile view. Thumbnails should help users choose an angle, not turn into a tiny noisy strip.

Quality here depends on the WooCommerce Media Library. For the main image, WooCommerce recommends sufficiently large square or near-square source files, especially when buyers need to inspect details. If Producter shows a blurry result, first check the original files, thumbnail sizes, and WooCommerce Product Images settings rather than adjusting widget styles at random.

Price: Product Price

Product Price should be configured next to Add To Cart or another action block. The Sale price position setting is confirmed in Producter. For most stores, the most readable option is to make the current price larger and place the old price nearby or above it, but not in a way that makes the buyer wonder which amount is current. If sales are run through WooCommerce scheduled sales, do not copy the discounted price into plain text. Let WooCommerce manage the price and let Producter handle the output.

Price testing should include three products: one without a discount, one on sale, and one with a scheduled sale if that mechanism is used. Make sure the styling does not break the struck-through old price, the currency remains visible, and spacing does not collapse on long prices. For multilingual or multicurrency stores, also verify compatibility with any extensions that alter price formatting on the public frontend.

Stock: Product Stock

Product Stock should help the buyer decide, not pressure them artificially. If the product is widely available, a calm status line is enough. If stock is limited, before/after text can make the message easier to understand: "Only" before the number and "left in stock" after it, for example. But do not use labels like that if WooCommerce is not tracking exact quantities.

In the HTML Tag setting, do not choose a heading tag just for the font size. If the stock status is just a status line, div or span is often enough. Heading tags are better reserved for meaningful page headings. For styling, use normal and hover states only when the block is interactive or sits next to a link. Otherwise, a hover effect on a plain status line can be misleading.

Rating and reviews: Product Rating

Product Rating is most useful when the site has real reviews. Content includes Show reviews link and alignment, while Style includes star size, colors, and review text styling. If there are only a few reviews, do not make the block overly large. Shoppers quickly notice the mismatch: a large visual rating area built around a single review looks like an attempt to overstate trust.

If you enable Show reviews link, check where the link goes and whether the page actually includes an accessible reviews block. In a Single Product template, this is usually tied to the WooCommerce review tab. If the tabs are hidden, disabled, or replaced by a custom block, the link may lead to an empty area. In that case, set up the page structure first and only then enable the rating after the anchor behavior is verified.

Meta and Additional Information

Product Meta is best used where categories, tags, and SKU genuinely help. In Table view, the block becomes a clean information row or table, while Inline view works well for a compact area below the title. A Separator is useful when there are many items and they need visual separation. The Missing field can be useful for SKU: instead of leaving the area blank, you can show a calm label such as "SKU pending," but that should match your support workflow.

Product Additional Information works especially well for products with technical or size-related characteristics. If you sell clothing, size, material, and fit attributes should be stored as product data rather than only mentioned in the description. If you sell electronics, compatibility, wattage, and package contents should be visible on the product page. Then the widget outputs structured information instead of repeating description paragraphs.

Tabs and Advanced

Product Data Tabs belongs in the details area. It is not a first-screen block unless your store sells products where technical documentation matters more than the image. Configure tab navigation so the active state is obvious. The Style documentation confirms separate settings for Product Tabs and Product Tabs Navigation, including color, heading color, background, border, radius, shadow, and hover transition duration.

Use Advanced for responsiveness and utility classes. For example, you can assign the class producter-layout-check to a section and then add a small CSS tweak through Appearance > Customize > Additional CSS or via a safe snippets plugin. Do not edit Producter, Elementor, WooCommerce, or parent theme files. Any change inside plugin files will disappear after an update and make the site harder to maintain.

Practical example: building a product page with a verifiable result

Let us walk through a concrete scenario. You need to build a Single Product template for an accessories store: a large gallery, title, rating, discounted price, stock, short description, metadata with SKU and categories, additional specifications, and tabs for the description and reviews. The goal is a page where Producter outputs the current product data rather than manually frozen content.

Goal

The final template should work for every product in the selected category. When the manager changes the price, stock, SKU, image, or attributes in WooCommerce, the public page should update without any manual edits to the Elementor layout. Shoppers see the same structure, but different products display different data.

This is the key difference from a static landing page. In a static landing page, you can type a price into plain text and insert an image manually. In a product template, that is the wrong approach: the price should come from Product Price, images from Product Images, specifications from Additional Information, and SKU and categories from Product Meta. Otherwise, the store will quickly end up with mismatched information.

Preparation

Prepare 3-5 test products. One should have a discount, one should have a regular price, one should have multiple images, one should include filled-in attributes, and one should have limited stock. For each product, verify publication status, catalog visibility, featured image, short description, price, and category. If you plan to use reviews, enable them for the product and add a test review only on staging.

Create a new Single Product template in Elementor Theme Builder. Give it a clear name, for example Producter product layout test. Do not assign conditions to the full catalog yet. If Elementor offers a prebuilt block, you can still start from a blank canvas. In this example, understanding Producter mechanics matters more than copying someone else’s layout.

Build steps

1. Add a two-column structure: a wide area on the left for Product Images, and a right column for Product Title, Product Rating, Product Price, Product Stock, and the purchase action.
2. Drag Product Images into the left column. Verify that on a product page it uses the current product rather than a manual selection from Products. Configure Sale flash and thumbnail styles.
3. Add Product Title to the right column. Choose the HTML Tag based on the overall page structure. If an H1 already appears above, do not create a second H1.
4. Add Product Rating below the title. Enable the reviews link only if the page actually contains a reviews block or a Reviews tab.
5. Add Product Price and configure Sale price position. Test both a discounted product and a product without a discount.
6. Add Product Stock next to the price or below it. Set before/after text so the status is clear without making manual promises.
7. Add Product Short Description below the commercial block. Use before/after text only for a short utility label if one is needed.
8. Below the first screen, add Product Additional Information and Product Meta. For Meta, choose Table or Inline depending on the number of items.
9. At the end of the product area, add Product Data Tabs. Remember that this widget is designed for the product page and the current product context.
10. Save the template with Update, then assign publishing conditions first to one test category or one test product.

Verification

Open the template with several products. The discounted product should show the correct sale price, while the non-sale product should not leave behind an empty decorative area. A product with a gallery should have working thumbnails, while a product with a single image should not make the block look broken. For a product with attributes, Additional Information should display specs; for a product without attributes, the block should be hidden, replaced, or moved lower so it does not create a visual gap.

Then check the mobile layout. Switch to tablet and mobile inside Elementor, but also open the real public preview in the browser. The builder shows an approximation, while the theme, cache, script optimization, and WooCommerce styles may only reveal themselves on the frontend. Critical expected state: the shopper must be able to see the title, price, image, and purchase action without horizontal scrolling.

A detail people often miss

If you are using Producter on a regular page for a promo block, repeat the same steps but select the same product in every widget. Then open the actual WooCommerce product and compare the price, image, SKU, and stock. If the data does not match, check the Products field in each widget. This is a simple mistake, but it is a dangerous one: the page may promote one product, show another product’s price, and link to a third.

Quick takeaway: Producter works best when Elementor handles composition, WooCommerce remains the single source of product data, and each widget is tested against several real products.

Checking the result: data, responsiveness, SEO, and speed

After setup, you should not stop at a single glance inside the editor. Producter operates in combination with WordPress, WooCommerce, Elementor, the theme, and the browser. So validation should follow the full chain: product data, page context, visual layout, mobile view, SEO structure, performance, cache, and behavior after a product update.

Data check

Start with a simple comparison. Open the product in the WooCommerce admin and the public page in a neighboring tab. Check whether the title, price, discount, stock, SKU, categories, tags, short description, and attributes match. If a value changes in WooCommerce, it should update in the corresponding Producter widget. If it does not, look for cache, a manually selected different product, or static text left behind in the layout.

Check the price especially carefully. WooCommerce can show a regular price, a sale price, and a scheduled sale. Product Price should output the current price, not an old copy. If the price differs from the cart, that is already a critical issue. Producter is not responsible for recalculating checkout totals, but any visual price output still needs to match WooCommerce logic.

Responsive check

Elementor lets you control spacing, size, and alignment per device, and Producter follows that model through the Style and Advanced tabs. For a product page, it is important to check not only width but also the order of blocks. On mobile, the gallery usually comes first, followed by the title, rating, price, action, short description, and details. If Product Meta with long tags appears between the price and the action, it becomes harder for the shopper to complete the purchase.

Test long titles, long category names, an empty SKU, a large discount, a long list of attributes, and a multi-line short description. Styles that look clean on a demo product may fail on a real catalog. Use fixed spacing moderately, allow text wrapping, and do not make the price so large that the currency symbol drops to a new line.

SEO structure without unnecessary spam

Producter should not turn the product page into a set of repeated H1 tags. Product Title includes an HTML Tag setting, and that setting should be used carefully. If the page already has an H1, the additional product heading can be H2, H3, div, or span. If you are building a full Single Product template and Product Title is supposed to be the primary heading, verify that the theme is not still outputting the old H1 in parallel.

Product Meta and Product Additional Information can support search clarity when they output real categories, SKU, and attributes. But do not turn before/after text labels into a bundle of keywords. Buyers need clear names for characteristics, and search engines need structured, consistent content. The best SEO outcome for Producter is a clean product structure, correct headings, and visible information that matches WooCommerce data.

Speed and cache

Producter is presented as lightweight on product pages, but actual performance depends on the entire page: the number of Elementor sections, image sizes, the gallery, fonts, animations, third-party widgets, and cache behavior. Do not overload the first screen with shadows, multiple carousels, and large background images. Product Images should display high-quality photos, but it should not replace the work of proper media optimization.

After publishing, clear both site and browser cache, then check the page in incognito mode. If the price or stock does not update, temporarily disable HTML/JS/CSS optimization and exclude product pages from aggressive caching if the store uses dynamic pricing, live stock, or personalized conditions. For a simple store, disabling cache entirely may be unnecessary, but for price and stock it is essential that buyers see current data.

Safe visual improvements without editing the plugin

Sometimes, after configuring Producter, you need to fine-tune the appearance of the product area: tighten the spacing around price and stock, improve the distance between SKU and categories, or remove excessive spacing on mobile. It is best to make those adjustments through Elementor settings first. If that is not enough, use additional CSS only in a safe place: Appearance > Customize > Additional CSS, a child theme, or a trusted snippets plugin. Do not edit Producter, WooCommerce, Elementor, or parent theme files.

Because public Producter CSS classes are not confirmed in the available sources, it is safer to assign your own class to the Elementor container. Open the section or container that holds the product composition, go to Advanced, and add the class producter-layout-check. That keeps the CSS limited to this specific area.

.producter-layout-check .price {
  display: inline-flex;
  align-items: baseline;
  gap: 0.5rem;
  line-height: 1.2;
}

.producter-layout-check .stock,
.producter-layout-check .product_meta {
  margin-top: 0.75rem;
  line-height: 1.45;
}

@media (max-width: 767px) {
  .producter-layout-check .price {
    flex-wrap: wrap;
  }

  .producter-layout-check .product_meta {
    word-break: break-word;
  }
}

This snippet does not depend on Producter internals. It gently affects standard WooCommerce elements inside your section: the price, stock, and metadata. If a specific theme uses different classes, the tweak may not apply, but it should not break the rest of the site because it is limited to your container.

The test is straightforward: open a product with a long price, a product with a long SKU, and the mobile layout. The price should wrap without horizontal scrolling, the metadata should stay within the screen width, and the stock line should have normal spacing. To roll the tweak back, remove the CSS and the producter-layout-check class from the container. Do not leave several old versions of the same tweak in the code, because that makes troubleshooting harder.

Common Producter issues and troubleshooting

Most Producter issues are easier to diagnose by following a sequence rather than defaulting to "reinstall the plugin": page context, product data, widget settings, theme, cache, and plugin conflicts. That saves time because Producter almost always displays what it receives from WooCommerce and Elementor.

The widget does not show the product on a regular page

Symptom: Product Title, Product Price, or Product Images has been added to a regular page, but the block is empty or does not show what was expected.

A likely cause is that the widget is outside a product page and has no current product. The Producter documentation says that on a regular page, you need to select a product in Products. Check the Products field in every widget inside the same product block. If one widget has a product selected and another does not, the result will be incomplete.

Fix: select the same product in all widgets in that block, save the page with Update, clear the cache, and compare the public view with the WooCommerce product page. If the block is meant to be universal for all products, move it into a Single Product template and test the current product context.

Product Data Tabs is empty or does not work on a landing page

Symptom: the tabs are added, but nothing useful appears on a regular page.

In most cases, the cause is context. According to the documentation, Product Data Tabs works on a product page and receives the current product data. On a regular page without a current product, it is not the right widget. Another cause is that the product has no data for those tabs: no description, no reviews, or no visible attributes.

Fix: use Product Data Tabs inside a Single Product template or on a real product page. For a regular landing page, use Product Short Description, Product Additional Information, or a separate text block. If the Additional Information tab does not appear on the product page, check the attributes and the Visible on the product page setting in the WooCommerce product.

The price does not match the cart or the admin area

Symptom: Product Price shows an old price, another product’s price, or does not reflect the discount.

First check whether a different product was selected in Products on a regular page. Then check the WooCommerce product itself: regular price, sale price, sale schedule, and publication status. If the price is correct in the admin but outdated on the public page, clear the page cache and object cache. For stores with dynamic pricing, verify that caching is not conflicting with personalized price conditions.

Fix: make sure Product Price points to the correct product data, do not type the price manually into before/after text, and do not duplicate it in a regular text block. If the problem appears only with one theme, temporarily test a default theme or Storefront on staging, as WooCommerce recommends when diagnosing theme conflicts.

Stock does not appear or looks incorrect

Symptom: Product Stock is empty, shows only a general status, or does not show the quantity.

Product Stock depends on WooCommerce inventory settings. Check global stock management, the individual product settings, stock quantity, stock status, and product type. For variable products, stock may be managed at the variation level, and that needs to be taken into account during testing. If quantity tracking is disabled, the widget is not required to show a unit count.

Fix: configure inventory in WooCommerce, then update the product and the page. If the buyer does not need an exact quantity, use a calmer availability status and avoid before/after text that implies a specific count without real data behind it.

Additional Information does not appear

Symptom: Product Additional Information has been added, but the block is empty or does not show specifications.

Check whether the product has attributes, weight, dimensions, or other data that WooCommerce outputs in Additional Information. For attributes, visibility on the product page matters. If the attributes are used only for variations and are not meant to appear publicly, Producter cannot turn them into a full specs block without changing the underlying product data.

Fix: fill in the attributes in WooCommerce, mark them as visible where needed, update the product, and test Product Additional Information again. If some products do not have specifications, plan the design so it works without an empty block: hide the section, move it lower, or use a text fallback in a regular Elementor block.

Elementor freezes or Producter widgets disappear from the panel

Symptom: the editor loads slowly, the widget panel is empty, or Producter does not appear in search.

The cause may be plugin conflicts, insufficient resources, script optimization, an outdated Elementor version, or JavaScript being blocked in the admin area. The Producter changelog on CodeCanyon includes separate entries about improved Elementor compatibility and fixes, so keeping the plugin updated matters.

Fix: on staging, leave only WordPress, WooCommerce, Elementor, and Producter active, temporarily disable admin-side script optimization, and test the editor. Then re-enable plugins one by one. If the issue returns after activating a specific extension, document the conflicting plugin pair and contact the developer with a System Status report.

After publishing, the template applied in the wrong place

Symptom: the new layout appears on extra products or does not appear in the intended category.

The cause is tied to Elementor Theme Builder conditions. A Single Product template only goes live when Display Conditions are assigned, and those conditions define the scope. If you choose a condition that is too broad, the layout may apply to the whole catalog. If the condition is too narrow, you may not see it on your test product.

Fix: go back to Theme Builder, open the template conditions, and first assign the template to one test category. After verification, expand the scope. If old theme elements remain on the page, check whether they are being output by a separate template or a theme hook area.

When to roll the setup back: if the price, stock, or purchase action behaves unpredictably even after clearing cache and testing the theme, temporarily disable the new template for the live catalog and restore the default product page until the cause is identified on staging.

FAQ on setting up CodeCanyon WooCommerce Product

Can Producter be used without WooCommerce?

Not in any practical sense. The official Producter documentation states that Elementor and WooCommerce are required for further use. The widgets output WooCommerce product data: price, image, stock, metadata, short description, and tabs. Without WooCommerce, the data source simply does not exist.

Is Elementor Pro required?

For the Producter widgets themselves, the sources list compatibility with Elementor and Elementor Pro, but creating a Single Product template through Theme Builder is usually part of Elementor Pro. If you use Producter on a regular page with a selected product, the scenario may differ. For a universal product template, verify the requirements of your Elementor version and your current site setup.

Why does Product Data Tabs not work on a regular page?

According to the documentation, Product Data Tabs receives data on the product page and works with the current product. That context does not exist on a regular page. For a landing page with a selected product, use Product Short Description, Product Additional Information, or other widgets that support manual product selection.

What should I do if Additional Information is empty?

Check the WooCommerce product data: attributes, weight, dimensions, and attribute visibility on the product page. WooCommerce only shows Additional Information when there is something to display. Producter does not invent specifications on its own. It only renders the data prepared inside the product.

Can I manually type a price in Elementor next to Producter?

It is better not to do that on a live store. The price should come from WooCommerce through Product Price. Otherwise, after a discount, currency change, or product update, users may see one value on the page and another in the cart. Manual text is fine for explanations, but not as the source of the price.

How do I check that the product template is not hurting SEO?

Check the headings. The page should have one main H1, and Product Title should not create a duplicate if the H1 is already being output by the theme or another block. Use the HTML Tag setting in Product Title intentionally, and do not repeat the product name in several identical headings just to force keywords.

Why does the site still show the old price or stock after a product update?

The most common cause is cache. Clear the site cache, object cache, CDN cache, and browser cache, then test again in incognito mode. If the store uses dynamic pricing or personalized conditions, check the caching rules for product pages. Also make sure that a widget on a regular page is actually pointing to the updated product.

When might Producter be unnecessary?

If you already have Elementor Pro WooCommerce widgets or a large builder such as ShopEngine, JetWooBuilder, or WooLentor that covers all the product blocks you need, Producter may duplicate existing functionality. It makes the most sense when you specifically want the focused Merkulove widget set or Producter’s particular settings.

When CodeCanyon WooCommerce Product is the right choice

CodeCanyon WooCommerce Product is worth using if your store already runs on WooCommerce and Elementor, and your goal is to build a controlled product page or product block layout. Producter is valuable not because it promises to "build a store in one click," but because it offers a clear workflow: real WooCommerce data flows into dedicated Elementor widgets, while the designer controls placement, typography, colors, borders, spacing, and states.

Before implementing it, check the dependencies, product data quality, theme, WooCommerce templates, and the page scenario. After installation, start with a single widget on a regular page, then build a Single Product template on staging, test several products, and only after that expand the publishing conditions. This order reduces the risk that a beautiful layout ends up tied to a single product or starts showing empty data.

If you need more than product fragments - archives, filters, checkout, account pages, wishlist, and comparison - look at broader WooCommerce builders. But if your goal is to cleanly display Product Images, Product Price, Product Stock, Product Rating, Product Meta, Product Short Description, Product Additional Information, Product Data Tabs, and Product Title inside Elementor, Producter remains a direct and understandable tool.

Once the preparation is complete and you understand the limits of the current site, you can download the installation package, install it on a test copy, and verify the result using the workflow from this guide: product data, price, stock, tabs, mobile view, cache, and display conditions.