How to Find a LifterLMS Conflict Without Breaking Your Live Site

Something on your LifterLMS site stopped working. The quiz will not load, the checkout button spins forever, the course builder shows a blank screen, or lessons look broken after a theme update. Very often the cause is not LifterLMS itself but a LifterLMS conflict: another plugin, the theme, or a snippet of custom code interfering with it.

The classic advice is "deactivate all your plugins and switch to a default theme". On a live site with paying students, that advice is how you turn one bug into an outage. This guide gives you a method that finds the culprit while students keep learning: where to test, what to collect first, the order to disable things in, and how to fix the conflict once you have found it.

It is written for site owners and the developers who support them. You need administrator access, and ideally a staging copy of the site.

Signs that you are dealing with a conflict

Conflicts tend to show up in a few recognisable ways. If yours matches one of these, the method below is worth following:

• It started after a change. A plugin or theme update, a new plugin, a new snippet in functions.php, or a host change such as a new caching layer.
• Something JavaScript-driven fails. The quiz, the course builder, the checkout, lesson time tracking and the certificate editor all depend on scripts. One JavaScript error from another plugin can stop all of them on that page.
• It only happens on some pages or for some users. For example, it works for administrators but not for students, or only on pages built with a page builder.
• Layout breaks on LifterLMS pages only. The theme's CSS, or an outdated template override in the theme, is the usual reason.

If the problem is a 404 on courses or lessons, a caching issue, or emails not arriving, start with the dedicated guides first: fixing course and lesson 404 errors and LifterLMS caching conflicts. Those causes are common enough to rule out before a full conflict test.

Collect evidence before you change anything

Five minutes of evidence gathering saves hours of guessing, and some of it is impossible to get once you start deactivating plugins.

1. Write down how to reproduce it

Note the exact page, the user role, the browser, and the steps. "Log in as a student enrolled in Course A, open Lesson 3, click Take Quiz, nothing happens" is a test you can repeat after each change. "Quizzes are broken" is not.

2. Check the browser console

Open the browser's developer tools on the failing page and look at the Console tab while you repeat the steps. A red error naming a file in another plugin's folder is the strongest clue you will get. Also check the Network tab for failed requests to admin-ajax.php: a 403 there often means a security plugin or firewall is blocking the request, not a code conflict.

3. Copy the LifterLMS System Report

Go to LifterLMS > Status. The System Report tab lists your WordPress, PHP and LifterLMS versions, the active theme, every active plugin with its version, and a Template Overrides section. Click Copy for Support and paste the result into a text file. Now you have a record of the site exactly as it was when the problem appeared.

The Template Overrides section deserves a careful look. For each LifterLMS template your theme overrides, it shows the core template version and the version of the copy in your theme. A theme override that is several versions behind the core template is a frequent cause of broken layouts and missing features after a LifterLMS update.

4. Check the logs

The Logs tab on the same Status page shows log files that LifterLMS and its add-ons have written. For PHP errors, turn on WordPress debug logging on staging (shown below) and read wp-content/debug.log after reproducing the problem.

Where to test: staging first, troubleshooting mode second

There are two safe places to run a conflict test. Use the first whenever you can.

A staging copy of the site

Most managed WordPress hosts can create a staging copy in one click. On staging you can deactivate anything, switch themes and enable debugging without students noticing. Two LifterLMS-specific cautions apply:

• Recurring payments. LifterLMS detects when a site has been copied to a new URL and treats it as a staging site, so automatic recurring charges are not processed from the copy. Do not override that on staging. Our article on staging sites and recurring payments explains how it works.
• Emails. A staging copy still contains real student email addresses. Disable outgoing email on staging, or route it to a mail-catching service, before you trigger any engagements.

Turn on debug logging in the staging site's wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Health Check troubleshooting mode on the live site

When the problem only happens on production, for example because it depends on live payment gateway settings or a host-level cache, use the free Health Check & Troubleshooting plugin from WordPress.org. Its troubleshooting mode gives you a session where all plugins are disabled and a default theme is used, and it applies only to your own logged-in session until you disable it or log out. Visitors and students keep seeing the normal site.

In troubleshooting mode you re-enable plugins one by one from the admin bar. Re-enable LifterLMS first, confirm the problem has gone, then add the others back.

One limit: troubleshooting mode only changes what your session loads. To test a problem that only students see, create a test student account and use troubleshooting mode while logged in as that student in a private browser window.

A safe order for isolating the conflict

Whether you are on staging or in troubleshooting mode, work in this order. Repeat your reproduction steps after every change.

1. Confirm the baseline. With only LifterLMS (and its add-ons) active and a default theme such as Twenty Twenty-Five, the problem should be gone. If it is still there, it is not a conflict: it is a LifterLMS bug, a server issue, or a configuration problem, and you should take your notes to LifterLMS support or your developer.
2. Switch the theme back. If the problem returns with only your theme added, the theme or its template overrides are the cause.
3. Re-enable plugins in groups. With 30 plugins, testing one at a time is slow. Re-enable half. If the problem returns, the culprit is in that half: disable half of them again, and so on. Five or six rounds will find one plugin among 40.
4. Test custom code last. Code snippets plugins, must-use plugins in wp-content/mu-plugins and a child theme's functions.php are easy to forget. Health Check does not disable must-use plugins, so check them separately on staging.
5. Confirm the pair. Once you think you have found the culprit, test with LifterLMS, the default theme and just that one plugin. If the problem appears, you have a confirmed conflict.

On staging with WP-CLI, the same process is quicker from the command line. These are standard WordPress commands:

# Record what is active before you start
wp plugin list --status=active --field=name > active-plugins.txt

# Deactivate everything except LifterLMS
# (add your LifterLMS add-on slugs to the comma-separated list)
wp plugin deactivate --all --exclude=lifterlms

# Switch to a default theme
wp theme activate twentytwentyfive

# Bring a plugin back
wp plugin activate some-plugin-slug

Use the slugs from active-plugins.txt to keep your LifterLMS add-ons active, and to restore everything when you finish.

Common LifterLMS conflict patterns

After enough of these investigations, the same culprits come up again and again.

Symptom	Usual cause	Where to look
Quiz, builder or checkout does nothing on click	A JavaScript error from another plugin, or script optimisation that combines, defers or delays LifterLMS scripts	Browser console; the optimisation plugin's exclusion settings
AJAX requests return 403	A security plugin or web application firewall blocking admin-ajax.php or REST requests	Network tab; firewall logs
Students see stale progress or another state	Page caching of logged-in or LifterLMS pages	Cache exclusions for course, lesson, quiz, checkout and dashboard pages
Layout broken on course or lesson pages only	Outdated theme template overrides, or theme CSS	Template Overrides in the System Report
Student dashboard tabs return 404	Another plugin using the same endpoint slugs	Endpoint settings under LifterLMS > Settings > Accounts; flush permalinks
Fatal error after an update	A plugin calling a function or class that changed	The file and line in debug.log

LifterLMS already ships compatibility code for some well-known cases. The plugin contains a class whose job is to make it "play nicely" with other plugins, themes and hosts, for example around WooCommerce account endpoints and BuddyBoss. That is why updating every component, not just LifterLMS, is always the first fix to try.

Fixing the conflict once you have found it

Finding the culprit is only half the job. The options, roughly from least to most work:

1. Update both sides. Check whether the conflicting plugin or theme has a newer version. Many conflicts are fixed upstream once reported.
2. Change a setting rather than removing the plugin. Optimisation plugins nearly always offer a way to exclude scripts or pages. Exclude LifterLMS scripts from deferral and delay, and exclude LifterLMS pages from page caching.
3. Update the theme's template overrides. Compare each outdated override with the current core template and carry the theme's changes forward. Our guide to LifterLMS template overrides shows how to do this safely.
4. Report it to both developers. Send the reproduction steps, the console or log error and your System Report. A clear report is often fixed within a release or two.
5. Write a compatibility fix. When neither side will change, a small custom plugin can dequeue a script on LifterLMS pages, adjust a hook priority or filter conflicting output. Keep it in a plugin, not in the theme, so it survives theme changes.
6. Replace the plugin. If a plugin is abandoned and conflicts with a core part of your course site, replacing it is often cheaper than maintaining a workaround.

How to prevent the next conflict

• Update on staging first, then run a short smoke test: log in as a student, open a lesson, mark it complete, take a quiz, and run a test checkout with your gateway's test mode.
• Update one thing at a time on production, so that if something breaks you know which update caused it.
• Keep the plugin list short. Every plugin you remove is one less thing that can conflict. Remove plugins that duplicate LifterLMS features.
• Keep custom code in version control and in a site plugin, following the approach in how to customize LifterLMS without breaking updates.

Frequently asked questions

Will deactivating plugins delete my LifterLMS data?

No. Deactivating a plugin, including LifterLMS, does not remove courses, enrollments or progress. LifterLMS only removes its data on uninstall if you have deliberately configured it to. Deleting other plugins can remove their own settings, so deactivate rather than delete while testing.

Is Health Check troubleshooting mode safe on a live site?

It is designed for that. The plugin says troubleshooting mode affects only your own session until you disable it or log out. It is still sensible to test outside peak hours and to have a recent backup.

The problem disappears on staging. What now?

Then the difference between the two environments is your clue. Common candidates are server-level caching, a CDN or firewall that only fronts production, different PHP versions, and live payment gateway settings. Compare the System Reports from both sites side by side.

Should I contact LifterLMS support or the other plugin's developer?

Contact whoever's code produces the error. If the console or log names a file in the other plugin, start there. If the problem appears with only LifterLMS and a default theme active, it is a LifterLMS issue. Include your System Report either way.

What to do next

Set up a staging site if you do not have one, and run the isolation steps above before you change anything on production. In most cases you will have a confirmed culprit within an hour, and the fix is an update, an exclusion setting or an updated template override.

When the conflict sits between two components you rely on and neither vendor will change, you need a compatibility fix written and maintained by someone who knows LifterLMS internals. Our LifterLMS support service handles exactly this kind of investigation, and you can send us your System Report and reproduction steps to get started.