CodeCanyon Responsive Pro - WordPress Plugin

A Guide to Responsive Settings in CodeCanyon Responsive Pro

This guide to CodeCanyon Responsive Pro will help you understand which element properties you can change for different screen sizes, prepare it to work with WPBakery Page Builder, set custom breakpoints, build a safe version of a section, and check the result before publishing. Instead of fixing the mobile layout one symptom at a time, you’ll work from the original element and its default styling to separate rules for the devices you need, then check the CSS cascade and roll back any change that causes problems.

CodeCanyon Responsive Pro extends WPBakery Page Builder. It lets you treat responsive design not as a separate layout, but as a set of exceptions for an existing element. This is especially useful on sites with pages that have been built in WPBakery for a while, where a heading wraps awkwardly on a small screen, spacing takes up too much width, cards feel cramped, or a particular block needs to disappear. This guide focuses on situations like these rather than general theory about mobile layouts.

First, identify which changes are actually needed at a particular width. Then create one rule, check the public-facing page, compare it with the default state, and only then move on to the next property. This order matters: the element’s own settings, row and column options, theme styles, additional CSS rules, and cache can all affect the page at once. The more focused each step is, the easier it is to tell what changed the result.

How Responsive Pro Extends Responsive Editing in WPBakery

WPBakery already lets you build pages from rows, columns, and elements, but adapting a specific property often calls for more precise control. Responsive Pro adds a set of device-specific options based on the devices you configure in the add-on. The product page lists supported properties such as borders and corner radius, margins and padding, background and color, text size and weight, letter and word spacing, alignment, wrapping, display, dimensions, size constraints, and positioning. The add-on also advertises a custom CSS selector and the ability to define any number of devices.

The point of this list isn’t to assign a separate value to every property. It’s to keep an element simple on a wide screen and change only what’s causing the problem on a narrow one. For example, a text card doesn’t necessarily need a new design for phones. Reducing its padding, removing a fixed width, or restoring its normal display may be enough. Changing one property at a time makes the cause and effect clear and avoids a pile of exceptions that are hard to maintain.

Default State and Responsive Overrides

It helps to distinguish between two layers. The default state is how the element looks without special conditions: its content, structure, usual spacing, color, and dimensions. A responsive override is a separate value that should apply only at a selected breakpoint. If you mix these layers, a mobile adjustment can mask a problem in the original styling. For example, if a card has a fixed width on desktop and looks clipped on a phone, randomly changing the font size shouldn’t be the first fix. Start by checking whether the fixed width is the underlying cause.

A useful note for each change has five parts: the element, its original value, the condition, the new value, and the visible effect. For a call-to-action block, that might look like this: “button in column - 32 px side padding - narrow screen - 16 px - label stays on one or two readable lines.” You don’t need to show this note to site visitors. It helps an editor distinguish a deliberate rule from an accidental setting months later.

Some properties are safer than others for an initial experiment. Padding, maximum width, and text size usually produce easy-to-check results. Positioning, forced height, and custom selectors call for more care because they can affect neighboring elements or override theme styles. Start with values that describe the block itself, not the entire page around it.

When Responsive Pro Is a Good Fit

CodeCanyon Responsive Pro is a good fit when content is already built in WPBakery and you need to make specific parts of a page readable without rebuilding the entire layout. Common candidates include a large heading in the hero section, a set of service cards, a block with text over a background, two columns with an image and description, a pricing table, a button panel, or a decorative element that gets in the way on a narrow screen.

• Typography. Adjust text size, line height, alignment, weight, or wrapping when text becomes hard to read.
• Spacing. Reduce padding or margins, or adjust width, height, or maximum dimensions when a block takes up too much room.
• Visibility. Control whether an element appears when a secondary decorative layer obscures the main content on a small screen.
• Appearance. Adjust the background, color, border, or corner radius when the contrast or shape no longer works at a different width.

In all these cases, the add-on doesn’t replace a well-structured page. If cards are in the wrong order, contain too much text, or use an image with unsuitable dimensions, a responsive setting won’t fix the underlying problem. Responsive Pro is most useful for fine-tuning a composition that’s already clear.

When This Approach May Not Be the Right Fit

Don’t start with Responsive Pro if the page is breaking because of invalid HTML, a theme conflict, or CSS that loads unpredictably. In that situation, changing values in the editor becomes guesswork: a rule may appear to work in the preview, then disappear after a page refresh or get overridden by another style. First find the source of the conflict, disable any unnecessary temporary changes on a copy of the site, and confirm that WPBakery can save the element’s default state.

The add-on also isn’t a tool for creating a separate mobile site. If the sections, content order, and navigation all change at every screen size, it makes more sense to revisit the page structure and the theme’s capabilities. Responsive Pro works at a smaller scale: keep the same section and meaning, but adapt its settings to the available space.

What to Check Before Making Your First Change

Before installing or enabling the add-on, choose one test page and one element with a clearly defined problem. Don’t start with the home page, an ad campaign, or a form that drives leads. Use a copy or draft where you can preserve the default state, check the page without cache, and roll back if needed. This test takes less time than searching through dozens of published sections for an accidental rule.

Make sure you’re using WPBakery Page Builder, not another builder with a similar historical name. Older sites often use the term Visual Composer in their interfaces and descriptions, but the current WPBakery product and the separate Visual Composer Website Builder are different tools. Responsive Pro is designed to work with WPBakery, so its settings need to be added to elements in the builder used to create the page.

Check the other dependency too: Responsive Pro extends the settings for individual elements, so it shouldn’t be your only defense against a nonresponsive theme. Open the test page in a regular browser, narrow the window, and note where the selected block breaks down. It’s helpful to capture a few before screenshots at wide, intermediate, and narrow widths. Then you can compare the same content under the same conditions instead of relying on a vague impression.

Environment Checklist

Before you begin, put together a short checklist. It helps prevent a common mistake: assuming the add-on isn’t working when changes haven’t reached the public-facing page because of cache, a different editor, or a change to the wrong element.

• Confirm that the test page opens in WPBakery and that changes to the element’s standard settings are saved.
• Back up the page or create a draft so you have a clear rollback point.
• Note which theme and other add-ons add their own design options to WPBakery.
• If the site uses page caching, clear it or temporarily bypass it after each test save.
• Choose actual widths to test. Instead of vague labels like “mobile” and “tablet,” use several states where the content’s behavior really changes.

Check before installing: If a basic change made in WPBakery itself doesn’t appear on the published page, don’t move on to responsive values. First resolve the issue with saving, caching, or editing the wrong version of the page.

Install and Enable Responsive Pro Without Losing the Existing Layout

Install Responsive Pro like any other WordPress add-on by uploading the ZIP archive you received through the plugin management area. After uploading and activating it, don’t open a dozen existing pages right away. Start with the test page you prepared in the previous step and confirm that the WPBakery editor loads fully and that the selected element’s settings open without errors.

A safe sequence matters more than speed. First, confirm the add-on appears among the active plugins. Then open the page in the editor, find the Responsive Pro section in an individual element’s settings, and save one simple change. If the new fields don’t appear, don’t try to compensate with custom styles. Check the setup instead: Is WPBakery active? Is the page being edited in a different editor? Is there a JavaScript error in the admin area? Does another add-on add a similar tab with conflicting fields?

Use the First Change as a Diagnostic Test

For your first test, choose a noticeable but safe property. Padding on a text block or a heading size for one additional device is a good option. Don’t start with position, a fixed height, hiding an element, or a CSS selector. If the basic setup isn’t working, those properties will give you too many possibilities to investigate.

1. Open the test page in the WPBakery editor and choose one element, not a row with a dozen nested columns.
2. Note its original appearance and the default value of the property you plan to change.
3. Open Responsive Pro settings, choose one additional condition, and make a small, easy-to-spot adjustment.
4. Save the page, then open the published page or preview in a separate tab.
5. Resize the window to the breakpoint and check whether only the expected change appears.

If the difference appears in the specified range, the basic chain is working: WPBakery saved the setting, Responsive Pro generated a rule, the browser applied it, and the cache didn’t serve an old copy. Only then should you move on to a real section. If there’s no difference, roll back the test setting and check the conditions instead of adding a second change.

How to Tell an Add-on Issue from a Page Issue

When a change doesn’t appear, work from the simplest checks to the more complex ones. First, confirm that you’re editing the same element you see on the public-facing page. Older sites often duplicate similar blocks, and the editor might be showing a draft or another language version. Then confirm that the page was saved. Next, rule out cache: refresh the page in a private window or use the site’s usual cache-clearing method. Only then check external CSS and conflicting add-ons.

Keep the order of styles in mind too. Responsive Pro creates responsive CSS rules for the selected properties, but the CSS cascade determines the final style in the browser. A more specific theme rule, a style inserted later, or custom styling from another add-on may take precedence. The symptom is usually straightforward: the value appears in the editor, but it’s crossed out in the browser inspector or replaced by another rule. That’s no reason to keep increasing specificity. First find the winning rule and decide whether it should be the default style or whether it needs a careful adjustment in a child theme.

Set Up Custom Devices and Breakpoints Without Creating a Mess

One of Responsive Pro’s advertised features is the ability to create any number of devices. That doesn’t mean it’s useful to create a condition for every phone model. In this setup, a device is a working label for a width range where the layout changes. The more conditions overlap, the greater the chance that two settings will affect the same property and produce unpredictable results.

Start with three practical ranges: wide, intermediate, and narrow. You can name them whatever you like, but the labels should explain why the range matters, such as “wide grid,” “narrow column,” and “phone text.” The name matters less than having a clear breakpoint. If cards start feeling cramped at an intermediate width, that’s where the rule belongs, not in a profile you call “tablet” out of habit.

Choose Breakpoints Based on Content, Not Device Names

Open the page, gradually narrow the window, and watch for the point where the layout becomes uncomfortable rather than looking for a device icon. A heading wraps in an awkward way, a button label becomes too long, two columns no longer fit, the background crops out the important subject, or the gap between cards turns into a blank band. That point is a candidate breakpoint.

Write down what you observe in simple terms: “At this width, the two columns still fit, but the text column is approaching the minimum readable width.” Then choose the least disruptive response. Often that means adjusting padding, text size, maximum width, or alignment. Don’t hide an element as your first response. If users need the information block, first try to preserve its meaning while reducing the visual clutter.

Inherit Values Across Conditions

Responsive settings are easier to understand when each new condition changes only what differs from the default layout. Suppose a heading’s size works well in the hero section at a wide width. For an intermediate width, change only its size and line height. For a narrow width, add only an alignment change or smaller side margins. That way, you can explain every setting: it isn’t a new, independent design, but a response to a specific space constraint.

Don’t assign the same value in every condition “just in case.” That makes the settings harder to maintain and hides which rule is actually needed. If the default value works at a smaller width, leave it as the default. If a change applies to all narrow states, set it in the nearest shared condition instead of copying it into every profile.

Configure CodeCanyon Responsive Pro: From Safe Settings to Precise Overrides

Once you’ve defined your devices, move on to the actual element. A good order is to adjust spacing first, then dimensions, then typography, and finally decorative properties. The reason is simple: changing a color or font weight won’t solve a block that doesn’t have enough width. If the text is still hard to read after you’ve fixed the available space, then font size, line height, and alignment become useful, targeted adjustments.

Open Responsive Pro settings for the specific element and define the goal before entering a value. Don’t think “try 18 px”; think “keep the button label readable without making the row wider.” This approach helps you make the fewest changes and avoid a situation where a heading’s size, width, padding, position, color, and border all change on a narrow screen when only one property was needed.

Margins, Width, and Maximum Dimensions

Margins separate an element from its neighbors; padding creates space between its content and its border. A large section with generous padding may look polished on a wide screen, but on a small one, that same padding takes up a noticeable share of the line. In Responsive Pro, start with the padding on the container, card, or text block. Reduce it to suit the available space without pushing text against the edge. After saving, check the block and its neighbors: changing margins can affect the rhythm of the entire column.

Width and maximum width are especially useful when an element was given a fixed value for a polished desktop layout. On a narrow screen, a fixed width can cause horizontal scrolling, clipping, or overlap with a neighboring block. The safe goal is to let the element use the available space while retaining a reasonable limit where needed. Don’t confuse this with forcing a height. Fixed heights are often riskier for text because localization, larger font sizes, or different content can add more lines.

Check Spacing After Each Change

After changing padding or width, make four checks. First, confirm that the page has no horizontal scrolling. Second, make sure the text isn’t pressed against the edge of its container. Third, check whether the stacking order of a decorative layer and a button has changed. Finally, return to a wide window: a responsive override shouldn’t make the default layout worse. If changes appear where you didn’t expect them, check the device range and whether there’s a second rule for the same property.

Text: Size, Line Height, and Wrapping

The product page lists responsive settings for font size, line height, letter and word spacing, alignment, weight, style, text transform, text decoration, whitespace, and overflow. This range is useful because it lets you adjust text without changing the theme’s typography globally. At the same time, it calls for discipline: typography responds best to small, coordinated changes, not a set of arbitrary values for every condition.

Start by identifying what makes the text hard to read. If a heading takes up four short lines, the cause may be an oversized font or excessive padding on the parent container. If the lines look crowded, adjusting line height may help. If the text unexpectedly extends beyond its container, first check the width, wrapping, and overflow settings. Be especially careful with white-space and text-overflow: they can hide content instead of making it easier to understand.

Don’t use a smaller font as a universal fix. The minimum comfortable size depends on the font, contrast, and length of the text. It may be better to change the alignment, reduce decorative padding, rework the wording in the editor, or give the heading more width. Responsive Pro can apply the solution you choose to the right condition, but readability should guide that choice, not the desire to preserve the desktop layout at any cost.

Use Backgrounds, Borders, and Rounded Corners to Support Contrast

Backgrounds, colors, borders, and corner radius are part of an element’s appearance. They’re useful when a block changes size on a narrow screen, sits next to a different background, or needs to stand out more clearly from nearby elements. For example, a card that’s easy to distinguish by spacing in a wide row might need a more visible border in a vertical list. That doesn’t mean you need a new decorative style for every device. Add only the detail that makes the separation clearer.

Check contrast with the actual content. Light text over a background image may work in a desktop layout, where the image fills a wide area, but become harder to distinguish after the image is cropped on a narrow screen. In that case, first check the background and text placement. If an additional color is truly needed, use it as a responsive adjustment. Don’t try to compensate for weak contrast with several layers of shadow and borders if the text is still hard to read.

Display, Height, and Positioning: Higher-Risk Settings

The display property is suitable for a clearly secondary detail: a decorative line, a repeated icon, an empty divider, or a block that duplicates information shown elsewhere. Before hiding anything, ask what the page will be like for someone viewing only the narrow layout. If a price, term, button, or explanation disappears, that’s the wrong choice. Try changing the layout or moving important content into the main page flow instead.

Use the same caution with height and maximum height. They can seem like a quick way to make cards uniform, but changing text and translations can make the outcome unpredictable. If you limit the height, be sure to check a long heading, a list, and the page after the content has been updated. Positioning requires even more care: use it only when you know which container the element is positioned relative to and how it will behave as the width changes. Otherwise, a responsive override can pull an element out of the normal document flow and cause it to overlap other content.

This sequence doesn’t limit what the add-on can do. It reduces the number of unknowns. Once everything is working, you can move on to more precise settings. If something breaks, the sequence also points to where to look: spacing, text, appearance, or an element being taken out of the normal flow.

How a Single Rule Changes the Page

Understanding this chain makes it easier to diagnose what you see on the page. It starts with a selected WPBakery element and its original styles. Responsive Pro then ties the property you choose to a configured device. After the page is saved, the browser checks the current width against the conditions and applies the CSS rule if it matches. The visible change might be to spacing, text size, visibility, or another property, but it should appear only in the state for which it was set.

This model explains why you need to check the page at an actual width, not only by clicking a device icon in the editor. It also explains how two rules for the same property can conflict and why a theme style can sometimes take precedence. Responsive Pro creates the override, but the page’s entire CSS environment determines the final appearance. The next section shows how to apply this chain to one real section without extending the experiment to the whole site.

Practical Example: Make a Services Section Easier to Read

Consider a common task on a services page. The hero area contains a WPBakery row with three cards, each with an icon, a short heading, a paragraph, and a button. The layout looks tidy on a wide screen. As the window narrows, the headings wrap onto too many lines, the cards retain too much padding, and differences in card height make the buttons look out of alignment. The goal isn’t to create a different page for phones. It’s to preserve the meaning of all three services, give the text room to breathe, and keep the calls to action easy to spot.

This example is useful because it involves several real Responsive Pro properties without requiring you to use them all. We’ll adjust spacing and text, not positioning or visibility. If the section is readable after the first two steps, no further changes are needed.

Step 1. Note the Original Structure

Open the page in WPBakery and identify where the row ends and an individual card begins. Then trace the nesting: row, column, container, text element, button. If you set padding on the text instead of the container, the card’s background and border will stay the same, and the result may not be what you expect. If you change the column width, you’ll change the whole grid rather than a single card. Identify the element you’re working on before opening its settings.

Make a brief note of the original state. For example: the card has generous padding; the heading size works only in a wide column; the button follows the paragraph; the background and border are visible; the content must remain visible. This note matters more than a list of exact pixel values: it shows which parts of the structure the responsive adjustment needs to preserve.

Step 2. Find the Width Where the Problem Starts

Open the public page or preview and narrow the window. Don’t stop at the first noticeable line break: a line break alone isn’t always a problem. Look for the point where the card stops feeling comfortable. In this example, it happens when side padding takes up too much room for the text, the heading breaks into too many short lines, and the button looks disconnected from its description.

At that width, select a device in Responsive Pro or create a clear condition for a narrow column. You don’t need to pick a popular phone size. The condition should reflect the state of your layout. If another template or font changes the breakpoint later, you can revisit it as a deliberate rule rather than an unexplained device profile.

Step 3. Reduce the Card’s Padding First

Open Responsive Pro for the card container and reduce its padding for the selected condition. Keep enough space around the text, but don’t preserve the desktop styling at any cost. After saving, check the narrow layout and see whether the text has more room. This change alone may make the heading easier to read and bring the button closer to the paragraph without changing the button’s own styles.

If that solves the problem, don’t add another setting just to feel like you “need to do more.” Spacing is part of responsive design. Often it’s the spacing, not the font size, that causes the problem. If the heading still looks too large, move on to the next step.

Step 4. Adjust Typography Only for the Text That Needs It

Open the heading’s text element, not the entire card. For the same condition, make a modest adjustment to the font size or line height. Choose one main control: if the characters themselves are too large, change the font size; if the words are readable but the lines feel crowded, change the line height. Don’t also change the weight, letter spacing, text transform, and width until you know the problem can’t be solved without them.

Check the service card with the longest name. Don’t evaluate the rule only on a card with a short heading. The longest phrase will show whether the layout still feels balanced. If the content is multilingual, test with the longest translation. That helps avoid a situation where the site looks fine in the editor in one language but the card height breaks in another after publishing.

Step 5. Check the Button and Vertical Flow

Now look at the card as a whole. The button should stay close to its explanation, but it doesn’t have to line up vertically with the buttons in the other cards if their content differs. Trying to align every button with a fixed paragraph height or rigid positioning can create a bigger problem at the next screen size. If the height difference is modest and the section is readable, preserve the natural document flow.

If the button really does get lost, first check its margins and padding. Then make sure it doesn’t have its own width or display rules. Only after that should you decide whether the button needs a targeted adjustment. The same principle applies: one element, one condition, one change you can explain, then check again.

Step 6. Check the Wide and Intermediate Layouts Again

Don’t finish as soon as the narrow layout looks right. Return to a wide window and make sure the cards retain their original appearance. Then check an intermediate width, where the grid hasn’t collapsed to a single column but is already running short on space. This is often where you’ll find a second symptom. The narrow-screen rule may be fine, while the intermediate layout needs a small adjustment of its own.

If the intermediate layout looks good, don’t create another device. If it doesn’t, add a separate condition and fix one specific problem, such as slightly reducing the padding. Don’t copy over the full set of mobile values. An intermediate layout has a different width and may need a different adjustment.

Check the Results: Make Sure the Rule Works as Intended

You can’t confirm responsive behavior from a single screenshot. A working rule should produce the expected outcome across its specified range, leave neighboring states intact, and remain in effect after a normal page refresh. Put together a short check and repeat it after every meaningful change. That’s quicker than waiting for users to tell you the page looks different on their devices.

Check the Page in a Browser

1. Open the page in a wide window and make sure the default styling hasn’t changed.
2. Narrow the window to the breakpoint where the original problem occurs and check the selected element.
3. Keep narrowing the window and confirm that text isn’t clipped, the button is available, and the page doesn’t scroll horizontally.
4. Refresh the page normally, then check it in a separate private window to see the result without your usual browser data.
5. Check neighboring sections. A broad selector shouldn’t add unexpected spacing, hide content, or cause elements to overlap.

If everything looks right at one size but jumps at a slightly wider or narrower one, that isn’t a minor cosmetic issue. It suggests the conditions overlap or leave a gap. Revisit the device names and check which rule should apply to that range. Don’t try to fix the jump with a third arbitrary value. First restore a clear system of conditions.

What a good setting looks like: You can explain every responsive change in one sentence: which element changes, under what condition, which property changed, and what problem it fixes.

What to Record for Future Maintenance

After configuring the page, leave a short note in the site’s working documentation: the page, section name, conditions, properties changed, and the reason. You don’t need to record every visual value if it’s visible in the editor. The context is what matters. For example, note that the card padding was reduced for a narrow column and the heading was adjusted to accommodate longer service names. This is especially useful when another editor updates the page later or a theme update changes the default typography.

Check the rule again after a significant content change. A new long heading, a different button, a translation, or a replacement background image can change the conditions you started with. Responsive Pro shouldn’t make you afraid to update text. Clear, small rules make it easier to see what changed and where an adjustment is needed.

Responsive Pro Troubleshooting: Why a Responsive Rule Isn’t Working as Expected

Most problems with responsive settings don’t mean the add-on is broken. The issue is usually in one of four places: you’re editing the wrong element, the rule doesn’t match the current width, stronger styles override the saved CSS, or the browser is serving an older page from cache. Troubleshooting is faster when you check these points in the same order instead of changing values at random.

Start with one visible symptom. For example: “The card’s padding stays the same in a narrow window.” Then reduce the number of variables: one test page, one element, one device, one property. A complex element with many nested blocks isn’t a good place for an initial test because it adds too many competing sources of styling.

Symptom: A Section or Setting Is Missing from the Editor

First confirm that the add-on is active and that you’ve opened the page in WPBakery Page Builder. Some sites use the block editor, another page builder, or old templates that look like WPBakery on the public-facing page but are edited differently. Then open the settings for an individual standard element and check whether the Responsive Pro section appears. If it’s available for only some elements, don’t assume something is broken. The add-on may add settings only to the element types supported by your setup.

If the WPBakery interface doesn’t load fully, you see an error in the admin area, or the settings window won’t open, first deactivate recently added extensions on a copy of the site. Compare when the symptom started with updates to the theme, the builder, or another add-on. Don’t delete working settings from a live page to run an experiment. Reproduce the problem in a controlled environment and see whether it goes away when the conflict is removed.

Symptom: The Value Is Saved, but Nothing Changes on the Page

Check each step in the chain. First, did you save the page after making the change? Second, are you opening the same page and language version that you edited? Third, are you within the selected device’s range? Fourth, could the cache be serving old HTML or CSS? Only after these checks should you open the browser’s developer tools and see whether the rule appears among the element’s styles.

If the rule is there but crossed out, it lost in the cascade. Find the winning declaration and where it came from: the theme, custom CSS, a WPBakery style, an optimizer, or another add-on. Choose a fix based on the source. If a theme rule is too restrictive, it may be safer to adjust it in a child theme or the project’s designated location for custom styles than to create a more aggressive override on every element. If Responsive Pro needs to take precedence for one specific element, make sure the custom selector targets that element rather than the entire site.

Symptom: The Rule Applies at the Wrong Width

This almost always points to how the devices are defined or to overlapping conditions. Don’t determine the width based on how one phone looks. Browser zoom, scrollbars, and the preview environment can all affect what you see. Instead, gradually resize the window and note the point where the layout jumps. Then compare that point with the conditions you configured.

If two rules change the same property, the outcome depends on their order and the CSS cascade. Simplify the setup: temporarily leave one rule enabled and confirm how it behaves, then restore the second and check the boundary between them. A condition called “mobile” shouldn’t automatically change everything below an arbitrary number. Its purpose is to define a range that your content actually needs.

Symptom: The Page Scrolls Horizontally on a Phone

Don’t start by reducing the font size. Horizontal scrolling usually means an element’s width, margin, transform, border, or positioning takes it beyond its container. Temporarily highlight the problem section in the browser and check its child elements. Pay particular attention to fixed widths, oversized margins, absolutely positioned elements, and images that don’t shrink with the column.

Once you find the source, change only that element. If it’s a container with a fixed width, add a responsive adjustment to its width or maximum dimension. If the problem is a side margin, reduce the margin instead of changing the width of all child elements. If a decorative layer is responsible, first decide whether it’s needed at a narrow width. The fix should return the element to the normal flow while keeping its content available.

Symptom: Text Is Clipped, Overlapping, or Too Small

Check possible causes in order. First check the container width and padding, then whitespace and overflow, then font size and line height. Clipped text may be caused by white-space or text-overflow, but those properties are often not the underlying problem. They may be a later attempt to hide a line that’s already too long. Restore natural wrapping if the meaning requires it, then adjust the spacing or typography.

Text that’s too small is a different problem. A solution that makes the whole block fit isn’t successful if visitors have to zoom in to read it. Check whether you can free up space by reducing padding, changing alignment, or adjusting the container size. If the heading is simply too long, revise the page copy. Responsive Pro controls presentation, but it doesn’t replace editing.

Quick Troubleshooting Guide

What You See	What to Check First	Safe Action
Setting isn’t visible	Add-on status and WPBakery editor	Check a standard test element and look for add-on conflicts
Change doesn’t apply	Save status, page, range, and cache	Check the CSS cascade before adding another rule
Effect appears in the wrong range	Overlapping conditions	Simplify the devices and check each rule’s breakpoint
Horizontal scrolling appears	Size and spacing of a specific child element	Fit the element into the available width without hiding useful content
Text is clipped	Container, wrapping, and overflow	Restore readability before adjusting the font

If troubleshooting requires you to disable settings, record what you’re disabling and why. Remove one questionable condition, save the page, check it, and then decide whether to restore the rule with different settings. Resetting everything at once takes away your main evidence and can create a new problem unrelated to the original one.

When a Custom Selector Makes Sense

The product page advertises the ability to apply CSS through a custom selector. It’s a powerful tool, but not a good place to start. Use it when you know exactly which nested element you need to change and the element’s standard settings aren’t enough. For example, you might need to adjust a nested part of a third-party WPBakery element that has a stable class but doesn’t expose the property directly. Before using the selector, check in a browser that the class is unique to the relevant section and doesn’t change when the content is updated.

Don’t target a general class such as a button, heading, or column if the page has many of them. Add the section as context, test on a copy, and note why the selector is needed. If something unexpected happens, first disable that specific custom rule instead of removing all the page’s responsive settings.

Useful Pairings and Safe Improvements for Responsive Rules

Responsive Pro handles responsive values for individual WPBakery elements. The theme controls default typography, the grid, global colors, and shared styles. A caching plugin serves the files and pages that have already been generated. Keep those responsibilities separate in your work too: don’t reproduce the theme’s global layout in dozens of individual block settings, and don’t try to fix cache with a new responsive rule.

Use a Child Theme for Default Styles

If the same stable style is needed across the site, keep it in the project’s designated location for custom styles or in a child theme. For example, a shared container width, typography scale, and standard image behavior should be part of the baseline. Apply Responsive Pro on top of that baseline where a specific WPBakery section needs to respond to screen width. This keeps global styles from being duplicated across pages and leaves each responsive override short and easy to understand.

Before moving a rule into a child theme, confirm that it really is repeated in several independent sections. If it’s needed only for the hero block on one page, making it global will make maintenance harder. To roll back, first disable the latest change on a test copy, then clear the cache and compare the default layout. Don’t edit WordPress core, WPBakery, or the add-on itself: updates will overwrite those changes and make the cause harder to find.

Check Cache as a Separate Step

Cache doesn’t inherently conflict with responsive design, but it can give you a false impression. The editor may have saved the new values while visitors still see an older cached copy. Follow a simple rule: after changing Responsive Pro, save the page, clear only the cache the site actually uses, and check again in a separate tab. If the site has multiple caching layers, record the order for clearing them in the project’s working instructions.

Don’t add new CSS overrides until you’ve confirmed that the browser received the latest page. Otherwise, you may end up with two rules: the first one was correct, while the second was added only in response to an old copy. Once the cache refreshes, the second rule can cause a new problem. A safe rollback is to remove the latest unnecessary setting, refresh the cache again, and check the original intent.

Content and Images Are Part of Responsive Design

Don’t separate the design settings from the content. A long card depends on more than padding: the actual heading length, image proportions, order of information, and button size all matter. If the card still feels crowded after you adjust the spacing, check the text. It may contain two calls to action that say the same thing, a subtitle that’s too long, or an image that’s trying to convey information better presented as text. That doesn’t mean you shouldn’t use Responsive Pro. It means using it alongside a careful review of the page.

When replacing photos, check the original aspect ratio and the subject’s position in the image. A responsive container height won’t bring back an important part of an image that was cropped elsewhere. Choose an appropriate file or adjust its display using the element’s standard settings first, then fine-tune spacing and dimensions in Responsive Pro. That way, the rule solves a real layout problem instead of compensating for an unsuitable source image.

When CodeCanyon Responsive Pro Is a Good Choice

The add-on makes sense if your site is already built with WPBakery Page Builder and you need to control how specific elements behave at different widths. Its strength is precision: you can tie spacing, dimensions, text properties, display, and other settings to meaningful conditions instead of trying to rewrite the entire layout. The best results come from understanding the default structure first, identifying one visible symptom, and giving every override its own check and a clear rollback plan.

Don’t rush to fill in every available field. Start with a test page, confirm one safe change, check it without cache, and record the reason for it. Then you can adapt important sections one at a time: headings, cards, blocks with backgrounds and buttons. Done this way, the settings remain useful documentation for the site rather than a collection of unexplained overrides.

If this approach suits your page and the test checks out, you can download CodeCanyon Responsive Pro and start with a copy of one section instead of making sitewide changes.