Clear Caches After an Update

Overview

After updating KineticHub, WordPress may confirm that the new plugin version is installed while the public website continues to display older styles or behavior.

Possible symptoms include:

• Old block controls remain visible in the editor
• A recently fixed issue still appears on the frontend
• New settings are missing
• A block uses outdated styling
• An animation behaves differently for administrators and visitors
• Mobile devices display an older layout
• A block works after several refreshes but not consistently
• Old generated CSS or JavaScript is still being served

This usually happens when one or more cache layers still contain files generated before the update.

Clearing only the browser cache may not be enough.

Confirm that the update completed

Before clearing caches, confirm that the intended KineticHub version is installed.

Go to:

Plugins → Installed Plugins

Locate KineticHub and check the displayed version.

When using KineticHub PRO, also confirm that:

• The premium package is active
• The license remains connected
• KineticHub Free is not active at the same time

Do not begin troubleshooting the new release while WordPress is still using the previous plugin version.

Why old files can remain visible

A WordPress website may use several independent cache layers.

These can include:

• Browser cache
• WordPress page cache
• Generated CSS cache
• Generated JavaScript cache
• Object cache
• Hosting or server cache
• CDN cache
• Mobile cache
• Guest optimization cache
• Critical CSS
• Remove Unused CSS files
• Service-worker or PWA cache

Each layer may need to be cleared separately.

Purging one cache does not guarantee that every other layer has also been refreshed.

KineticHub asset versions

KineticHub registers its shared frontend assets using the current plugin version.

Under normal WordPress loading, a new version changes the asset URL version parameter and helps browsers request the updated file.

However, external cache and optimization systems may create their own generated files.

These generated files may continue containing older KineticHub CSS or JavaScript even after the original plugin asset has changed.

This is why generated optimization files should be rebuilt after an update.

Recommended cache-clearing order

Use this order after updating KineticHub:

1. Confirm the new KineticHub version
2. Clear generated CSS and JavaScript
3. Purge the WordPress page cache
4. Clear the object cache when applicable
5. Purge the hosting or server cache
6. Purge the CDN cache
7. Clear any separate mobile or guest cache
8. Open the page in a private browser window
9. Test while logged out
10. Test the editor and frontend separately

This order reduces the chance that an older layer recreates or continues serving stale files.

Clear generated CSS and JavaScript

Optimization plugins may create combined or processed versions of frontend files.

These can include:

• Minified CSS
• Combined CSS
• Critical CSS
• Remove Unused CSS output
• Minified JavaScript
• Combined JavaScript
• Delayed JavaScript lists
• Guest-optimized files

Look for options such as:

• Regenerate CSS
• Purge Generated CSS
• Clear Optimized Files
• Delete Used CSS
• Regenerate Critical CSS
• Clear Minified Files
• Purge All Optimization

Run the relevant cleanup after updating KineticHub.

A normal page-cache purge may not delete these generated assets.

Clear the WordPress page cache

A page cache stores the rendered HTML sent to visitors.

That cached HTML may still reference:

• Older KineticHub asset URLs
• Older block markup
• Previous data attributes
• Old responsive classes
• Old inline configuration
• Old page content

Use the cache plugin’s purge option.

Depending on the plugin, it may be named:

• Purge All
• Clear Cache
• Flush Cache
• Delete Cache
• Clear Page Cache

After purging, load the page while logged out.

Administrators are often excluded from page caching and may see a newer version than normal visitors.

Clear the object cache

An object cache stores WordPress data in memory.

Common object-cache systems include:

• Redis
• Memcached
• Hosting-level persistent object cache

Normally, a KineticHub frontend style issue is more likely to involve page or asset caching than object caching.

Clear the object cache when:

• Dashboard settings appear not to update
• An enabled or disabled block retains its previous state
• WordPress continues returning old plugin options
• The website uses a persistent object cache
• Other cache-clearing steps did not refresh saved settings

Use the official WordPress, hosting, or cache-plugin control.

Do not delete cache files or Redis databases manually without understanding what else uses them.

Clear the hosting or server cache

Some hosting providers cache pages before WordPress processes the request.

This cache may remain active even after the WordPress cache plugin has been purged.

Open the hosting control panel and look for options such as:

• Clear Server Cache
• Purge Full Page Cache
• Flush Dynamic Cache
• Purge Varnish
• Clear NGINX Cache
• Clear Hosting Cache

The exact label depends on the hosting provider.

When the hosting platform provides its own WordPress plugin, use its official purge control.

Purge the CDN cache

A CDN may continue serving old copies of:

• CSS
• JavaScript
• Images
• Fonts
• HTML
• Video cover images

Purge the affected KineticHub assets or perform a complete CDN purge when targeted invalidation is not available.

After purging, confirm that the page source and Network panel use the expected current files.

A CDN cache can affect both visitors and administrators.

Clear separate mobile caches

Some cache and optimization systems generate separate versions for:

• Desktop
• Mobile
• Tablet
• Logged-in users
• Logged-out visitors
• Different geographic regions
• Different languages

A mobile layout may remain outdated even when the desktop page is correct.

After changing responsive behavior or updating a mobile fix:

1. Clear the normal page cache
2. Clear the mobile cache
3. Clear generated CSS
4. Purge the CDN
5. Test on a real mobile device

Do not assume that a desktop cache purge also clears the mobile version.

Clear guest optimization

Some performance plugins apply additional optimization only to visitors who are not logged in.

This may include:

• JavaScript delay
• Critical CSS
• Guest-mode caching
• Remove Unused CSS
• Combined files
• Separate cached HTML

The page may therefore work while you are logged in but remain broken for normal visitors.

Always test:

• While logged out
• In a private browser window
• On a different browser
• On a real mobile device

Clear browser cache

After clearing WordPress and server caches, reload the page without using the browser’s stored files.

You can:

• Open a private or incognito window
• Perform a hard refresh
• Clear cached images and files
• Test in another browser
• Test from another device

A private browser window is usually the simplest verification method.

It does not clear the website’s server cache, but it reduces the chance of viewing locally cached assets.

Hard refresh

A hard refresh asks the browser to request the page and its assets again.

Common shortcuts include:

Windows and Linux

Ctrl + F5

or:

Ctrl + Shift + R

macOS

Command + Shift + R

Browser behavior can vary.

A private window remains useful because some extension, storage, or service-worker data may still affect a normal tab.

Service workers and PWA caches

Websites using a Progressive Web App or service worker can cache frontend files separately from the normal browser cache.

Possible symptoms include:

• The website updates in one browser but not another
• The mobile home-screen version remains old
• Old files return after a normal refresh
• The browser reports that files are served by a service worker

Temporarily unregister the service worker or clear the site’s application storage while testing.

Then confirm that the PWA system correctly refreshes its cached assets after deployment.

Reload the WordPress editor

The Gutenberg editor can remain open while the plugin is updated.

That editor tab may still use JavaScript loaded before the update.

After updating KineticHub:

1. Save any unsaved page changes
2. Close or fully reload the editor tab
3. Open the page again
4. Select the affected block
5. Review the updated controls

Opening and closing only the settings sidebar is not sufficient.

The complete editor page should be reloaded.

Save the page again only when necessary

A plugin update normally does not require every page containing KineticHub blocks to be resaved.

Do not resave all pages automatically.

Resave a page only when:

• The update introduces a migration that requires it
• A specific setting needs to be changed
• The block reports invalid content
• Support instructions explicitly require resaving
• The page itself contains unsaved changes

Repeatedly resaving a broken or unregistered block may change its saved data.

Restore plugin registration first when WordPress reports an unavailable block.

Check whether the frontend uses the new files

Open browser developer tools and select the Network panel.

Reload the page and filter for:

• kinetichub
• core.js
• Block-specific JavaScript
• Block-specific CSS
• Global animation CSS

Check:

• The request returns 200
• The URL points to the active plugin directory
• The version parameter is current
• The response is not marked as an old CDN cache
• The file is not being served by an outdated combined bundle
• The browser is not using a stale service-worker response

Disable the browser cache from developer tools while the panel is open when necessary.

Check the page source

View the public page source and search for:

kinetichub

Confirm that the HTML references the expected plugin and asset paths.

When the source still references an older version or a removed plugin folder, an HTML, CDN, or optimization cache is still active.

The source shown to logged-in administrators may differ from the source shown to anonymous visitors.

Test both where appropriate.

Clear caches after a Free or PRO switch

When switching between KineticHub Free and PRO:

1. Deactivate the old package
2. Activate the intended package
3. Confirm that only one edition is active
4. Activate the PRO license when applicable
5. Clear generated CSS and JavaScript
6. Purge the page cache
7. Purge server and CDN caches
8. Reload Gutenberg
9. Test the frontend while logged out

Old generated files may still reference the previous plugin directory.

This can cause missing scripts, missing styles, or duplicate behavior.

Clear caches after changing dashboard settings

Clear caches when changing settings that affect the frontend, including:

• Performance Mode
• Mobile Motion
• Asset Optimization
• Shared visual values
• Enabled or disabled blocks
• Custom CSS, when available in the installed version

Some dashboard changes affect only future page loads.

An already cached HTML page may continue using the previous configuration.

Clear caches after editing responsive settings

Responsive changes may be stored correctly in WordPress while generated CSS or mobile HTML remains outdated.

After editing mobile or desktop behavior:

1. Update the page
2. Purge the page cache
3. Clear generated CSS
4. Clear the mobile cache
5. Purge the CDN
6. Test at the intended viewport width

Do not judge responsive changes only from a desktop administrator session.

Clear caches after replacing media

When replacing an image, audio file, video, or cover image:

• Clear page cache
• Purge CDN cache
• Clear image optimization cache
• Regenerate thumbnails when required
• Confirm the media URL
• Test in a private browser window

A CDN may keep the older file when the replacement uses the same URL.

Using a new filename can make cache invalidation more reliable for important media changes.

Cache clearing and performance

A full cache purge temporarily removes optimized copies.

The first visitor after the purge may experience a slower page load while caches and generated files are rebuilt.

This is normal.

For important production websites:

• Purge during a lower-traffic period
• Regenerate critical CSS before announcing completion
• Preload important pages where the caching system supports it
• Test the homepage and major landing pages
• Confirm that generated files rebuild successfully

Do not avoid necessary cache clearing solely because the first request may be slower.

Do not disable caching permanently

Caching is not inherently incompatible with KineticHub.

When clearing caches solves the problem, the next step is to ensure that the cache correctly refreshes after updates.

Do not permanently disable all performance features unless one has been confirmed as incompatible.

Use targeted exclusions for:

• A specific KineticHub script
• A block-specific stylesheet
• JavaScript delay
• Remove Unused CSS
• Critical CSS processing

Keep unaffected optimization features enabled.

Do not delete cache directories manually

Avoid manually deleting:

• WordPress cache directories
• Optimization-plugin directories
• Server cache files
• CDN files
• Redis data

unless the responsible plugin, host, or developer specifically instructs you to do so.

Manual deletion can:

• Remove unrelated site data
• Cause permission problems
• Interrupt cache regeneration
• Leave incomplete generated files
• Affect other websites on the same account

Use the provided administration controls whenever possible.

Recommended verification process

After clearing caches:

1. Confirm the installed KineticHub version
2. Reload the WordPress dashboard
3. Open the affected page in Gutenberg
4. Confirm that the expected controls are available
5. Open the frontend in a private browser window
6. Test while logged out
7. Test desktop
8. Test mobile
9. Test the affected interaction
10. Check the browser Console
11. Check the Network panel
12. Confirm that updated assets are loaded

Do not consider the issue resolved after checking only the editor.

Troubleshooting

The update is installed, but the old styling remains

Clear generated CSS, page cache, server cache, CDN cache, and browser cache.

Inspect the Network panel to identify the stylesheet being served.

New editor controls are missing

Reload the complete WordPress editor.

Clear browser and administration optimization caches.

Confirm that the new plugin version is active.

The frontend is updated for administrators but not visitors

Guest page caching or guest optimization is active.

Purge the logged-out cache and test in a private browser window.

Desktop is updated, but mobile remains old

Clear any separate mobile cache, responsive CSS, CDN cache, and browser cache on the mobile device.

One page remains outdated

The caching system may use page-level caching.

Purge the affected URL specifically or run a complete page-cache purge.

Also check whether that page has its own critical CSS file.

CSS is updated, but the animation still uses old behavior

Clear generated JavaScript, combined files, delayed-script caches, server cache, and CDN cache.

Confirm that the current KineticHub script is loaded.

The block becomes unstyled after purging

The optimization plugin may not have regenerated its CSS correctly.

Temporarily disable CSS optimization and test the original KineticHub files.

Then regenerate the optimized files.

The page works briefly and then becomes old again

A higher cache layer may be rebuilding the stale version.

Check:

• Hosting cache
• CDN cache
• Cache preload
• Service worker
• Mobile cache
• Critical CSS generator

Clear caches from the outermost systems as well.

A private browser still shows the old version

The stale content is probably coming from the server, CDN, page cache, or service worker rather than normal browser cache.

Inspect response headers and the Network panel.

The asset version is current, but the behavior is still wrong

The problem may not be caching.

Check:

• JavaScript errors
• Theme conflicts
• Parent layout
• Optimization rules
• Saved block settings
• Required media
• A regression in the current KineticHub version

Continue with the relevant troubleshooting document.

The cache plugin shows an error while purging

Record the error and check its documentation or support resources.

Do not repeatedly purge while the cache system is failing to write or regenerate files.

When caching is probably not the cause

Caching is less likely to be the main cause when:

• The problem appears in every browser and device
• The latest files are confirmed in the Network panel
• The issue continues with caching and optimization disabled
• Browser console errors reference KineticHub
• The block fails in a simple test page
• The same problem appears on a fresh staging installation
• Required media or content is missing
• A parent layout consistently breaks the block

Continue troubleshooting instead of repeatedly clearing caches.

Information to collect for support

Before contacting KineticHub support, collect:

• KineticHub version
• Free or PRO edition
• Affected block
• Page URL
• Previous and current plugin versions
• Cache plugin name
• Optimization plugin name
• Hosting cache system
• CDN provider
• Enabled optimization settings
• Whether generated CSS and JavaScript were rebuilt
• Whether the issue affects logged-out visitors
• Whether mobile uses a separate cache
• Browser Console errors
• Relevant Network requests
• Screenshot or short recording
• Whether the problem continues with caching disabled

Do not include passwords, private access details, payment information, or complete license keys.

Next step

Continue with Sticky or Pinned Effects Are Not Working when a KineticHub section is visible and updated but does not remain fixed, pin correctly, or transition during scrolling.