CodeCanyon ARPrice - WordPress Plugin

A Practical Guide to Setting Up and Using CodeCanyon ARPrice

CodeCanyon ARPrice is not just for making a pricing table look good. In real-world use, it is a tool that connects pricing tiers, feature comparisons, call-to-action buttons, responsive display, click analytics, and sometimes third-party flows such as WooCommerce, lead forms, or subscription pages. In this guide, we will walk through how to approach setup so the table actually helps visitors choose a plan instead of becoming just another decorative block on the page.

This guide is written for site owners, webmasters, and WordPress editors who already have the plugin ZIP file and need to publish a clear pricing table on a services page, SaaS site, course page, membership site, agency website, or team showcase. Below, we cover site preparation, installation, template selection, column setup, billing period toggles, shortcode publishing, page builder workflows, result validation, and troubleshooting common issues.

I will not rehash the product listing. It is much more useful to understand the logic behind the setup: what data to prepare before opening the editor, which settings affect appearance, where responsive layouts usually break, how to safely verify button clicks, and when ARPrice is better kept simple. We will also look at comparable solutions so it is clear when this plugin is justified and when a simpler option may be the better fit.

Where ARPrice Adds Real Value and Where It May Be Overkill

The main job of the plugin is to make plan comparisons easy to understand. On a pricing page, visitors should be able to see the differences between plans, the price, the key limits, the action button, and, if needed, a switch between billing periods. ARPrice covers this use case with ready-made templates, a visual editor, column settings, effects, tooltips, responsive behavior, and several publishing methods for the site.

The strength of CodeCanyon ARPrice is not just a single table style, but the range of scenarios built around it. The sources confirm ready-made samples, visual editing, price toggles, separate section settings, shortcode support, a widget, support for Gutenberg, Elementor, Beaver Builder, and other builders, template import and export, as well as view and click analytics. That makes the plugin especially useful when the pricing table is a meaningful part of the conversion flow rather than a random page element.

Strong use cases include:

• A SaaS pricing page that needs a monthly and yearly billing switch.
• An agency site comparing service packages with different scopes of work.
• An education project where plans differ by access to lessons, materials, or consulting.
• A membership or subscription site where the table leads to a signup form or plan page.
• A team showcase page, if you need to display staff cards, roles, and profile links using a suitable template.
• A visually rich comparison page where icons, tooltips, images, video, or even a map inside sections are genuinely helpful.

ARPrice may be unnecessary if all you need is one very simple two-column table with no design layer, no toggle, and no reuse. In that case, a native WordPress block or a lightweight free plugin may offer fewer settings but be easier to maintain. Another case where you should think twice is a site with a very tight performance budget. The official page says assets are optimized to load only where the shortcode is used, but final speed still depends on the theme, caching, the number of tables, icons, fonts, and media inside the columns themselves.

Practical rule of thumb: choose ARPrice when the pricing table needs to function as a standalone sales and navigation block. If the table is only meant to be a static list, first check whether standard WordPress blocks already solve the problem.

What to Prepare Before Installation and First Launch

The most common mistake with pricing tables is starting with the visual design. People see dozens of templates, pick the flashiest one, and then try to force unprepared pricing plans into it. A better approach is to gather the data and constraints first. That will help you quickly determine how many columns you need, which comparison rows matter, whether you need a billing period toggle, and what each button should do after a click.

Plan Content and Comparison Rules

Before installation, prepare a working table in a document or spreadsheet. It should include plan names, prices, billing periods, 5 to 8 key features, user or usage limits, a short subtitle under each plan name, and the button action. If you have more features than that, do not move all of them into the visible table. On a sales page, it is usually better to show the main differences and leave the details for an FAQ, an expandable section, documentation, or a separate page.

For ARPrice, it is especially important to decide in advance whether you have one pricing state or multiple states. The official documentation confirms a toggle with up to eight steps, and the marketing page refers to common periods such as monthly and yearly. But just because the technical option exists does not mean you should show eight variations. The more steps you add, the harder it becomes for visitors to compare offers, and the more carefully you need to test the mobile view.

WordPress Technical Conditions

The documentation lists minimum requirements for older PHP and WordPress versions, while CodeCanyon claims compatibility with modern WordPress branches up to 6.8.x. In practice, before installation it is better to check not only formal compatibility but also the site environment:

• The site has a backup of both files and the database, especially if tables will be imported or updated.
• The theme does not aggressively override default button, list, and shortcode styling with global CSS rules.
• Your caching plugin lets you clear page cache after inserting the table.
• If you need Elementor, Beaver Builder, WPBakery, or Gutenberg, the publishing method is aligned in advance with the page editor currently in use.
• If buttons lead to WooCommerce, forms, or subscriptions, those target elements have already been created and tested separately from the table.

Also check the user role. Plugin configuration, shortcode insertion, and page editing usually require administrator access or editor-level permissions with access to the relevant areas. If a content manager can see the page but cannot see the ARPrice menu or insert the builder block, the issue may be permissions rather than the plugin itself.

Security and Updates

With a commercial plugin, it is especially important not to stay on old builds for too long. Public security databases include records of vulnerabilities in older ARPrice versions and in a separate free plugin with a similar name from the WordPress directory. There is no need to turn that into panic in this guide: the takeaway is simple - use the current patched version, update on a site copy first, and do not leave old archives active in production.

Before updating, the developer documentation recommends backing up the database, tables, ARPrice uploads folder, and the plugin folder itself. That is sensible not only for major releases. Pricing tables often contain a lot of manual text, colors, images, and links, so losing a template can be more noticeable than it seems.

Installation and First Check in the WordPress Admin

Installing ARPrice is similar to installing most commercial WordPress plugins: you either upload the ZIP through the admin panel or move the plugin folder to the server. The documentation describes both methods: through Plugins - Add New - Upload and by uploading the arprice folder to wp-content/plugins/. This article does not cover the purchase flow, license entry, or how to obtain the commercial archive, because that is not part of configuring the functionality on the site.

After activation, an ARPrice section should appear in the left-side WordPress menu. The first check should not stop at seeing that the plugin is active. You need to confirm that the plugin panel opens, the template list is available, you can create a new table, and the editor does not throw a JavaScript error while loading.

Quick Post-Activation Test

1. Open the WordPress admin and make sure ARPrice appears in the left menu.
2. Go to the new table creation screen and open the list of built-in templates.
3. Select any simple template in preview mode, but do not publish it on a main page yet.
4. Save the test template with a clear name, for example Test Pricing Table.
5. Copy the shortcode from the table list or the editor and paste it into a draft page.
6. Open the page in a private browsing window and verify that the table is visible without logging in.

If the test template saves correctly and renders on the page, you can move on to the real setup. If not, do not start by changing colors or effects. First check user permissions, cache, JavaScript minification conflicts, the page editor you are using, and browser console messages.

What Not to Do on Day One

Do not move all of your plans into a complex animated template before basic validation. Do not enable every icon library, media feature, map, video, and custom code option at once. Do not place the same test shortcode on a dozen pages, because later it becomes harder to tell where the cache is holding on to an old version. In the first 20 minutes, the goal is only one thing - confirm that the chain "ARPrice editor - saved template - shortcode - front-end page" actually works.

How to Choose a Template Without Losing the Meaning of Your Plans

ARPrice offers built-in templates and a separate section for installing ready-made samples. The documentation says templates can be previewed, selected, cloned, and customized, while ready-made samples can be installed from Create New - Install Free Samples when that feature is enabled on the site. That is convenient, but template selection should be driven by content, not by how impressive the thumbnail looks.

A template is a good fit if it helps people compare offers. For three SaaS plans, the familiar "Basic - Pro - Enterprise" layout works well. For an agency with many comparison rows, even column heights, readable differences, and a calm button style matter more. For a team showcase, you can hide unnecessary price and button sections, since the documentation confirms that separate column parts can be hidden, including the header, price, body, and button.

Selection Criteria

• Number of columns. The template needs to remain readable with your real number of plans, not just in the demo.
• Row length. If features are wordy, choose a calmer grid and avoid columns that are too narrow.
• Button contrast. The main plan button should stand out, but it should not visually fight with the rest of the page.
• Toggle support. If you have monthly and yearly billing, check how the toggle looks in the selected template on a mobile screen.
• Ability to disable unnecessary sections. For a team showcase, consulting packages, or service cards, hiding the price or bottom section may be useful.

If you are migrating an older table, do not try to reproduce every pixel of the previous layout right away. ARPrice supports importing data from other templates and importing and exporting its own tables, but when the design changes you still need to review rows, line breaks, icons, and buttons. A good outcome is when visitors understand plan differences faster, not when the new table merely looks superficially similar to the old one.

The ARPrice Editor: Configuring Columns, Sections, and Responsive Behavior

The ARPrice editor is built around one important idea: you configure the table visually and see changes immediately. The documentation separately covers template width, naming, saving, preview, column parameters, colors, fonts, tooltips, effects, custom CSS, and warnings about invalid HTML. That makes the editor convenient, but it also increases the risk of accidentally changing the look of the entire template when you only meant to fix one column.

Template Width and Column Width

In the actual editor, the template width defines the frame within which the columns sit. The documentation explains the simple math: if the template width is 1000 pixels and a column is 200 pixels wide, five columns fit in a row. In practice, though, you should not think only in division. You need to leave space between columns, account for theme padding, and verify that the block does not run into the edges of the page container.

For a typical site, start with three or four columns. If you have more plans, consider splitting them into two tables, for example "For Individuals" and "For Businesses." ARPrice supports an unlimited number of columns and rotating columns, but that does not cancel the UX rule: visitors should be able to compare options without a horizontal marathon.

How to Check Width Without Guesswork

1. Save the table and open the page in a normal browser window.
2. Gradually reduce the window width and watch where text begins to wrap or compress.
3. Check mobile mode in both the ARPrice preview and the browser dev tools.
4. If the table becomes cramped, reduce the number of visible columns on tablets and phones, or simplify the text in the rows.

Do not try to fix overflow by only shrinking the font. A price and button that are too small are worse than a clean column wrap. If the table compares many features, some details may belong in a separate block below.

Global vs. Local Changes

In ARPrice, some settings apply to all columns in the template, while others belong to a specific section. For example, column width, spacing between columns, responsive columns, and hiding empty rows relate to the overall structure. Meanwhile, the header, description, price, body, and button are edited as separate table parts. Good configuration starts with the overall grid, then moves to content, and only then to visual details like colors.

Mandatory rule: save a copy of the original template first. In the ARPrice saved table list, you can see actions such as edit, preview, duplicate, and delete. The duplicate is your fallback if you lose a working layout while experimenting with colors, border radius, or effects.

Responsive Columns and Mobile Views

The documentation describes the Responsive Column and Display Columns settings for mobile and tablet views. In practical terms, this means you can allow width to adapt automatically or keep a fixed width, and you can also specify how many columns to show on different screen sizes. For most pages, it is best to start with responsive columns and then separately verify the number of visible columns on a phone.

If visitors need to compare three plans but on mobile only see one column at a time, use clear plan names and do not bury the important differences too far down. If you have four or five plans, check whether the table turns into a long vertical strip. Sometimes the winning plan should appear first after the intro rather than third, because on mobile the visitor may never scroll that far.

Price Toggles, Effects, and Clickable Columns

The price toggle is one of the most visible ARPrice features. The documentation confirms support for Toggle Price, copying data from the first step to other steps, multiple toggle styles, a separate mobile view, title positioning, tab labels, and a default step. On the plugin's marketing page, the toggle is described as a way to compare different billing periods or offer sets.

When to Enable the Toggle

A toggle makes sense when every plan follows the same variation logic. The classic example is monthly versus yearly billing. A more complex example is "For 1 Site," "For 5 Sites," and "For Agencies," but only if visitors immediately understand why they are switching the table. If the toggle changes too much text, visitors stop reading the table as one comparison and start getting confused.

For CodeCanyon ARPrice, a safe setup sequence looks like this:

1. Enable Enable Toggle Price only after the base table is already saved.
2. Copy the first step's data into the remaining steps if the plan structure is the same.
3. Change only the price, period, one or two value rows, and the button label where that difference is real.
4. Choose a toggle style that does not compete visually with the table buttons.
5. Set the default step to match the page's primary offer.
6. Check the mobile style: a standard column layout and a dropdown can behave differently.

Effects and Animations

ARPrice supports animations, hover effects, rotating columns, and visual emphasis. These can help attract attention, but they become harmful quickly if every plan is "moving" and fighting for attention. On a conversion-focused page, it is usually enough to highlight one recommended plan, add a restrained hover effect to the button, and avoid animating every row.

Be especially careful with rotating columns. This mode can be helpful when you have many plans and need to present them compactly, but it also makes comparison harder. If you use rotation, keep plan names short, verify the navigation elements, and make sure visitors can return to the plan they need without losing context.

Fully Clickable Column

The column settings include an option to make the entire column clickable. The documentation explains that the click can trigger the button link or button script and is useful if the standard button or bottom section is hidden. That is a strong feature for pricing cards, but it needs to be handled carefully.

If the whole column is clickable, visitors expect any click inside it to lead to one clear action. Do not place several competing links, expandable elements, and tiny clickable icons inside such a column. For accessibility and analytics, it is better to keep a visible button and use full-column clickability as reinforcement rather than as the only cue.

Fonts, Icons, Tooltips, and Custom CSS

The visual power of ARPrice can easily become a weakness if you use everything at once. The plugin supports Google Fonts, icon packs, custom images, tooltips, custom CSS, and separate color settings for sections. That means you can create a table that aligns perfectly with your brand, but you can also overload the page with fonts, icons, and pop-up elements.

Fonts and Character Sets

Official sources mention Google Fonts and the ability to add character sets. For a Russian-language site, that is not a minor detail. If the selected font does not support Cyrillic, the table can look inconsistent: part of the text will render in one font and part in another. So before publishing, check Cyrillic in plan names, feature rows, buttons, tooltips, and the toggle.

For a pricing table, it is usually better to use one primary font and one accent weight rather than several font families. The price should read large and clearly, but it should not overpower the message. If the table includes many numbers, pay attention to alignment and line breaks. On mobile, a long price with a billing period can unexpectedly wrap onto two lines.

Icons and Media Inside Columns

ARPrice supports Font Awesome, Material Design Icons, Ionicons, Typicons, as well as video, audio, HTML5 media, and Google Maps in suitable sections. These options are useful for unusual scenarios: tours with a map, courses with a video clip, support packages with communication channel icons. But a standard pricing table usually needs a few icons, not a full stack of libraries.

In the global settings, the documentation describes the ability to disable individual icon libraries if they create unnecessary load. That is a practical option for sites where the table is used on one page and extra icon packs are being loaded for no reason. After disabling a library, verify that icons do not disappear from published tables.

Tooltips Without Overload

Tooltips help explain complex limits such as "active users," "project," "monthly quota," or "priority support." But if every row has a tooltip, visitors are forced to read the table through pop-ups. Use tooltips only where a short label could easily be misunderstood without explanation.

A good tooltip answers one specific question. For example, not "Extended support includes various benefits," but "Weekday responses only, rollover work is not included." In ARPrice, you can configure tooltip text and background colors, so check contrast and avoid making them look like ad elements.

Safe CSS for Small Improvements

The ARPrice documentation includes global custom CSS and an example using an element class. Below is a cautious variation that does not modify the plugin core and does not depend on an invented internal API. It is useful if you want to visually frame the table container on the page and make keyboard focus more visible on links. Before applying it, replace the outer container class with your own class added in the page block or theme.

.pricing-page-arprice a:focus,
.pricing-page-arprice button:focus {
  outline: 3px solid #1f8cff;
  outline-offset: 3px;
}

.pricing-page-arprice .arp_price_table {
  max-width: 1180px;
  margin-left: auto;
  margin-right: auto;
}

The check is straightforward: open the page, tab through the buttons with the Tab key, and confirm that the focus outline is visible. Then reduce the browser width and verify that the table stays within its container. If the class .arp_price_table is different in your version or template, do not guess the selector on a live site. Use the CSS class information in the ARPrice interface or inspect the page copy in the browser. To roll back, remove this CSS from the plugin's global settings or from the theme's additional CSS.

Publishing the Table via Shortcode, Widget, and Page Builders

Once the table is saved, you need to display it on the site. The ARPrice documentation describes two basic methods: insert the shortcode into a WordPress page or post, or use the widget through Appearance - Widgets. It also confirms dedicated elements for Gutenberg, Elementor, and Beaver Builder, while the official page additionally lists WPBakery, Cornerstone, King Composer, and Divi Builder as compatible insertion methods through either a shortcode or an element.

Shortcode on a WordPress Page

The shortcode is the most predictable output method. You can copy it from the table editor or the saved table list. It works well when the page is built in the standard editor, when you need to insert pricing inside a long landing page, or when the page builder supports a shortcode block.

Recommended workflow:

1. Save the table and copy its shortcode from the ARPrice list.
2. Open the draft page where the pricing block will appear.
3. Insert the shortcode into its own block rather than mixing it into a paragraph.
4. Update the page and verify the front end while logged out of the admin panel.
5. Clear the page cache if the table does not change after saving.

If the shortcode appears on the page as plain text, the editor, theme, or builder did not process it as a shortcode. In that case, use a dedicated shortcode block. A plain HTML block is not always the right choice, and you may also need to review the builder settings.

Widget in a Sidebar or Utility Area

The ARPrice widget is useful for constrained areas: a sidebar, footer block, or a dedicated theme area. The documentation explains that the widget is added through Appearance - Widgets, after which you choose a saved table from a dropdown. It is not the best method for a large four-plan table, but it works well for a short one-off offer or a small comparison block.

Before publishing in a widget, check the width of the widget area. A sidebar is often narrower than the main content container, so a complex table may become compressed or excessively tall. For widget use, it is better to create a separate simplified template rather than reuse the same block from the main pricing page.

Elementor, Gutenberg, and Beaver Builder

The Elementor documentation says ARPrice adds a dedicated element to the builder, lets you choose a saved template from a dropdown, and then shows a preview on the page. The logic in Beaver Builder is similar: you select the saved table, save the page, and refresh it. For Gutenberg, the changelog notes a redesigned block with a preview of the selected table.

In practice, that means you should avoid editing the same table from multiple places at once. Configure the table in ARPrice, save it, and then insert it into the builder. If you need to change pricing content, go back to ARPrice instead of trying to edit the generated markup inside the builder.

Practical Example: A Pricing Table for a Service with Monthly and Yearly Billing

Now let us build a working scenario you can adapt for a SaaS product, education service, membership site, or agency offering. The goal is to create a three-plan table, show monthly and yearly options, highlight the recommended plan, place the block on the page, and verify that the buttons lead where they should. The example does not depend on any specific payment system: buttons can lead to a quote request page, a form, a WooCommerce product, or a registration page.

Goal and Preparation

We need a table with the plans Start, Growth, and Business. For each plan, we already have the monthly price, yearly price, 5 to 6 key differences, a short description, and the button link. The main plan is Growth because it fits most customers. Before opening ARPrice, the "Pricing" page has already been created and the target pages for the buttons have been tested separately.

Setup Steps

1. In ARPrice, create a new table and choose a three-column template with good contrast and a restrained button style.
2. Rename the template so it is easy to find in the list, for example Pricing SaaS Main.
3. Fill in the column titles, descriptions, prices, and feature rows for the monthly state.
4. Enable Toggle Price, create two steps, and label them "Month" and "Year." In the actual ARPrice interface, the real field names may appear in English, so keep exact UI labels unchanged where applicable.
5. Copy the first step's data into the second one and change only the price, the billing period, and the rows that reflect yearly savings.
6. Highlight the Growth plan using color, a ribbon, or a more prominent button, but do not make the other plans hard to read.
7. Check Responsive Column and the column count on phones. If the text is long, shorten the rows instead of shrinking the font to an unreadable size.
8. Save the table, copy the shortcode, and insert it into the draft of the "Pricing" page.
9. Open the page as a normal visitor and switch between monthly and yearly a few times.

Validating the Result

On the public-facing page, visitors should clearly see three plans, an obvious active billing period, a highlighted recommended plan, and working buttons. When the billing period changes, the price and related rows change too, but the table structure should not jump around. On mobile, plan names should stay readable, buttons should not overlap nearby elements, and the toggle should not take up half of the first screen.

Quick takeaway: if a visitor can understand the difference between the plans in 10 to 15 seconds and click the right button without excessive reading, the table is doing its job. If they have to open a tooltip for every row, the table should probably be simplified.

A Note on WooCommerce and Forms

The documentation confirms that ARPrice can work with WooCommerce by adding an Add to Cart shortcode to the button flow, and it can also open an ARForms form through a shortcode in the button script. That is useful when the pricing table needs to lead to a product or a lead form. But this type of integration should be tested separately: the WooCommerce product must add to the cart correctly without the table, and the form must open and submit correctly before you embed it in ARPrice.

If nothing happens after a click, do not start by redesigning the whole template. First test the target shortcode or link on a separate page. Then check whether the standard button block is hidden in ARPrice and whether the form script conflicts with JavaScript optimization.

Analytics, A/B Testing, and How Not to Jump to Conclusions Too Early

ARPrice includes view and click statistics for tables, and the documentation describes A/B testing as the ability to show multiple tables through a single shortcode [ARPrice_ab] with traffic distribution and separate analytics. That is useful if your pricing page already gets traffic and you have a specific hypothesis to test: a different plan order, a different recommended plan, a different button label, or a different emphasis on yearly billing.

When A/B Testing Is Worth It

A/B testing is not useful on an empty page with no visitors. It is also ineffective if the variants differ in everything at once: color, copy, number of plans, price, button, and layout. You will not know what actually influenced clicks. With ARPrice, it is better to test one strong hypothesis at a time.

Examples of meaningful hypotheses:

• A highlighted middle-tier plan gets more clicks than a highlighted premium plan.
• Yearly billing as the default state leads to more button clicks.
• Short feature rows are easier to read than long descriptions inside the table.
• A button labeled "Get a Consultation" performs better than a neutral "Choose" label.

Configuring Tests Without False Conclusions

In ARPrice A/B testing, you select a main table and variations with a display percentage. The documentation separately warns that saving the settings resets A/B analytics. So do not change the distribution every day without a real reason. First make sure both tables render correctly, then let the test collect enough views and clicks.

If the site uses aggressive caching, the A/B logic may not behave as expected because visitors will keep seeing a cached version of the page. That is not a unique ARPrice issue, but a general risk with dynamic blocks. Before launching a test, open the page in private mode, clear the cache, and make sure the variants truly change.

Import, Export, and Reusing Tables Without Creating Chaos

ARPrice includes template import and export features, and the official page also highlights the ability to migrate data from older comparison tables. On a single site, that may seem secondary, but in an agency workflow, franchise setup, course network, or project with multiple landing pages, reusing tables quickly becomes an important maintenance task. Without structure, the editor ends up with a pile of similar templates and no clear understanding of which one is published, which one is a test, and which one became outdated after pricing changes.

Before using import and export, define the role of each table. Do not name templates simply "Table 1" or "New Pricing." It helps to encode the page, audience, and state in the name: Pricing Main RU Monthly-Yearly, Agency Services Short Sidebar, Team Showcase Footer. Visitors never see that name, but it makes maintenance, A/B testing, and cross-site migration much easier.

When Export Actually Matters

Export is worth using when the table serves as a working standard and needs to be moved to a site copy, a new domain, a staging environment, or a related project. For example, an agency may build a strong pricing table for one client and want to adapt it quickly for a second language version. Or a SaaS owner may first configure the page on a staging site and then move the table into production. In those cases, export saves time and reduces the chance of manual errors.

But export should not replace a backup. The update documentation specifically mentions backing up the database, tables, ARPrice uploads folder, and the plugin folder. Exporting a template helps move a specific table, but it does not guarantee restoration of the full environment: images, custom fonts, global CSS rules, target button pages, and cache settings.

How to Maintain a Table Library

For long-term project health, set one simple rule: never edit published tables blindly. First duplicate the template, make the changes, test them on a draft page, and only then replace the shortcode or the selected template in the builder. Even if the change is minor, such as one price adjustment, still take a screenshot of the current state and note where the table is used. ARPrice shows saved templates, but it does not always answer the editorial question: "Which pages currently depend on this table?"

A useful internal structure:

• Reference template. A clean design version without experimental colors or temporary promotions.
• Live page table. The version currently published on the main pricing page.
• Test variation. A version for A/B testing or a future update.
• Archive copy. A saved version from before a major pricing or structural change.

This structure becomes especially important if ARPrice is used with WPML. A translated table can fall out of sync with the primary one if you update prices in one language first and forget to update English or another locale afterward. Before publishing any change, compare not only the appearance but also the actual values: price, billing period, limits, button text, and target URL.

Use Cases That Really Show ARPrice at Its Best

A strong pricing table plugin is useful for more than a page called "Pricing." ARPrice supports sections, tooltips, media, maps, hiding individual column parts, clickable columns, and multiple output methods, so it can be used in several adjacent scenarios. The key is not to turn every page into a table for visual effect alone. Each scenario should have a clear goal, defined input data, an expected outcome, and a way to verify success.

Comparing Service Packages for an Agency

For an agency, the table often compares not products but the scope of work: audits, strategy, design, support, reporting, consulting. Here, short rows and a clearly recommended package matter most. In ARPrice, you can highlight one plan with a ribbon or color, add tooltips to potentially unclear items, and make the button lead to an inquiry form. The success check is simple: the visitor understands how "Support" differs from "Growth" without having to read a long contract inside the column.

What Can Go Wrong

If every row contains a full list of tasks, the table becomes hard to compare. It is better to keep 6 to 8 core differences in the table and explain the details lower on the page. If the button opens a form, test the form independently first, then embed it via a supported shortcode or link.

Pricing for an Education Project

For courses and membership sites, the price is often not the only factor. Access format matters too: lessons, recordings, homework review, community group, consultations, certificate. Icons and tooltips can help here, but there is no reason to place video inside every column. Video belongs on the course page, while the table should help people choose the right level of participation.

If there is monthly and yearly access, the ARPrice toggle is a good fit. Make sure the toggle changes not only the price but also the wording of the billing period. You should not leave a row saying "per month" in the yearly state. It is a small mistake, but it immediately reduces trust.

Team or Expert Showcase

The official ARPrice page mentions team showcase use cases. In that scenario, the table stops being a pricing table and becomes a set of staff cards. Some sections can then be hidden: price and button may be unnecessary, while the photo, job title, short specialization, and links matter more. Treat this as a separate template, not as a repurposed pricing table.

The success check is different here: cards should have consistent height, names should not break the grid, and social icons should not become oversized because of theme styles. If you need to display many team members, it is better to divide the showcase by departments or roles than to output a long strip of dozens of columns.

Comparing Locations, Tours, or Packages with Maps and Media

ARPrice supports Google Maps and media in suitable sections, which opens up niche use cases: tours, events, real estate, offline services. But those elements should help visitors choose. A map in a column makes sense if location is the main difference between offers. Video makes sense if it shows the service outcome or the package format. If media is only decorative, it makes the page heavier and distracts from pricing.

Before launching this kind of setup, check API keys, theme width constraints, mobile behavior, and caching. If the map does not load, the table should not become empty. Leave a text description of the location as a clear fallback.

Compatibility, Performance, and Clean Ongoing Maintenance

A pricing table usually sits on an important page, so it should be treated as part of the user journey. It affects not just design, but also speed, clicks, accessibility, localization, and post-update maintenance. ARPrice gives you many settings, which means responsibility for the final polish still stays with the site owner.

Theme and Builder Compatibility

If the table looks different in the editor and on the live page, the cause is usually theme styling, the builder container, caching, or minification. ARPrice has its own preview, but the real page adds its own spacing, content width, button styles, and fonts. So checking only inside the editor is not enough.

For Elementor, Beaver Builder, and other builders, use the native ARPrice element or a shortcode block. Do not paste the generated table HTML manually. That kind of workaround breaks updates, makes maintenance harder, and can disable plugin behavior.

Performance and Extra Assets

The official page says heavy JS and CSS are loaded based on shortcode placement, but that is not a reason to put everything into the table. Icons, external fonts, video, maps, tooltips, and animations all add complexity. If the table sits on a high-traffic or advertising-focused page, test it together with caching and performance optimization.

Practical performance steps:

• Do not use video, maps, or audio inside the table unless they help visitors choose a plan.
• Disable unused icon packs only after confirming that required icons do not disappear.
• Do not add multiple Google Fonts just for one table.
• After changing the table, clear the page cache and verify the public result.
• If a script optimizer breaks the toggle, exclude the pricing page or ARPrice scripts from aggressive deferral, but confirm the conflict with a test first.

Localization and WPML

The sources mention WPML readiness and RTL support. That does not mean translation happens automatically without reviewing all user-facing strings. A pricing table contains a lot of manual text: plan names, feature rows, buttons, tooltips, and toggle labels. After translation, check not only the wording but also row length. Russian text is often longer than English, so a column width that worked before may no longer be the best fit in reverse for other languages.

For a multilingual site, keep one table as the structural reference and test localized variants in each locale. Do not mix currencies, billing periods, and limits in one line without explanation. If the price varies by region, it is better to clearly separate pages or states than to force visitors to guess.

Interface Video: When It Helps to See the Editor in Motion

The CodeCanyon page includes a video link for the ARPrice admin panel. It is useful not as a replacement for a written guide, but as a quick visual reference: where the editor is located, what working with the table looks like, and why preview should be checked before publishing. The video supports the intent cluster around "how to use CodeCanyon ARPrice," "ARPrice editor," and "setting up a WordPress pricing table."

After watching, do not copy the demo layout literally. Use the video as an interface map, then adapt the real pricing, copy, buttons, and validation to your own page.

When CodeCanyon ARPrice Is the Right Choice

CodeCanyon ARPrice is worth using when the pricing table is an important part of the page and you need more than a plain price list. It gives you a controlled visual block with templates, an editor, period toggles, responsive columns, shortcodes, widgets, page builder integration, analytics, and A/B testing. The plugin is especially useful for sites where pricing changes over time, comparisons are reused across pages, and buttons lead to a real next step for the visitor.

Before launch, keep the plan simple: prepare the pricing, choose a content-driven template, save a copy, configure responsive behavior, test the shortcode on a draft page, verify the buttons, and only then add effects, tooltips, media, and A/B testing. That sequence saves far more time than trying to build a perfect design on the first pass.

If, after reading this guide, you know which plans to show, which publishing method fits your site, and which checks to run before launch, you can move on to the practical step and download the ZIP archive to test on a copy of the site. Judge the result not by the number of enabled effects, but by how quickly a visitor understands the differences between the plans and clicks the right button.