CodeCanyon PreviewBot - WordPress Plugin

CodeCanyon PreviewBot Setup Guide for Live WordPress Preview

CodeCanyon PreviewBot is not meant to dress up the admin panel. It is meant to speed up everyday work with drafts, pages, products, and layouts: you edit content in WordPress, and the open preview window refreshes without the constant need to hit the browser refresh button manually. In the sources, the product also appears under its former name, WP Live Preview, so that matters when searching older discussions and changelogs, but the rest of this guide uses the current name from the task.

What follows is not a purchase guide or a sales-style product card, but a hands-on guide to using the plugin in practice: what to check before installation, which modes to enable first, when a hotkey makes more sense than automatic refresh, how to test multiple windows, and why cache, permissions, the block editor, or a WebSocket connection can get in the way of live preview.

This guide is intended for site owners, content managers, theme developers, front-end specialists, and WooCommerce store administrators. If you edit one short post once a month, the benefit will be modest. But if you regularly check page appearance, CSS, blocks, responsiveness, and cross-browser output, live preview saves time precisely on those repetitive checks.

What problem live preview solves

WordPress already knows how to open a post or page preview in a new tab. The problem starts after that first preview: you keep changing text, blocks, CSS, images, templates, or product fields, while the preview tab stays frozen until you save the draft, refresh the page, and make sure you are looking at the correct URL. For a quick edit, that is manageable. On a landing page, product page, or long-form article, manual checking quickly turns into a loop of unnecessary steps.

PreviewBot closes that gap between the editor and the public-facing side of the site. According to the product listing, it can automatically refresh preview windows when changes are made in the post and page editor, supports hotkey-based refresh, multiple preview windows, and in newer feature descriptions mentions WebSockets, support for different browsers and devices, OnePreview mode, and improved WooCommerce compatibility. CSS sync for Visual Composer / WPBakery Page Builder is also explicitly listed.

It is important to understand where the line is: the plugin does not replace version control, a staging site, a WooCommerce test order, or cache validation for visitors. It helps you see draft results faster in a preview context. If you need to show content to an external client without admin access, that is a different use case, and plugins for public preview links are a better fit. There is a separate section on those below.

Where the impact is most noticeable

The plugin shines most in workflows where visual checking happens dozens of times in a single session. That includes editing a complex page in the block editor, working with WPBakery CSS, adjusting spacing, checking headings and images, fine-tuning a WooCommerce product page, and comparing responsive layouts across multiple browser windows. In those scenarios, the editor does not just need to see the final result. They need to quickly understand which specific setting changed the public-facing appearance of the page.

• A content editor can see whether a heading, image, callout, or table breaks the theme layout.
• A front-end specialist can keep several preview windows open at different widths and check responsiveness without constantly copying URLs.
• A store admin can edit a product page and spot more quickly if the gallery, price, tabs, or short description are displaying differently than expected.
• A theme developer can test styles on a real WordPress page instead of only inside the editor, where different CSS rules may apply.

Quick takeaway: PreviewBot is useful not because WordPress lacks preview functionality. It is useful because it connects the editor and already open preview windows into a single workflow.

Who this plugin is for, and when another approach makes more sense

CodeCanyon PreviewBot should be viewed as a tool for internal editorial and development work. It is especially useful on sites where pages are regularly refined by hand: landing pages, product pages, service pages, long articles, portfolios, and content with lots of images, blocks, and CSS settings. If one person edits a page while another reviews the result in a different browser or on another device, the WebSockets mode with multiple windows may be more convenient than simply refreshing a tab.

The plugin may be unnecessary on sites where all content is created through rigid templates and almost never reviewed visually. For example, if news is imported automatically, products are filled from CSV, and design is checked only on staging before release, live preview will not become a core tool. In those cases, a stable publishing workflow, cache control, and template testing matter more.

When PreviewBot is a good fit

It makes sense if you often catch yourself repeating the same sequence: change a block, save, open preview, refresh the tab, resize the window, then go back to the editor. The product works especially well in setups where the editor is on one monitor and the preview is on another, or where both sit side by side on the same screen. In that setup, the preview becomes a permanent control panel.

When to test carefully before rolling it out

You should be cautious if the site is heavily cached, runs behind a CDN, uses strict security rules, has a nonstandard editor, builds pages with multiple builders, or relies on custom post types with their own permission rules. In those cases, the plugin can still work, but you need to validate more than just whether the tab refreshes. You need to verify the full chain: the editor records the change, WordPress saves the draft or preview data, the preview window receives the signal, the browser does not block the connection, and the cache does not serve an old version.

Do not install the plugin directly on a production site with active advertising or significant traffic without running a short test on a site copy first. Even a small preview tool can conflict with cache, the editor, security policies, or user roles.

What to check before installation

You do not need to overcomplicate installation, but it is worth reducing a few risks upfront. PreviewBot affects the editing experience, open preview windows, and the network connection between them, so the checklist differs from installing a simple decorative plugin. The main goal of preparation is to understand where you will test updates, which editors are involved, and what to do if the preview starts showing an old version.

A working copy of the site and a rollback point

The best option is a staging copy or a local copy of the site. That lets you enable auto-refresh, WebSocket mode, hotkeys, and CSS sync without risking live pages. If you do not have staging, at least make a backup of the files and database before installation, and run the first test on a draft or a private test page.

For a site using a CodeCanyon plugin, it is especially important to keep the original archive and understand how you would return to the previous state. Rollback is usually simple: disable the plugin in Plugins, clear cache, close preview windows, and test the editor again. But if the site uses script optimizers, a CDN, or strict security rules, clear those caches as well after deactivation.

The editor, builder, and post types

Check exactly where you plan to use live preview. The product listing mentions pages and posts, Gutenberg Code Editor support, Visual Composer / WPBakery CSS handling, and improved WooCommerce compatibility. That does not automatically guarantee support for every third-party builder or every custom post type. If the site uses Elementor, Divi, a custom theme builder, ACF fields, or custom metaboxes, add them to your validation plan as separate scenarios.

Cache, HTTPS, and WebSockets

Most complaints about “changes not showing up” in WordPress are often tied not to the editor, but to browser cache, plugin cache, server-side cache, or a CDN. The official WordPress documentation specifically notes that WordPress does not include page caching by default, but caching plugins and managed hosting can still serve an older version. That matters even more for PreviewBot: the plugin may refresh the window exactly as intended, but the window may still receive cached HTML.

If you use WebSockets, check HTTPS, proxies, your CDN, and the browser console. Modern browsers block some insecure mixed requests, and the WebSocket connection needs to be allowed by your infrastructure. On an HTTPS site, any supporting resources and connections must be configured so the browser does not treat them as insecure.

User roles and preview access

In WordPress, drafts and private preview links are usually accessible only to users with the proper permissions. If a designer opens the preview in a separate browser without logging into the admin panel, they may see a login screen, the homepage, or an access error. That is not necessarily a PreviewBot problem. First make sure WordPress itself shows the preview manually for that user, without any auto-refresh involved.

Installation and a first test with minimal risk

For a commercial WordPress plugin delivered as a ZIP archive, the basic installation path is standard: admin panel, plugins section, upload archive, install, activate. What matters more here is not the installation flow itself, but the first validation after activation. Do not start with your real homepage or a complex product page. Use a test draft where it is safe to change text, an image, and one simple block.

Basic installation sequence

1. Open the WordPress admin panel as a user who has permission to install plugins.
2. Go to Plugins - Add New - Upload Plugin.
3. Select the plugin ZIP archive and click Install Now.
4. After installation, click Activate.
5. Check whether your version exposes a PreviewBot settings page, an editor metabox, or an icon in the top admin bar.

If WordPress says the archive does not contain an installable plugin, do not start uploading every nested ZIP file one by one. Commercial product packages often include documentation, the original archive, and a separate installable ZIP. Extract the package locally and find the file that contains the actual plugin folder with the main PHP file inside. Do not manually modify the plugin contents.

The first test after activation

Create or open a page draft. Use the standard WordPress preview, such as Preview in new tab. After the tab opens, return to the editor, change the heading or a short paragraph, save the draft with Save draft, or follow the workflow required by your editor version. If automatic refresh is enabled, the preview window should update without a manual reload. If hotkey mode is enabled, press the selected shortcut and confirm that the tab receives the new version.

Start by checking a simple text change. If even that does not refresh, there is no point in immediately troubleshooting WPBakery CSS, a WooCommerce gallery, or WebSocket communication between devices.

Once the simple test works, make the scenario more complex step by step: image, page template, custom field, WooCommerce product, builder CSS. That order saves time because you can immediately see at which level the chain breaks.

A settings map for after installation

The interface may differ from one version to another, so the logic of the configuration matters more here than promising the exact wording of every menu item. Based on the product page and changelog, the product is tied to automatic refresh, hotkeys, refresh intervals, multiple windows, WebSockets, OnePreview, quick access from the top bar, and the ability to disable PreviewBot completely. Those are the first things worth checking.

Preview window refresh mode

Start by choosing a mode: automatic refresh on change or manual refresh through a hotkey. Automatic mode is convenient when editing text, spacing, and blocks. But if the page is heavy and includes many requests, complex galleries, products, dynamic blocks, or third-party widgets, overly frequent refreshes may become more disruptive than helpful.

For a typical site, it makes sense to start with a moderate interval and a single preview window. If everything works reliably, add a second window for a different browser width. If the page takes a long time to load after every save, switch to a hotkey so you control exactly when the preview should refresh.

Hotkey behavior and browser conflicts

The product description explicitly notes that hotkeys depend on the system and browser. That is an important detail: some key combinations are already reserved by the browser, an extension, the operating system, or the editor itself. If the selected combination does not work, do not assume it is immediately a plugin bug. Try a different combination, a different browser, and a mode without third-party extensions.

WebSockets, OnePreview, and multiple devices

WebSocket mode is useful when the preview window needs to receive a signal not just in a neighboring tab, but in another browser or on another device. According to the changelog, OnePreview automatically changes the preview window URL when you switch to editing a different post or page. That is convenient for an editor who keeps one separate preview window open and does not want to open a new tab every time.

If the site infrastructure is complex, enable WebSockets deliberately. Check the browser console, network requests, HTTPS behavior, your CDN, and any corporate proxy. If the connection is blocked, temporarily return to local auto-refresh or hotkey mode and log the issue for the site administrator.

Initial settings table

This table helps you choose sensible starting values without trying to guess every site-specific detail in advance.

After each settings change, save it with Save Changes, close any extra preview tabs, and test one scenario at a time. If you turn on every mode at once, it becomes difficult to tell what actually fixed or broke the preview.

How the editor-to-preview connection works

PreviewBot is built around a simple principle: the editor records a change, and the preview window receives a signal to refresh or fetch fresh data. In standard WordPress, the user creates that link manually. With live preview, the link is automated, but it still depends on where the new page state is stored and whether the browser can retrieve the current result.

One window, multiple windows, and different widths

The product description says multiple preview windows can be opened by copying the current preview URL into new windows or tabs, and all of them will refresh when changes are made. In practice, that is useful for responsive checks: keep one window wide, narrow the second to tablet width, and use a third as a control browser. That does not replace full testing on real devices, but it quickly reveals obvious issues with spacing, heading wraps, and button visibility.

Why preview sometimes lags behind

Lag can appear at different levels. The block editor may not have saved the change yet. A builder may store CSS separately. WooCommerce may display some data only after the product is saved. Cache may return an old page. The browser may block an insecure request. That is why troubleshooting should follow the chain rather than reducing everything to “the plugin works” or “the plugin does not work.”

For an editor, that leads to a simple rule: if you need to verify the exact final state, first make sure WordPress shows the save status, then refresh the preview. Automatic mode is excellent for visual flow, but the final check before publishing should still include a manual save, a review in a standard tab, and validation under the appropriate user role.

Where not to expect magic

Live preview should not be expected to instantly reflect data that WordPress itself, or a third-party plugin, does not expose to preview until save time. That often applies to complex metafields, product data, dynamic blocks, shortcodes, widgets, external API data, and custom theme templates. In those cases, PreviewBot speeds up reloads, but it does not change the internal architecture of the data source.

Gutenberg, WPBakery, and WooCommerce specifics

The most valuable part of setup is not flipping a switch, but understanding how the plugin behaves with the editor your site actually uses. The product listing specifically mentions Gutenberg Code Editor, Visual Composer / WPBakery Page Builder, and WooCommerce. That means these scenarios should be tested through dedicated checks, not broad assumptions.

The block editor and Classic Editor blocks

The documented product limitations note that when Classic Editor blocks are used inside Gutenberg, changes may not be detected while you are typing and may only register after you click out of the block. That is normal for this kind of integration: a classic block inside a modern editor has its own state-update behavior. If an editor complains that preview is “not live” specifically inside a classic block, first ask them to click outside the block or use the refresh hotkey.

For standard blocks, test three kinds of changes: text, image, and block settings in the sidebar. If text refreshes but the image or block setting does not update until save, document that as behavior specific to that block or editor. Do not promise the team that every block type will behave the same way.

WPBakery CSS and older Visual Composer pages

WPBakery can store CSS in several places: global settings, page-specific CSS, element classes, or row and column design settings. PreviewBot claims CSS sync for Visual Composer / WPBakery, so start with simple CSS on a single page: change a block background color, spacing, or border. If the preview reflects the change immediately, move on to more complex rules.

Do not mix builder CSS, theme CSS, minification, CDN behavior, and browser cache in the same test. If a style does not appear, first check whether it was saved inside WPBakery itself, then inspect the page source and the Network tab in developer tools. Sometimes the problem is not preview refresh at all, but that the CSS is stored somewhere other than expected, or that the theme does not output it in the specific template.

WooCommerce and product pages

With WooCommerce, it helps to separate visual fields from store data. Titles, short descriptions, and images are often easier to validate than variations, prices, stock status, tabs, galleries, and blocks that depend on the product template. The product changelog mentions improved WooCommerce compatibility, but that is not a reason to assume every custom product card is guaranteed to work.

A practical store test looks like this: create a test product, change the short description, featured image, one attribute, and one visual page block. After each change, check what updates in the preview window. If some data only appears after Update, record that as a working rule for the team: PreviewBot speeds up validation, but the final product page still needs to be checked after saving.

Practical scenario: editing a landing page in two windows

Below is an example you can repeat without risking a live page. It shows how to use CodeCanyon PreviewBot in a typical editorial workflow rather than in the abstract: you have a service page or product page, you need to adjust the block structure, verify the text, and confirm the layout does not break at a different window width.

Goal

You need to update the top section of a landing page: replace the headline, revise the opening paragraph, choose a different image, and verify that the button stays visible as the window narrows. The result should appear in preview without constant manual tab refreshes.

Preparation

• The plugin is activated, and the basic preview mode has already been validated on a simple draft.
• A test page or a copy of a real page is open, without affecting visitors.
• The WordPress editor is open in one window, and the standard page preview is open in another.
• If you need to test responsiveness, the preview URL has been copied into one more narrower window.

Steps

1. In the editor, change the headline in the top section and wait for WordPress to register the change, or save the draft with Save draft.
2. Check whether the wide preview window updated. If hotkey mode is enabled instead of auto-refresh, press the selected shortcut.
3. Replace the image in the block. If the image does not update immediately, save the draft and check whether browser cache is interfering.
4. Narrow the second preview window and verify that the image is not covering the button, the headline is not breaking awkwardly, and important text is not disappearing.
5. If you are working with WPBakery, add simple CSS in the page settings and make sure the preview is showing that CSS, not an old cached version.

Validating the result

The scenario is successful if both preview windows show the same current text, the new image, and a correct layout. As an extra check, open the preview page in another browser under the same user account. If WebSocket mode is enabled for another device, test that too, but do not mix it into the first basic validation.

A detail that often causes confusion

If the wide window updates but the narrow one still shows the old version, the cause may not be PreviewBot at all. Check whether the second window is using an old preview link, whether authentication was lost, whether cache kicked in, or whether you are looking at the published page instead of the draft. First compare the URL and WordPress login status, then change plugin settings.

How to validate the result before publishing

Live preview speeds up preparation, but it does not eliminate the need for a final check. Before publishing, you need to confirm that the page is correct not only in the preview context of a logged-in editor, but also in a normal user scenario. That is especially important for pages with cache, forms, WooCommerce, dynamic blocks, and access restrictions.

Editor-side checks

• Save the draft or update the post using the standard WordPress button.
• Open the standard preview without extra experimental modes.
• Compare the page in a wide and a narrow browser window.
• Check that headings, images, buttons, and important blocks are not overlapping.
• If the page is already published, after Update review it as a normal visitor in a separate window.

Administrator-side checks

An administrator needs to look deeper: are there JavaScript errors, are requests being blocked, is cache serving an old version, and is auto-refresh overloading weak hosting. In developer tools, check the Console and Network tabs. For WebSockets, it is useful to confirm that the connection opens successfully and is not blocked by a security policy, proxy, or CDN.

Validation after clearing cache

If the published page does not match the preview, clear cache at the levels that actually exist on the site: the caching plugin, hosting-level server cache, CDN, and browser cache. Do not clear everything blindly every time. First identify exactly where the stale version appears: for the logged-in user, for a guest, in another browser, on another device, or only behind the CDN.

A solid final check looks like this: PreviewBot helped you refine the layout quickly, but the decision to publish is made only after a normal save, a visitor-style review, and proper cache validation.

Troubleshooting common preview issues

Live preview problems rarely have one universal cause. It is more practical to start from the symptom: what exactly is not refreshing, where it happens, which editor is being used, whether standard preview works without the plugin, and whether the console shows any errors. Below are checks that are especially relevant to this class of live preview plugins.

Symptoms, causes, and safe actions

Symptom	Possible cause	What to check	How to fix it
The preview window does not refresh at all	Standard WordPress preview is not receiving fresh data, or PreviewBot mode is turned off	Does manual Preview in new tab work after Save draft?	Get manual preview working first, then enable auto-refresh
It refreshes too often and interrupts typing	The interval is too short, or auto-refresh is enabled on a heavy page	Preview load time and the number of open windows	Increase the interval or switch to a hotkey
The hotkey does not work	The key combination is already used by the browser, system, or an extension	Try a different shortcut, another browser, or a mode without extensions	Assign a less contested shortcut and document it for the team
A Classic Editor block in Gutenberg refreshes only after clicking outside the block	A limitation in how changes are detected inside the classic block	Test a normal block and a classic block separately	Use click-out behavior or hotkey refresh as the working rule
WPBakery CSS is not visible in preview	The CSS is stored elsewhere, was not saved, or is being blocked by cache	Page CSS, global CSS, page source, and Network	Save the CSS in the correct location, clear cache, and test without minification
A window on another device does not receive updates	The WebSocket connection is blocked, or the device is not authenticated	Browser console, HTTPS, CDN, proxy, and draft-view permissions	Test the connection on the same network, then adjust the infrastructure or use the normal mode
An old published version appears after refresh	Browser cache, a caching plugin, server cache, or CDN	Guest mode, another browser, and cache clearing for the specific URL	Configure cache purging on page updates and exclude preview URLs if that is safe
The preview redirects to the homepage, login screen, or an access error	Lost authentication, an incorrect preview link, or insufficient permissions	Login status, user role, and standard preview without PreviewBot	Log in with the correct role, open a fresh preview link, and do not share a draft as if it were a public link

When it is better to roll back a setting

Do not roll back the whole plugin. Roll back the last mode you enabled. If windows stop refreshing after enabling WebSockets, disable WebSockets and test normal auto-refresh. If the page becomes too heavy to edit after enabling auto-refresh, switch back to hotkey mode. If the conflict started after a script optimizer was enabled, temporarily exclude preview scripts from bundling and minification, but do that through the optimizer settings, not by editing plugin files.

You do not need code changes in WordPress core, the theme, or PreviewBot for this kind of issue. Without a confirmed filter or an official extension method, it is safer to rely on plugin settings, cache settings, and a test page. Do not edit WordPress core, plugin files, or builder files just to fix a preview workflow.

Performance, security, and editorial discipline

PreviewBot speeds up work, but it can easily turn into a source of unnecessary load if you open too many windows and set refresh too aggressively. Be especially careful on weak hosting, on pages built with heavy builders, on large galleries, WooCommerce products, and dynamic blocks. Every refresh is a request to the site, plus loading HTML, CSS, images, and scripts. On staging, that may barely matter. On a production site with active traffic, it becomes much more noticeable.

How to avoid overloading the site

• Do not keep dozens of preview windows open at the same time.
• For heavy pages, use hotkey mode instead of auto-refresh on every change.
• Check responsiveness at two or three widths, not every possible screen size at once.
• Turn off PreviewBot through its available setting when editing is finished and live preview is no longer needed.
• On staging you can test more aggressively; on production, use the minimum mode that gets the job done.

Draft security

A draft preview window is not the same thing as a public client-facing link. If someone lacks permission to view the draft, that is not a bug. It is normal WordPress access control. For external review, use dedicated solutions with temporary preview links and a clear access policy. Do not send internal preview URLs to random people, and do not try to work around user permissions through live refresh settings.

SEO and indexing

Live preview itself should not be treated as a way to expose drafts to search engines. Before publishing, validate the regular published page, meta data, canonical settings, indexability, and cache using the tools already used on the site. PreviewBot helps you review design and content, but it does not guarantee a correct SEO outcome. If the page is built with a page builder, also check the final HTML and loading speed.

An editorial policy for ongoing use

If PreviewBot is being installed for a team rather than a single administrator, agree on a simple usage policy in advance. This is not about bureaucracy. It is about making sure every editor understands the same things: when to use live preview, when to save a draft, when to clear cache, and whom to notify when something fails. Without that, the team quickly ends up arguing about why preview updates for one person but shows an old version for another.

A good minimal policy fits into a few points. First, test changes on a draft or a page copy if the update affects the hero section, a form, a product block, or an important button. Second, use auto-refresh only on lightweight pages, and switch to hotkey mode for heavy layouts. Third, do not send internal preview URLs to outside people unless they have been granted WordPress access. Fourth, before publishing, always perform a standard check of the published page as a visitor.

It is also worth documenting the working hotkey combination and the browsers where it has been verified. If editors use different operating systems, the same shortcut may behave differently. In that case, it is better to choose a fallback shortcut or agree that on problematic pages the team will use the plugin's button or manual refresh mode in the interface, if your version includes one.

The most useful habit is to document not only the error, but also the test context: post type, editor, enabled PreviewBot mode, number of preview windows, presence of cache, browser, and the user’s login state. That short note saves the administrator time because it immediately shows where to look: permissions, cache, the WebSocket connection, a hotkey conflict, or the specifics of a particular builder.

When CodeCanyon PreviewBot is a good choice

PreviewBot is worth using if you frequently edit WordPress pages and want to shorten the manual verification loop: open preview, refresh the tab, compare widths, return to the editor. Its main strength is the connection between the editor and already open preview windows, especially if you care about hotkey mode, multiple windows, WPBakery CSS, or testing the page in another browser.

Before using it regularly, test a simple draft first, then a page in the real editor, then WPBakery or WooCommerce if the site uses them. After that, choose the minimum mode that does the job: automatic refresh for lightweight pages, a hotkey for heavy ones, and WebSockets only where you truly need different browsers or devices. If that validation matches your workflow, you can download the CodeCanyon PreviewBot archive and move on to testing it on your own site copy.

The main practical takeaway is simple: the plugin is useful when live preview is part of a disciplined workflow. Start with safe installation, then enable settings one by one, then run a real scenario, troubleshoot cache, and finish with a final check of the published page. In that setup, the tool speeds up work instead of adding another layer of confusing behavior.