CodeCanyon WooLentor Pro - WordPress Plugin

Guide to Setting Up and Using CodeCanyon WooLentor Pro in WooCommerce

CodeCanyon WooLentor Pro is best viewed not as a standalone decorative widget pack, but as a working layer between WooCommerce, Elementor, the WordPress block editor, and the storefront itself. In this guide, we will walk through how to prepare the site, enable the right modules, build store templates, and verify that shoppers actually see the intended result.

This material does not repeat the product's short description. The practical logic matters more here: where the plugin changes default WooCommerce pages, which settings to touch first, where theme or cache conflicts are most likely, and how to check the product page, cart, checkout, emails, and customer account after changes are made.

In the official documentation, the product is increasingly referred to as ShopLentor, while the older WooLentor name still appears in URLs, documentation, WordPress.org, and the CodeCanyon listing. This article uses the task name, CodeCanyon WooLentor Pro, while ShopLentor is treated as the current official continuation of the same product.

What Problem the Plugin Solves and Where It Helps

Standard WooCommerce gives you a functional store, but its default pages often look very similar: the shop page, product page, cart, checkout, and account area depend heavily on the theme and usually require template customization. WooLentor Pro addresses exactly that issue by adding ready-made templates, widgets, blocks, and modules that let a site owner modify the store without editing theme files.

The main use case is building a WordPress store where key commercial pages can be managed in a visual editor. Official materials confirm template support for the shop page, single product, cart, checkout, My Account, thank-you page, quick view, and emails. That makes the plugin especially useful for stores that need to quickly adjust page structure for a promotion, a new category, a seasonal catalog, or funnel testing.

At the same time, the plugin does not replace WooCommerce itself. It works on top of it: products, categories, orders, shipping methods, taxes, and payments remain in WooCommerce, while WooLentor Pro helps display and control the presentation layer. The key takeaway for an administrator is this: WooCommerce should be properly configured first, and only then should the visual and functional layer of WooLentor Pro be added.

When the Product Is a Good Fit

The plugin is a strong fit for a store owner, webmaster, or agency that needs to build custom pages quickly without developing a separate theme. It is especially useful if the site already uses Elementor or the WordPress block editor and the team wants to manage product pages, catalog blocks, and cart elements from a familiar interface.

• You need to replace the default shop page with a manageable template that includes filters, a grid, sorting, and promo blocks.
• You need to build a more persuasive product page with images, price, rating, description, trust elements, upsells, and related products.
• You need to simplify checkout, modify fields, add steps, or make the cart easier to understand.
• You need to add sales modules such as quick view, wishlist, compare, badges, partial payment, notifications, or pop-up offers.
• You want to use ready-made templates as a starting point instead of building every page from scratch.

When Another Approach May Be Better

WooLentor Pro may be unnecessary for a very simple store with only a few products if the theme's default output already does the job. It is also not the best choice if the store runs on a heavily customized theme with its own template logic, where visual builders tend to conflict with developer code. In that case, it is better to review the architecture with the person maintaining the theme before moving forward.

Another important case is websites under heavy load with complex caching. A large number of widgets, dynamic blocks, and scripts requires careful performance testing. A visual editor is not a problem by itself, but every new store module adds another behavior layer that should be tested on real product, cart, and checkout pages.

What to Check Before Installing It on a Live Store

Before installing WooLentor Pro, preparation matters more than speed. The plugin affects critical store areas: the catalog, product page, cart, checkout, emails, and customer account. If you enable all modules at once on a live site, it becomes difficult to understand which exact setting changed the result.

Start with a site copy or staging environment. This is especially important for stores with active orders. On a test copy, you can enable a shop page template, check the product page appearance, place a test order, and review emails without risking your current sales funnel.

Basic Pre-Launch Checklist

• Make sure WordPress, WooCommerce, Elementor, and the active theme are updated to a supported state.
• Create a backup of files and the database before enabling Pro features for the first time.
• Document which pages are assigned in WooCommerce as Shop, Cart, Checkout, and My account.
• Disable extra plugins that duplicate the same functions: a separate quick view plugin, a separate wishlist plugin, or a separate checkout field editor.
• Prepare one simple test product, one variable product, and one sale product so you can test different template states.
• Clear the site cache and browser cache after enabling templates, otherwise you may keep seeing the old storefront.

Safe rollout tactic: enable only Template Builder and one template first, then verify the result. After that, add modules one at a time: checkout field manager, quick view, wishlist, compare, email customizer, or partial payment, only if the store actually needs them.

What Depends on the Theme and Other Plugins

The theme may already override WooCommerce templates. A caching plugin may combine or defer scripts. Another builder may output its own product templates. Because of that, the same WooLentor Pro template can behave differently on two sites. That does not automatically mean the product is broken - more often, several tools are trying to control the same page area.

Check whether the site already uses separate plugins for filters, variations, cart behavior, quick view, email templates, and custom fields. If functionality overlaps, keep one primary tool. The less duplication there is, the easier diagnostics becomes and the lower the chance that a shopper will see two different cart blocks or two different sets of checkout fields.

Installation and Initial Validation Without Unnecessary Risk

The general installation flow is similar to any WordPress plugin: upload the file through the admin panel, then activate the plugin. For the Pro version, the base WooLentor/ShopLentor plugin usually also needs to be present on the site, because some features and interfaces live in the shared core. There is no need to start with purchase, licensing, or external steps - within this guide, what matters is that you already have the files and that you validate the setup correctly after activation.

1. Open Plugins in the WordPress admin panel and make sure WooCommerce is active.
2. If the base plugin is not installed yet, install it from the WordPress.org directory or the developer's official source.
3. Upload the Pro version ZIP file via Plugins - Add New - Upload Plugin.
4. Click Activate and check whether WooLentor or ShopLentor appears in the admin menu.
5. Go to WooLentor - Settings and do not enable all modules at once.
6. Open the shop page in a new tab and confirm that it still displays products.

After activation, do not rush into importing templates. First, confirm that the site still works in its original state: the catalog opens, the product page loads, the add-to-cart button works, and the cart and checkout show no errors. This is your control point: if a problem appears already here, fix it before configuring templates.

First Test After Activation

Create a short three-page check: the catalog, one product, and the cart. Add a test product to the cart, proceed to checkout, and then go back. If everything works at this stage, you can move on to Template Builder. If not, temporarily disable the new modules and check the error log, browser console, and cache conflicts.

Template Builder: How to Connect the Template, Editor, and Final Result

The most important part of WooLentor Pro is not the number of ready-made elements, but the logic behind template assignment. In the official guides, templates are created through WooLentor - Template Builder: the user clicks Add New, enters a name, selects a template type, chooses an editor, picks a ready-made design, and optionally marks it as the default template.

This logic works like a bridge. On one side is WooCommerce with its system pages and product data. On the other is Elementor or the block editor, where you place widgets, blocks, and visual elements. WooLentor Pro connects those sides: the template receives WooCommerce data and outputs it in the required layout.

Which Templates to Configure First

Do not start with edge cases. Configure what most shoppers actually see first. For a typical store, the order is usually: shop page, single product, cart, checkout, thank-you page, and My Account. Email templates are better handled after checkout has already been validated, because emails depend on order statuses and customer data.

How Not to Break WooCommerce System Logic

The most common template mistake is building a beautiful page while forgetting a required system element. On a product page, that might be the add-to-cart button or the variation block. On the cart page, it could be the product table and totals. On checkout, it could be the payment form and order review block. If an element is missing, the page may look complete, but the customer cannot complete the action.

Do not validate the template only visually. Open the product as a customer, select a variation, add the item to the cart, change the quantity, apply a test coupon, and go all the way to the payment step. A working template is not the one that looks good in the editor, but the one that preserves the path to placing an order.

Modules After Installation: What to Enable Right Away and What to Enable Only as Needed

WooLentor Pro includes many modules: some affect store pages, some affect checkout, and others focus on marketing or catalog management. The temptation to turn everything on at once is understandable, but for a production store, that is a poor strategy. The more modules you enable, the more scripts, settings, conditions, and conflict points you introduce.

A better approach is to work from a specific goal. If you need to replace default pages, enable Template Builder. If the issue is unnecessary checkout fields, enable Checkout Field Manager. If you want shoppers to view a product without leaving the current page, enable Quick View. If you need better emails, enable Email Customizer. If you need partial payment, enable Partial Payment and test it on a dedicated product.

Core Module Groups

• Pages and templates: shop, product, cart, checkout, account area, thank-you page, quick view, and email templates.
• Catalog and product pages: product grids, filters, badges, variations, quick view, search, compare, and wishlist.
• Checkout: field management, multi-step checkout, express checkout, side mini cart, and redirect to payment.
• Sales and marketing: popup notifications, cross-sells, order bump, timers, coupons, abandoned carts, and email automation.
• Store management: store vacation, post duplication, reporting emails, partial payment, and related utility features.

Settings Worth Checking First

Enable only one module and review its own settings first. Many modules have an activity toggle, a separate settings page, and fields for labels, positions, display conditions, or templates. After saving, be sure to clear the cache and open the storefront as a guest.

For Checkout Field Manager, the official material shows working with billing, shipping, and additional fields, as well as adding custom fields with a name, type, key, label, value, and validation. Here it is especially important to watch the field key: if the key contains spaces, is duplicated, or conflicts with an existing field, the data may not be saved the way the administrator expects.

Email Customizer is enabled through WooLentor - Settings - Modules, after which the template is created through Template Builder. The documentation lists the standard WooCommerce emails: new order, canceled order, failed order, processing order, completed order, refunded order, invoice, customer note, reset password, and new account. Before publishing an email template, do not validate only the design in the editor - check a test send and confirm that order data is present.

When a Setting Is Better Left Off

If a module changes a critical part of the funnel, enable it only when there is a clear benefit. For example, a multi-step checkout may be helpful for a long form, but excessive for a store that only needs two fields. Partial Payment is useful for expensive products or preorders, but not every catalog needs it. Sales Notification can increase trust if it shows real and accurate events, but it will annoy users if it appears too often.

After every questionable setting, leave yourself a rollback path: record which module you enabled, which fields you changed, which template you assigned as default, and what the previous state was. That saves hours of diagnostics when a template looks correct in the editor but does not match the result on the live site.

Scenarios That Show Where WooLentor Pro Shines

The product offers too broad a feature set to use it as just "another Elementor element pack." It is far more effective to connect its features into real scenarios. That helps the administrator understand which module owns which part of the customer journey and what exactly needs to be tested.

Catalog with Filters and Quick View

For a store with a large assortment, a nice-looking grid is not enough - shoppers also need to find products quickly. This scenario usually combines the Shop template, Product Grid, filters, sorting, quick view, and clear product status indicators. A visitor should be able to understand the price, availability, variations, and main call to action without unnecessary page changes.

The validation is straightforward: open a category, apply a filter, switch between grid or list view, open quick view, and add a product to the cart. If pagination disappears after filtering, styles break, or quick view shows incomplete data, look for a conflict with the theme, cache, or a second filtering plugin.

Product Page for a Higher-Value Purchase

On a single product page, you can build a trust section, gallery, availability block, variations, reviews, additional details, related products, and the purchase button. For higher-priced items, features like size chart, product badges, sticky add to cart, video gallery, or partial payment can be useful if that scenario is supported in your setup.

The key here is not to overload the page. The more expensive the product, the clearer the structure should be: photos and key details at the top, purchase conditions next to the button, details and reviews below, and additional offers presented without pressure. If the shopper cannot see the price, availability, or purchase button, a beautiful template is actively hurting conversions.

Checkout Without Extra Fields

Checkout Field Manager is useful when the default WooCommerce form collects too much information or lacks a specific field. For example, a local delivery store may remove unnecessary company fields, add a "delivery instructions" field, and make the phone number required. The key is not to remove fields that shipping, payment, tax logic, or integrations depend on.

After changing the form, create a test order and check where the new field appears: on the order page in the admin panel, in the email, in the customer account, and in the shipping integration, if one exists. If the data is visible only on checkout and disappears afterward, the setup is incomplete.

WooCommerce Emails Styled to Match the Store

Email Customizer helps bring transactional emails into a consistent visual style. But emails are a technical part of the store, not a standard landing page. They cannot lose the order number, item list, totals, addresses, status, or links. A good email template is clean, readable, and preserves all required WooCommerce data.

Check emails across several order statuses. For the administrator, new order notifications matter most; for the customer, processing, completion, refund, invoice, and password reset emails matter most. If data is missing in an email, go back to the template and add the required order widgets instead of decorating the message with more banners.

Practical Example: Build a Product Page and Run a Test Order

Let us walk through a realistic scenario for a clothing or accessories store. The goal is not simply to "make it look nice," but to go from configuration to a verified order flow. We create a single product template, add the required elements, and then test variations, cart behavior, checkout, and email delivery.

Goal

You want a product page with a clear gallery, price, variations, purchase button, short description, delivery block, related products, and a verified path into the cart. If the business needs it, you can also prepare a checkout field for delivery notes.

Preparation

• WooCommerce must be active on the site, and at least one variable product must already exist.
• Elementor or the block editor must open templates without errors.
• The shop, cart, checkout, and account pages must already be assigned in WooCommerce.
• On the test copy, duplicate quick view, wishlist, checkout field editor, or email customizer plugins should be disabled.

Steps

1. Open WooLentor - Settings - WooCommerce Template and enable Template Builder.
2. Go to WooLentor - Template Builder and click Add New.
3. Enter a clear name, for example Single product - main test, choose the Single type, and select the editor your team actually uses.
4. Select a ready-made sample design or a blank template, enable Set Default only in the test environment, and save the settings.
5. Open the template in the editor and add the required product page elements: image, title, price, rating, short description, variations, purchase button, description, additional information, and related products.
6. Save the template, open the product as a guest, and confirm that data is pulled from the actual product rather than showing empty editor placeholders.
7. Add the product to the cart, change the quantity, go to checkout, and place a test order using an available safe testing method.
8. Check the order in the admin panel and review the customer email. If Email Customizer is enabled, make sure the email template has not lost the order data.

Result Validation

The outcome is successful if the product page opens without errors, variations can be selected, price and availability update correctly, the purchase button adds the product to the cart, the cart recalculates totals, checkout creates the order, and the emails contain clear data. Validate the entire flow, not just an individual page, because WooLentor Pro often improves several connected WooCommerce areas at once.

A Common Detail That Often Gets in the Way

If the template looks correct in the editor but does not apply on the live page, check the template type, the Set Default flag, WooCommerce system page assignments, and the cache. For product archives, it also matters that WooCommerce correctly recognizes which page is the shop page and that the theme is not overriding the output with its own template file.

Result Validation: What to Check After Every Change

After configuring WooLentor Pro, what you need is not an abstract "design review," but a step-by-step validation of the customer journey. Split the review into the admin panel, storefront, order data, emails, and performance. That way, a problem will not get lost behind attractive design blocks.

Storefront

Open the store as a new visitor: not logged in, in a private window, and at mobile width. Check the catalog, product page, cart, checkout, account area, and thank-you page. If a module affects a pop-up, quick view, or mini cart, test not only whether it opens, but also whether it closes correctly, adds products properly, updates quantity, and lets the user move forward.

Admin Panel and Order Data

If you changed checkout fields, open the created order and verify that the data was saved. If you enabled partial payment, check the payment status and whether customer-facing messages are clear. If you changed the email template, compare the admin email and the customer email: both should contain the required information, but they do not need to look identical.

Speed and Cache

For store pages, design improvements should not break performance. After enabling heavier widgets, test the product page and checkout first without script combining, then again with cache enabled. If quick view, filters, variations, or the mini cart stop working after optimization, configure exclusions in the cache plugin for dynamic WooCommerce pages and scripts.

Safe CSS Refinement Without Editing the Plugin

If you need to fine-tune the appearance of a block, use a CSS class that you added yourself in Elementor to the section or widget. Do not depend on the plugin's internal classes unless they are explicitly documented, because they may change after an update. The example below makes product cards more even only inside your own shoplentor-guide-grid section.

.shoplentor-guide-grid .woocommerce-loop-product__title {
  min-height: 2.8em;
}

.shoplentor-guide-grid .price {
  display: block;
  margin-top: 8px;
}

.shoplentor-guide-grid .button {
  width: 100%;
  text-align: center;
}

Add the shoplentor-guide-grid class in the editor section settings, place the CSS in a child theme or the theme's safe custom CSS area, and then check the catalog on desktop and mobile width. The rollback is simple: remove the CSS or remove the class from the section. This approach does not alter the WordPress core, WooCommerce, the theme, or WooLentor Pro.

Compatibility, Multilingual Use, and Limitations

The official documentation includes separate materials for WPML and Polylang, which means multilingual stores are a real supported use case for this product. But multilingual setups always require validation: you are not only translating page text, but also templates, widget strings, checkout field labels, emails, URLs, and WooCommerce system elements.

If the store runs in multiple languages, do not duplicate a template blindly. Configure the main language first, then create the translated template or translated strings using the supported mechanism. Check that languages are not mixed on the product page, that checkout fields have the correct labels, and that emails are sent in the proper language.

Cache, Optimization, and Dynamic Pages

Cart, checkout, and account pages cannot be cached as aggressively as static pages. They depend on the current user, cart contents, the WooCommerce session, and login state. If, after enabling WooLentor Pro, a shopper sees someone else's cart, outdated totals, or a broken button, check cache rules first, not template design.

Security and Updates

Public security databases show that the product has had vulnerabilities in the past that were later fixed. The practical conclusion is not that the plugin should be avoided, but that the store should be updated regularly and that access to the editor and templates should be limited. Do not give template editing permissions to users who only need to manage orders or products.

For a store with active sales, it is useful to adopt one rule: any WooCommerce, Elementor, theme, or WooLentor Pro update should go through a staging copy first, then a short test order, and only after that be applied to the live site.

Team Roles, Access, and a Controlled Template Change Process

WooLentor Pro is often used not only by store owners, but also by designers, content managers, marketers, and developers. Each role has its own area of responsibility. If every user gets the same level of template access, the store quickly turns into a collection of random edits: one person changes the product page, another edits checkout, a third updates an email, and then nobody understands why the test order stopped working.

Split the work into layers. A content manager can change products, images, descriptions, and categories. A marketer can prepare copy for promo blocks, but does not need to assign a checkout template as default. A designer can work on the visual grid, but should understand which WooCommerce elements are system-critical and must not disappear. A developer or administrator is responsible for updates, cache, conflicts, backups, and pushing changes to the live site.

What Should Not Be Handed Off to Casual Editors

Critical areas include Template Builder, checkout field settings, email templates, partial payment, multi-step checkout, redirects, and any modules that affect order creation. These settings directly affect revenue, customer data, and purchase confirmations. If an editor only needs to change text on a product page, do not give them the ability to change the template type or remove checkout fields.

The principle of least privilege is not bureaucracy here - it is practical store protection. The fewer people who can change system templates, the easier it is to find the cause of an issue after an update or a failed edit. If the team is large, keep a simple change log: date, who made the change, which template, which module, and what was checked after saving. A log like this is especially useful before seasonal sales and major ad campaigns.

How to Publish Changes Without Chaos

1. First make the change on a staging copy or in a draft template.
2. Check the live-facing page, the mobile layout, and the full path through a test order.
3. Take a screenshot or short recording of the result so the team clearly understands what should appear on the site.
4. Deploy the change to the live site during a low-traffic period.
5. Clear the cache and repeat a short order test after publishing.

If the change does not pass validation, do not try to fix it by layering ten random actions on top. Roll back the last step, restore the previous template, or disable the last module you enabled. WooCommerce pages respond best to disciplined small changes: one template, one setting, one check, one conclusion.

When to Bring in a Developer

You need a developer when the problem involves the theme, server limits, PHP error logs, custom WooCommerce hooks, script optimization conflicts, or payment and shipping integrations. Do not ask a designer to "just fix" checkout if the error appears only after selecting a specific shipping or payment method. At that point, it is no longer a visual issue.

A developer is also helpful when you need a customization that will survive updates. In those cases, use a child theme, safe custom CSS, a verified snippet, or cache configuration. There is no reason to edit WooLentor Pro files directly: such changes will disappear on update and make long-term maintenance harder.

Video: Installing WooLentor Pro and Getting Started

Below is a focused video on installing WooLentor Pro. It is useful for the intent cluster "how to install WooLentor Pro" and covers the initial stage: where to upload the ZIP file in the WordPress admin panel, how to activate the plugin, and where to find its menu. Use it as a visual aid for installation, but handle store configuration and order validation using the steps from the guide above.

Common WooLentor Pro Issues and Diagnostics

Problems after enabling the plugin are usually caused not by a single button, but by the interaction between WooCommerce, the theme, Elementor, cache, and the selected module. That is why diagnostics works best when you move from symptom to cause: what the user sees, where it happens, which setting controls that area, and how to roll back the change safely.

The Template Is Created but Does Not Apply on the Site

Symptom: the template looks correct in the editor, but the live shop or product page still shows the old design. Possible causes include Template Builder not being enabled, the wrong template type being selected, Set Default not being enabled, incorrect WooCommerce system page assignment, or the theme overriding the output.

Check WooLentor - Settings - WooCommerce Template, then open Template Builder and make sure the template type matches the page: Shop for the shop page, Single for a product page, Cart for the cart, and Checkout for checkout. After that, clear the cache and open the page in a private window.

The Elementor Panel Does Not Load After Activation

The official common issues section links this problem to low server limits and recommends checking the PHP memory limit and max execution time. Do not change server parameters blindly on a production server: first review the error log, site health, hosting limits, and conflicts with other heavy plugins.

If the problem disappears after temporarily disabling some modules, the site is likely hitting a resource ceiling or an editor loading conflict. In that case, keep only the required modules enabled, update plugins, and discuss raising limits with your hosting provider.

Checkout Looks Correct but the Order Is Not Created

Symptom: the form appears, but after the customer clicks the button, an error appears or the order never shows up in the admin panel. Check whether you removed a required field that shipping, payment, or tax logic depends on. If you added a custom field, make sure its key is unique and does not contain problematic characters.

Roll back the latest Checkout Field Manager changes, restore the default fields, and run the test order again. If the default form works, reintroduce changes one at a time: first labels, then order, then new fields, then validation. That is the fastest way to isolate the exact failure point.

Quick View, Mini Cart, or Filters Do Not Respond

These features often depend on JavaScript. If modal windows stop opening, the cart stops updating, or filters stop changing the product list after optimization, temporarily disable script combining, deferred loading, and minification. Then add exclusions for WooCommerce pages and the scripts responsible for dynamic elements.

WooCommerce Emails Lost Order Data

Email Customizer changes how the email looks, but the message still has to preserve system data. If the email is missing the order items, addresses, totals, or status, go back to the template and add the შესაბამის order elements. Check multiple email types, because admin emails and customer emails serve different purposes.

The Page Layout Changed After an Update

If the layout changes after an update, first clear the cache and resave the template. Then check whether any of the widgets used in the template have changed. Do not fix the issue by editing plugin files: those changes will disappear on the next update. Use template settings, CSS in a child theme, or safe custom CSS instead.

When CodeCanyon WooLentor Pro Is the Right Choice

CodeCanyon WooLentor Pro is worth using if you need a manageable WooCommerce store where catalog pages, product pages, cart, checkout, emails, and the customer account can evolve without constant theme editing. Its strength shows up in the full chain: Template Builder defines structure, widgets output product data, modules add sales behavior, and result validation protects the customer journey.

Do not turn installation into a race to enable the highest number of features. First decide which part of the store needs improvement, then enable the relevant template or module, run a test order, and only after that move to the next area. That approach makes the plugin a useful tool rather than a source of random conflicts.

If, after validation, you can see that the product fits your store structure, you can download CodeCanyon WooLentor Pro and start with a staging copy of the site. The final benchmark is simple: the shopper should understand the product faster, move through cart and checkout without errors, and the administrator should see correct order and email data.