CodeCanyon Counter - WordPress Plugin

A Practical Guide to CodeCanyon Counter for WPBakery Page Builder

CodeCanyon Counter is an add-on for WPBakery Page Builder that helps you display eye-catching statistics on a WordPress page. It works best as a way to present verified facts, not as an analytics system or a replacement for reports. These facts might include completed projects, service areas, program participants, locations, or other figures visitors can understand at a glance. This guide covers site preparation, installation, configuring the element, working with multiple metrics, checking the layout at different screen sizes, and troubleshooting common issues.

A counter has one simple but important characteristic: a large number becomes part of the page’s design, so an error stands out more than it would in a regular paragraph. The information needs to be accurate, easy to read, and resilient to theme changes, caching, and builder updates. That’s why you should start with the source of the number, the purpose of the element, and how it will look on the live page, not with a flashy effect.

The steps below provide a cautious workflow for a site that already has WPBakery installed. The available fields and tab order may differ in a particular plugin release or theme. Where the product listing does not confirm a specific setting, this guide does not attribute it to CodeCanyon Counter. Instead, it relies on documented WordPress and WPBakery features such as rows, columns, design settings, responsive layouts, and custom presets.

What a counter adds to a page

A counter is useful when a number helps visitors quickly understand your scale, offering, or next step. An agency homepage might show completed projects and areas of expertise. An educational program page might show the number of sessions or subject areas, as long as the counting method is clear. A nonprofit might show completed requests or the amount of verified assistance provided. On a corporate site, three or four concise metrics with clear units often work better than a few impressive but abstract numbers.

The CodeCanyon Counter listing confirms its core features: it is an add-on for WPBakery, adds a Counter element, lets you apply custom colors, supports multiple counters on one page, includes animations from its advertised collection, adapts to different screen sizes, and comes with translation files. These features define a sensible scope for the element. The plugin handles how a number is presented in the WPBakery editor; the accuracy of the data, the editorial decision, and the element’s placement remain the site owner’s responsibility.

A useful metrics block answers three questions in a few seconds: what is being counted, why the number matters, and what unit it uses. The value 250 tells visitors very little without a label. 250 projects is clearer, but the wording still needs to be checked. 250 completed projects ties the number to a specific fact. If the figure applies to a particular period, mention that period in nearby explanatory text instead of hiding it in a small decorative line.

Don’t use Counter just to fill an empty space. If an organization has no verifiable metric, show a concise benefit, an explanation of how the work is done, or a testimonial instead. A large number added “to look impressive” can quickly undermine trust. Visitors should be able to understand the block without animation, while scripts load slowly, or after scrolling past it quickly.

A well-chosen metric supports the story of the section. After a description of services, it may make sense to show the number of projects completed. After a section about geographic reach, you might show the number of cities or regions, provided you have a clear counting rule. A row of unrelated numbers looks like an ad. A set of related metrics helps visitors connect the dots: what the team does, the scale at which it operates, and the practical outcomes it has achieved.

Who CodeCanyon Counter suits, and when to use another approach

This plugin is useful for editors who already build pages with WPBakery and want to add a compact row of metrics without writing markup by hand. It can work well on a service landing page, team page, About page, case study, campaign landing page, or event page. Since you can place multiple counters on one page, you can group related facts such as projects, locations, and team members. The block is most useful when its metrics support one idea rather than compete for attention.

CodeCanyon Counter is also a good fit when you need to match the block to your theme’s color palette. Support for custom colors does not mean every number needs its own color. In most cases, one brand accent for the value and a neutral shade for the label are enough. If the theme already uses a high-contrast background, check readability before adding color. Color should not be the only way to convey meaning: the period, status, and unit should be clear from the text.

This is not the right choice for dynamic data that needs to sync automatically with a CRM, online store, request management system, or analytics service. The available product description does not mention those integrations, so you should not expect automatic synchronization. In that case, use a tool with a documented connection to the system you need, or commission a separate server-side customization. Counter is better suited to metrics that editors control and update as part of a page review.

Another limitation comes from the page builder itself. The product listing explicitly requires WPBakery Page Builder and says the plugin is not optimized for Gutenberg. If your site uses the WordPress block editor and does not have WPBakery, this add-on is not a standalone solution. If the builder comes with your theme, first confirm that it is active, available for the post type you need, and able to open the selected page in its editor.

Think about the content’s lifecycle, too. A counter is a poor fit for a metric that changes daily but is updated by an editor only once a year. It does not establish a counting method: a satisfaction percentage is still questionable without an explanation of the survey, regardless of the animation. Conversely, a simple, stable metric can be more useful than a complex chart if visitors only need a quick point of reference.

Start with the data: map out your metrics

Before installing the plugin, make a small content map for the block. List each metric on its own line with its value, unit, source, data owner, last internal review date, and intended page. This map is for editors, not visitors. It helps keep the attractive interface connected to the original source of each number.

Choose metrics that are on the same level. A row showing the number of projects, a satisfaction percentage, and years in business works only if the method behind each figure is clear. If the methods are not comparable, it may be better to keep two reliable numbers and add explanatory text. Don’t mix an all-time total, a one-month rating, and a marketing promise as though they were measured in the same way.

Keep labels brief but specific. Use active clients instead of clients if the number really refers to active clients. Use countries served instead of countries if that is what the figure measures. If a metric is a future target, don’t present it as an achievement. Plain text is more honest here because an animated number looks like an established result.

Decide on the order of the elements. Visitors read the block from left to right or from top to bottom, so put the most important fact first and use the next positions to add context. Here’s a useful check: cover the numbers and read only the labels. If the labels make sense as a short story, you’ve chosen your content well. Then cover the labels and look at the numbers. If one value looks out of proportion and draws attention for no good reason, reconsider the order or typography.

There’s no need to force every value to have the same number of digits. Don’t try to make 7, 48, and 1,250 the same length. What matters is leaving enough room in each column for the metric to grow. If a statistic could reach five digits, plan for that now rather than having to rescue the published layout by shrinking the font later.

What to check before installing the add-on

Start with a site backup, and save the current version of the page you plan to edit. This is more than a formality: plugins and themes can load styles in different orders, and a live page may contain older WPBakery shortcodes. Take screenshots of the live page at a wide and narrow viewport so you can compare the changes against something concrete. If you have a staging site, run the entire workflow there first.

Next, make sure WPBakery is installed and active. The Counter listing names it as a requirement. In the WordPress dashboard, open Plugins and confirm that WPBakery is not inactive. Then open one of the pages you need and check that the builder is available. WPBakery settings can restrict access by role or post type, so a missing editor button does not always mean Counter is broken.

Compare your setup with the product listing, but be cautious. The product page lists historical WordPress compatibility ranges up to version 6.2 and says the plugin is not optimized for Gutenberg. That does not prove it works with every recent combination of WordPress, PHP, themes, and plugins. On a current site, test it briefly on a copy or staging page: activate the add-on, add one element, save a draft, view the live page, and check the hosting error log if you have access to it.

Check whether another installed extension already does the same job. Some themes or WPBakery bundles include their own statistics element. Elements with similar names do not necessarily conflict, but editors can easily choose the wrong one. Before you start, note the name of the element you need in the Add Element window and agree on one option for the page.

Also review your caching and optimization setup. Don’t assume the counter itself is causing a caching problem without first diagnosing it. However, optimization tools may combine, defer, or reorder JavaScript. If your site already uses aggressive optimization, check both the final number and whether the animation appears without errors after installation. Don’t disable everything at once. Identify the specific setting first, then temporarily exclude only the page or related resource according to your optimization tool’s instructions. Record what happens and restore the smallest configuration that works.

Finally, review your editorial workflow. Decide who verifies the figures, who enters them in WPBakery, and who approves the live page. One person may handle all three roles on a small site, but it is still useful to leave a note with the task. On a team site, this helps prevent a designer from changing the color and an editor from changing the label while the number remains from an old report.

Install it and run a first check without risking the live page

Install the ZIP archive using the standard WordPress workflow: open Plugins > Add New, choose the option to upload a plugin, finish the installation, and activate the add-on. WordPress supports ZIP uploads from the dashboard, and the installed plugins list lets you activate, deactivate, and update plugins. Don’t extract the archive over an existing folder in a file manager unless you understand its contents. Manual replacement makes it easier to leave old files behind or damage the add-on.

After activation, don’t start by editing an important published page. Create a draft with a name such as Counter Test, open it in WPBakery, and click Add Element. Find the Counter element by name or in the add-on’s category. Seeing it in the library is a useful first check: WordPress recognizes the active plugin, and WPBakery has registered an available element. WPBakery documentation explains that builder elements are shortcodes with settings, and the editor provides an interface for configuring them.

Add one counter with a test value, a short label, and a neutral color. Don’t use real statistics in the test until you are ready to publish them. Save the draft, open its preview in a separate tab, and reload the page normally. Check four things: the page does not go blank, the value is visible, the label is not covered, and the page’s neighboring elements are still in place. Move the setup to the live page only after it passes this check.

If the Counter button does not appear, stop here. Check that both WPBakery and the add-on are active, that the builder is available for this post type, that your user role has permission, and that activation did not produce an error. Don’t try to type in a guessed shortcode. The available sources do not confirm the product’s exact shortcode name or attributes, and manual insertion can create content that is difficult to maintain. It is safer to restore access to the element through the normal interface or contact the vendor with details about your setup.

After the first successful display, save a reference screenshot and the draft version. They will give you a baseline for troubleshooting. If the block behaves differently after you style it, you can compare it with the simplest working version: one element, one number, one label, with no duplication or complex background.

How Counter works as a WPBakery element

This is the key mechanism that distinguishes CodeCanyon Counter from a standalone analytics widget. The add-on registers a Counter element in WPBakery. The page editor adds it to a selected row and column, saves its settings in the page content, and the live page outputs the prepared markup, styles, and animation script. The final appearance therefore depends on three layers: the counter’s settings, the WPBakery container, and the theme’s CSS.

The first layer defines what the number means: its test or live value, label, color, and available effect settings. The second controls placement, including column width, the order of multiple elements, spacing, and the row background. The third can affect fonts, inherited text color, line spacing, and rules for smaller screens. When the block looks wrong, don’t change random Counter fields. First identify which layer is responsible.

For example, four counters unexpectedly become too narrow. If each number displays correctly, start by checking the row layout and column widths, not the values. If the number is readable but the label blends into the background, check the text color, row background, and styles inherited from the theme. If everything is visible but the effect does not run, look next at the animation script, caching, or JavaScript errors. This sequence saves time and reduces the risk of breaking a working design.

WPBakery builds pages from rows and columns. A row contains one or more columns, and content elements go inside them. The builder documentation also confirms that you can control column width and behavior across devices. Use this model directly: for three equal metrics, choose one row with three columns; for four, use four equal columns or two rows of two if the labels are long. Don’t make each counter handle the grid on its own.

This model also makes it easier to roll back safely. If the issue is with the content, restore the element’s previous value. If it is with the grid, restore the earlier row layout. If custom CSS is involved, remove the latest change from the designated location. Don’t edit WordPress core or theme or plugin files to test a theory. That kind of experiment is hard to reverse, and an update may erase the changes entirely.

Build a first counter: test it before entering real metrics

In your test draft, create one element and fill it in with details that make the output easy to recognize. Use a number that cannot be mistaken for a real statistic, such as 37, and the label Test metric. If you can choose a color, use a temporary shade with enough contrast that is not too bright. The goal is not to design the block yet. You’re checking the full workflow: the settings window opens, the element saves, the page displays the number, and the changes reach the live view.

Save the page, refresh the preview, and change one field, such as the number or label. After saving again, the live page should show the new value. This simple check is important because it separates a saving issue from an animation issue. If you change the number in the editor but still see the old one, first clear the page cache or temporarily bypass it for logged-in users. Don’t change the effect settings until you have confirmed that the current markup is being displayed.

Check the wording of the unit. English labels should read naturally next to the number, so use concise terms such as projects, participants, or requests. If the value changes often, choose a label that still works as the number grows. Updating the content should remain a simple task, not require editing several words and rebuilding the grid each time.

Once the single element works, save it as a reference instead of rushing to copy it dozens of times. WPBakery supports custom element presets: you can save a configured element and then add it from the My Elements tab. This is a builder feature, so first make sure your user role can access presets. A preset is useful for repeating typography and spacing, but it should not turn an old value into a template for every page.

After testing, delete the draft or keep it as a private reference page for your team. Don’t let it appear in search results, and make sure you remove any temporary data. The most troublesome consequence of a successful test is not a technical error but accidentally publishing a test metric that later appears in search results or client screenshots.

Detailed settings: meaning, color, quantity, and motion

Return to your metrics map and configure the block one layer at a time. This makes it easier to keep the data clear among the design settings. Available fields can vary by release, so look for the purpose of each setting rather than relying on labels from someone else’s instructions: value, label, color, effect, container settings, and responsive behavior.

Value and label

Enter the final number in the format the element supports. Don’t try to format it with spaces, extra characters, or HTML until you have confirmed that the basic output works. Start by getting the number to display correctly, then add a clear label through the interface if that option is available. If you need a percent sign, currency symbol, or explanation, add it only after checking the live page. The symbol should not break the alignment or leave visitors unsure whether it belongs to the value or the label.

The label should add context to the number, not repeat it. A construction like 100 100% is hard to read. Choose one primary metric and its unit. To compare with an earlier period, use regular text next to the block unless a reliable source confirms that the element can display comparisons. Don’t present growth as a total: “up 18%” and “18%” can mean very different things without context.

Color and contrast

The product listing says you can use custom colors. Start with an accent already used in the theme, then check it against the actual page background. Readability matters more than an exact match to the brand color. Dark text on a light surface is often easier to read, while a saturated color is better reserved for the large number or a small marker. If the background includes a photo, gradient, or video, give the row a calm inner surface or move the counter to a solid background.

Multiple metrics on one page

Support for multiple counters does not mean you need to use a lot of them. Three or four are enough for most sections. More can make comparisons harder, while on small screens the labels become too narrow. Start with one element, configure it, and duplicate it into neighboring columns. Then replace the values and labels while keeping the same overall approach. After each change, check that no test text remains and that the repeated content does not mislead visitors.

Keep the effect secondary

The product listing advertises more than 200 animation effects. That gives you plenty of options, but the practical test is simple: the effect should not make the number harder to read. For a calm corporate page, choose subtle motion or a minimal effect. Fast, abrupt, or frequently repeated effects are rarely appropriate and may compete with theme animations, sliders, pop-up notifications, or video backgrounds. Visitors should be able to see the final value without waiting for the animation.

After each major change, save the page and check the live view. The WPBakery window shows the structure, but it may not reflect all theme styles, caching, or script behavior. If the new version looks worse, don’t edit the plugin files by hand. Restore the element’s previous setting through its interface, revert to a saved page version, or remove the test element. This is safer and will survive a product update.

If your team needs a consistent style, save a well-configured element as a WPBakery preset. Record which settings define the style and which must change on every page. The style can include the color, a restrained appearance, and a suitable container. The value, label, data source, and next review date should remain separate editorial decisions.

Rows, columns, and spacing: why counters sometimes look wrong

Start laying out your counters with the WPBakery row, not the effect. Open the row settings and choose the number of columns based on the content. Three short labels will usually fit in three equal columns. For four values, check the wide layout first and then reduce the viewport width. If the labels wrap onto several lines, two rows of two may be easier to read. The goal is a balanced rhythm and a clear reading order, not fitting as many numbers as possible on one screen.

WPBakery documentation describes rows and columns as the basic page structure and lets you adjust width and visibility for different screen sizes. Don’t disable responsive behavior across the site just to fix one row. By default, the builder stacks elements on smaller screens, which is often the right choice for metrics. Forcing four columns on a narrow screen makes the text small and increases the risk of overflow.

Set spacing at one level. If the row, column, and individual element all have top spacing, later adjustments become guesswork. Decide which element controls the outer spacing: usually the row manages the distance from neighboring sections, while the column or element controls internal spacing. WPBakery’s Design Options let you adjust margins, padding, borders, backgrounds, and corner radius, but there is no need to use every available setting just because it is there.

If the block sits on a colored band, test two cases: one with a long label and one with the largest value you expect. A layout may look fine with 12 but fall apart at 12,500 or 1,250,000. Leave room for growing values in advance. Don’t shrink the font until it is hard to read just to preserve a rigid grid. Move one metric to another row or shorten its label without losing meaning instead.

Check the visual hierarchy. If the number is huge and the label is tiny, visitors see decoration rather than data. If the label is nearly as large as the number, the block stops reading like a metric. Aim for a clear order: the value first, the unit second, and the section’s explanatory text third. No effect can fix an imbalance between these three levels.

Animation without visual noise

CodeCanyon Counter’s animation should draw attention to a value visitors already understand, not become the main event on the page. Choose one approach for the entire row: a consistent duration and movement style make the metrics feel connected. If every value appears differently, visitors have to follow the effects instead of reading the content. There may be a reason to highlight one key value, but even then it is usually better to emphasize it through size or placement than through aggressive motion.

Test the first visit. Open the page in a new window, scroll to the block at a normal pace, and see whether you can read the labels in time. Then reload the page, navigate to the block through a menu or anchor if available, and check it again. Some effects appear only when the element enters the viewport in a particular way. A counter that appears only after a special scrolling pattern is not working reliably.

Don’t place several independent sources of motion next to each other: a slider, parallax effect, video background, slide-out panel, and rapidly animated numbers. Each component may work on its own, but together they can overwhelm visitors. On an informational page, motion should help people find their way around. A calm block with an accurate number is more useful than a flashy but hard-to-read spectacle.

Visitors who are sensitive to motion, using a low-powered device, or browsing with scripts disabled should still be able to see the number and label. Don’t use animation as the only way to reveal the value or hide the static number until the effect finishes. If the theme or optimization tool offers a reduced-motion mode, check the page with that mode enabled, too. If it leaves an empty space or ruins the contrast, revisit the layout instead of making the effect stronger.

Use this simple editorial test: if you can pause the page at any point after the block appears and visitors can still understand the numbers, motion is playing a supporting role. If the meaning becomes clear only at the end of a complex sequence, the effect has become too important. Return to a minimal option and make static information the foundation of the design.

Animation should not be a substitute for updating data, either. When a metric changes, update the value and label first, then check how the effect behaves with the new number. Don’t keep an outdated figure just because the new number changes the animation’s trajectory. Reliability matters more than decorative consistency in a published metrics block.

Responsive layout and translation: check them separately

The product listing claims that the plugin is responsive and includes .po/.mo translation files. These are useful features, but they don’t guarantee that the element will look right in every theme or language. Check responsiveness on the actual page, with its fonts, container width, and neighboring elements. Test the translation separately: files in the package don’t mean every string will already appear in the language you need, or that an editor-entered label will be translated automatically.

For a mobile layout check, test at least three sizes: wide, narrow, and somewhere in between. On a wide screen, look at the row’s rhythm. On a narrow one, see how the elements stack, whether the labels remain visible, and whether any number spills over the edge. The most frustrating problems often appear at intermediate widths: one column has become too cramped but has not stacked yet. Check in a browser emulator and, if possible, on at least one real device.

Decide in advance what needs to be localized. Service names, units, and labels entered in the element are often page content rather than system strings. Prepare them for each language version through your site’s multilingual workflow. Don’t rely on automatically translating a short label: grammatical errors and word length are especially noticeable next to a large number. If a translation is longer, adjust the layout or shorten the label, but don’t shrink all the typography without thought.

The add-on’s system strings are a separate matter. If the settings panel remains in English after you change languages, the cause may be how translations are loaded, the package version, or your site’s locale configuration. Don’t edit plugin files to translate the interface quickly. First check whether the problem is with a system string or with text entered on the page. Then use WordPress’s standard localization workflow or contact the vendor’s support team.

Pay close attention to long words next to large numbers. An English label may fit on one line while another language’s translation wraps to two. That is not a translation problem if the block is still readable. It becomes a problem when the label is clipped, too small, or runs into a neighboring element just to keep the columns the same height. Meaning comes first, rhythm second, and perfect symmetry last.

Save screenshots of the wide and narrow layouts after each language update. They will give you a useful reference if the theme’s font changes or the builder is updated. Responsive settings are not a one-time task: a change to the label, value, background color, or neighboring column can affect the layout again.

Example workflow: an agency achievements block

Here’s a workflow you can reproduce. The goal is to add a restrained row of three metrics to a service page, reinforcing the agency’s experience without competing with its main call to action. We’ll use three verified figures: completed projects, ongoing areas of work, and team members. In a real project, replace these with data from your own metrics map; don’t reuse example values.

Prepare the content

Gather three facts and confirm the wording with the person responsible for the data. Give them a consistent rhythm: value, short label, and internal source. Decide where on the page they will be most helpful. In this example, the block goes after a paragraph about the agency’s approach and before a detailed list of services. At this point, visitors already understand what the agency does, so the numbers serve as evidence of its scale rather than a substitute for an explanation.

Choose a design: a light surface, dark labels, and one moderate accent for the large numbers. Don’t add icons unless they help distinguish the metrics. Icons of a portfolio, map marker, and group of people may be useful, but they should share a style and still work without color. If the icons come from unrelated libraries, leave them out and use clean typography instead.

Set the time frame before adding the data. For example, “completed projects” might mean all closed projects since the team was founded, while “areas of work” might refer to its current services. Don’t mix these definitions without a label. If one metric is measured as of a particular date and another describes an ongoing service, explain the time frame in a regular sentence before or after the block. Counter keeps the presentation compact without letting the meaning get lost in small print.

Build the row in WPBakery

1. Open the page in WPBakery and add a new row where the block naturally follows the text.
2. Choose a layout with three equal columns. Save the page first so the change to the layout is recorded separately from the Counter settings.
3. Add Counter to the first column, enter the approved value and label, and open the preview.
4. After checking it, copy the element into the second and third columns, change only the content, and check each label again.
5. Set the shared background and outer spacing on the row, not on each element individually.
6. Choose one custom color for the values and a restrained effect, then save the draft.

Check each step separately. If all three counters show the same number after you copy them, the issue is almost certainly in the duplicated content, not the grid. If the values are correct but the third element wraps, adjust the column width or shorten the label. This workflow also makes it easy to undo the last step without rebuilding the entire row.

Check the layout

Open the draft in a regular browser and ask yourself five questions. Is it clear what each number measures? Does any value look like a promise rather than a fact? Does the order make sense on a phone? Is there enough contrast against the background? Can someone understand the block without seeing the animation? If any answer is no, fix the specific layer involved: the text, grid, color, or effect.

Then ask a colleague who was not involved in the setup to explain each metric in ten seconds. This is a quick editorial check. If they remember only the large numbers but not what they mean, shorten or clarify the labels. If they miss the most important metric, change the column order or add a brief introduction before the row. A successful counter does not need an explanation from the page’s author.

Finally, set a date for the next review. Growing metrics might need a quarterly editorial check; stable ones may only need to be reviewed before a page update. Connecting each number to a data owner matters more than the animation. It keeps the block from becoming attractive but outdated decoration.

Adapt the block for a case study

On a case study page, the same tool serves a different purpose. Instead of showing general company metrics, display numbers tied to that specific project: its duration, the number of materials produced, the channels used, or a measurable outcome if you have permission to publish it. Explain the original task and how it was measured before showing the figures. Don’t display personal or sensitive client information. If in doubt, aggregate the data or describe the workflow in text.

This approach makes the counter evidence for a specific story. A case study does not need generic claims about “thousands of successes.” It needs numbers that answer visitors’ questions: how much work was involved, what was done, and how the outcome was measured. If a metric takes more than one sentence to explain, it is too complicated for a large callout and should be covered later in the text.

How to check the page after publishing

Check the page in two modes: as an editor and as a new visitor. In the first, open the page in the dashboard, find each element, confirm that the right values are saved, and make sure no test data remains. In the second, use a regular browser window without the builder interface, load the page with a clean cache, and read it from top to bottom. Don’t judge the block from a single screenshot. Its appearance as you scroll, the neighboring elements, and how it looks on a return visit all matter.

Use this short checklist:

• Every number matches the approved metrics map.
• The labels explain the units of measurement and are not clipped.
• The row works on wide, medium, and narrow screens.
• There is enough contrast against the actual page background, not just in the editor.
• The animation does not hide the final value or distract from the content.
• After saving a change to a metric, the live page displays it.

Don’t worry if the WPBakery editor and live page look a little different. The builder shows the structure and element settings, while the theme may add global fonts, containers, and device-specific rules. The live page is what matters. If the difference is causing problems, don’t try to make the entire builder interface look exactly like the theme. It is more useful to configure a predictable row, set consistent spacing, and check the page after each significant change.

For team projects, add a brief note to the task record with the page, the block’s location, the metric owner, the review date, and the changes made. Visitors won’t see this note, but it can keep someone from having to repeat the troubleshooting work later. This is especially useful when several editors can access WPBakery and save the page with different settings.

Also check the page after updates. Open it after updating the theme, WPBakery, or your optimization tool, even if the update does not appear to be related to Counter. Styles and asset loading order can change indirectly. Compare the block with your reference screenshots, then check not only the displayed number but also the contrast, label wrapping, narrow-screen layout, and browser console for errors if a technical specialist can access it.

Finally, revisit the editorial meaning a few days later with fresh eyes. Ask someone who has not seen the layout what they took away from the block. If they say, “There were some big numbers,” the problem is not the technical setup but how the metrics connect to the text. Add a short explanation or replace a weak figure with a more useful one.

Performance, accessibility, and trust in your metrics

A counter has three separate qualities: it can work technically, look good, and still fail to inspire trust. So don’t stop at checking the effect. Start with the content: an exact number without context may be less honest than a rounded metric with a clear label. If the counting method is complicated, explain it briefly in nearby text. For example, a project count might include only completed work, not every incoming inquiry.

For performance, keep motion to a minimum. Don’t place several animated rows above the fold or repeat the same block in the header, page content, and footer. If the page already loads heavy media, a map, or a slider, pay close attention to its overall responsiveness. A problem that appears after installation does not prove that Counter caused it, but it is a reason to compare the page before and after on a test copy and identify the specific conflict. Don’t disable security, caching, or optimization sitewide just to get one effect working.

For accessibility, the number and label should be readable text, not an image or a value that appears only after a script runs. Don’t use color as the only way to convey meaning: a green number with no explanatory label does not tell someone with different color perception anything about “success.” Maintain sufficient contrast, avoid rapid flashing, and don’t assume every visitor will see the beginning of the animation. Subtle motion respects both the visitor and the page’s main content.

Check keyboard navigation for the interactive elements around the counter. The counter itself is usually informational, not a button. If there is a link or call to action next to it, keyboard focus should not get caught on decorative containers. Don’t make the number clickable just for effect; an action needs a clear purpose and label. A large metric that unexpectedly leads somewhere unknown creates the wrong expectation.

For trust, avoid impressive-looking round numbers without a method behind them. A value such as 99% next to “satisfied” raises questions if visitors don’t know who was surveyed or when. If the figure is uncertain, use a qualitative statement in regular text or add transparent context. Counter can make a verified fact more prominent, but it cannot make a claim credible on its own.

Plan for content maintenance. Each block should have a person or process responsible for keeping it current. Decide in advance what to do if the data stops coming in: freeze the last verified period and explain it, replace the block with text, or temporarily hide it in the editor. The worst choice is to keep showing a beautifully animated but outdated figure just because it is already part of the design.

For search visibility, it is more useful to pair numbers with regular text and make them relevant to the page. Search engines and visitors should not encounter a set of unrelated callouts. Don’t repeat the product name or target keyword in every label. Explain the actual outcome instead of trying to increase keyword density.

Make safe adjustments without editing plugin files

Before editing CSS inside CodeCanyon Counter, start with the built-in controls. WPBakery’s Design Options let you set margins, padding, borders, backgrounds, and corner radius. The Extra CSS Class name field lets you assign a class to the element. It is for a class name, not for pasting arbitrary CSS. Keeping these settings separate makes them less likely to be lost during an update.

If you need a small adjustment to the spacing around the block, assign the row a clear class such as site-kpi-row and add the CSS through the location provided by your theme or WPBakery. The builder documentation describes a separate Custom CSS area, and WordPress recommends avoiding direct edits to theme files because those changes can disappear during an update. Don’t add JavaScript just to display a number: the sources reviewed do not confirm an official custom API for Counter.

Make one small, reversible change at a time. First save the original settings, then add the class or a single style, clear the page cache, and check the wide and narrow layouts. If nothing changes or the style affects other blocks, remove the latest edit and return to the built-in settings. This is safer than searching through the add-on’s files for selectors that may change in a future release.

If the row is already easy to read, don’t add code at all. Custom CSS makes sense only for a specific need, such as adjusting the space between a row and the next section when the row settings cannot do it. It is not a required installation step. The fewer unnecessary overrides you have, the easier the site will be to update and hand over to another editor.

Troubleshooting: when the counter is missing, static, or breaking the layout

It is easier to troubleshoot CodeCanyon Counter by starting with the symptom. Don’t begin by reinstalling every add-on. First record exactly what happens on the live page, which page it affects, which user role you are testing, and what changed beforehand. Then change one factor and test again. This helps distinguish a data issue from a styling or caching problem.

The Counter element is missing from the Add Element window

Symptom: The add-on appears active in the plugins list, but you cannot find Counter in the WPBakery library. Likely causes: WPBakery is inactive, the editor is disabled for this post type, your user role is restricted, or activation failed. What to check: The status of both add-ons under Plugins, whether the editor is available on a test page, your permissions in WPBakery’s Role Manager, and the error log if available. Fix: Restore the required WPBakery plugin, enable the needed post type, or contact the vendor with details about your setup. Rollback: If the issue appeared right after activation and is affecting the site, deactivate only Counter and restore the page from a backup.

The editor shows the number, but the page is blank or shows an old value

Symptom: The settings are saved, but the preview shows an earlier version or an empty space. Likely causes: Page cache, browser cache, changes saved to the wrong revision, or a template displaying a different instance of the page. What to check: Change the label in a test element, save, open the live page in a private window, and temporarily clear the cache for that page only. Fix: Find the caching layer serving the old markup and refresh it through its normal controls. Rollback: Don’t edit the values in ten elements in a row. If you have lost track of the data, restore the last correct version of the page.

The final value is visible, but the animation does not run

Symptom: The static number appears, but the animation does not. Likely causes: The selected effect is incompatible with the setup, an optimization script changed how assets load, the block was already in view, or too many animations are competing on the page. What to check: Repeat the test on a clean draft with one element, open the page without browser extensions, and compare what happens during normal scrolling. Fix: Choose a more restrained effect, remove nearby motion, and check the optimization settings one at a time. Rollback: If the animation remains unstable, keep the static value readable. The information matters more than the effect.

Columns are cramped or labels overlap

Symptom: The row no longer looks balanced on a laptop or phone. Likely causes: Too many columns, long labels, doubled padding, or a conflict with theme styles. What to check: Open the row settings, temporarily shorten the labels, check an intermediate viewport width, and compare one row of three with two rows of two. Fix: Adjust the grid at the row level, shorten the labels without changing their meaning, and remove redundant spacing from one level. Rollback: Restore the previous column layout if the new one makes the wide version worse.

The color looks right in WPBakery but is hard to read on the site

Symptom: The color is set correctly in the element window, but the live text blends into the background or inherits another shade. Likely causes: A more specific theme style overrides it, the row background has changed, or an effect is layered over it. What to check: Use the browser inspector to see whether theme rules are changing the final color, without editing the code. Fix: First choose a contrasting built-in color and a solid surface. If needed, add a unique class and a small, reversible CSS change in the designated location. Rollback: Remove the latest custom style and return to the theme palette.

The block looks different after an update

Symptom: The numbers are still there, but the font, spacing, wrapping, or order of appearance has changed. Likely causes: The theme, WPBakery, or optimization tool was updated, or a cached set of CSS changed. What to check: Compare the page with your reference screenshot, test a minimal draft, and see whether the issue affects multiple pages. Fix: Restore the built-in row and element settings first, then make targeted adjustments for the theme or its custom CSS. Rollback: If the update failed on a copy of the site, delay publishing the changes until you can reproduce and diagnose the issue.

If the problem occurs only on the main page, while Counter works on a clean draft, don’t assume the add-on is at fault. Compare the containers, theme, cache, and neighboring effects. This control test narrows down the cause faster than deactivating plugins in bulk.

When CodeCanyon Counter is a good fit

CodeCanyon Counter makes sense when your site already uses WPBakery, you have several verified metrics, and the page needs a compact, configurable block. Its strength is a clear, focused purpose: add Counter to a familiar builder, apply a custom color, place multiple elements, and choose subtle motion. Everything else, including data quality, layout, contrast, translation, and post-publication checks, remains part of the editorial work.

If the test draft passes checks for saving, the live view, the mobile layout, and clear labels, you can download CodeCanyon Counter and add the block to the live page using the same steps. Don’t rush to add more effects or numbers. A successful metrics section feels at home on the page, presents facts without noise, and remains easy to understand after the next site update.