Gravity Forms Debug - WordPress Plugin

Guide to Troubleshooting Forms with Gravity Forms Debug

Gravity Forms Debug is not about showing off features. It is built for calmly investigating issues that are hard to catch on a live site: a theme conflict, a plugin conflict, broken form scripts, strange field behavior, a missing button in the admin panel, or an error that only appears on the public page. In this guide, we will look at when the add-on actually helps, how to prepare the site, how to use Conflict Tester, which logs to enable alongside it, and how to avoid leaving unnecessary diagnostic data behind after testing.

This material is intended for site owners, WordPress administrators, developers, and support specialists who need to quickly understand why a form behaves differently than it does in preview. We will not repeat the standard Gravity Forms product overview or discuss buying the product. The focus here is safe diagnostics on an already installed system.

The main idea is simple: Gravity Forms Debug is especially useful on a live site where you cannot bluntly disable the theme and all plugins for every visitor. But it is not a magic repair button. The add-on helps narrow down the cause, while the actual fix still depends on what you find: the theme, an optimization plugin, a page builder, a payment add-on, code in a child theme, or a server-side setting.

What the Add-On Solves and Where It Helps

According to the official Gravity Forms documentation and support discussions, the main job of the Debug Add-On is to provide Conflict Tester. It lets you test for theme and plugin conflicts in a way that applies only to the current user who enabled diagnostic mode. Everyone else continues to see the site normally. That is a major difference from a manual test, where the administrator temporarily switches to a default theme and globally disables third-party plugins.

This approach is useful when the issue appears only in the site's real environment. For example, the form calculates totals correctly in preview mode, but on the live page with the active theme the calculation does not update. Or the merge tags button breaks in the form builder, entry export stops working, reCAPTCHA disappears on mobile, or the button for adding a payment add-on feed never appears. In cases like these, you first need to prove that the problem is not in the form itself, but in the surrounding environment.

Gravity Forms Debug does not replace Gravity Forms system logs, the browser console, or System Status. It is better thought of as answering one question: "Who is preventing the form from working in this environment?" Logs answer a different question: "What exactly happened during submission, feed processing, a background task, or a notification?" A solid investigation usually combines both approaches.

If the issue appears only for one user, one role, or only in the admin panel, do not rush to turn everything on at once. First capture the symptoms, the page, the form, the user role, and the exact action that triggers the problem. The more precise your starting point, the fewer unnecessary switches you will make in Conflict Tester.

Typical Cases Where the Debug Add-On Makes Sense

This plugin is especially useful in scenarios where the error looks like a JavaScript, CSS, or server-environment conflict, but there is no obvious culprit. These situations include:

• The form works in Preview but breaks on the public page when used with a theme, page builder, or popup.
• Calculation fields, total, date picker, CAPTCHA, or conditional logic behave differently on the live page.
• Parts of the Gravity Forms admin UI stop opening, export fails, or parts of the interface disappear.
• After enabling optimization, minification, or deferred script loading, the form stops submitting.
• You need to test a conflict on a live site, but you cannot show visitors a default theme and disabled plugins.

In all of these cases, the add-on should not be the first and only step. Start with the usual basics: updates, the absence of obvious browser console errors, correct form embed, user permissions, and enabled Gravity Forms logs. Then use the Debug Add-On as a controlled isolation test.

Who This Diagnostic Method Is For and When It May Get in the Way

Gravity Forms Debug is best suited for site administrators, agencies, and developers who maintain forms on a live WordPress site. It saves time when there is no separate staging copy or when the bug appears only in the real environment: with the current theme, the current cache, the exact set of add-ons, and specific user roles.

That said, the add-on does not make the investigation completely risk-free from an organizational perspective. Technically, Conflict Tester isolates changes to the user who enabled the mode, but the administrator can still make mistakes: testing the wrong page, enabling the wrong plugin in the diagnostic session, forgetting to save the active elements, or failing to disable the mode after testing. That is why you need a short plan before you start.

This tool is a good fit if you:

• Understand which form, page, or feed is causing the problem.
• Can log into the admin panel with a user who has sufficient permissions.
• Have access to a backup, or at least to the hosting environment in case you need to roll back a conflicting plugin.
• Are prepared to test one change at a time and record the results.
• Are not trying to fix the form in front of the client without first documenting the original state.

The plugin may be unnecessary if the problem is already obvious. For example, if the logs clearly show an external API error, email is failing because of SMTP, the server is blocking loopback requests, or System Status explicitly reports a problem with upload folder permissions. In those cases, you can leave Conflict Tester for later and fix the confirmed cause first.

Limitation for Multisite Installs

Gravity Forms support sources include an important caveat: for WordPress multisite, they often recommend running a manual conflict check instead of using the Debug Add-On. So on a network install, do not assume Conflict Tester will be available or behave the same way it does on a single site. Check the documentation for your specific Gravity Forms version and current environment.

Practical rule: if the site is critical for sales or lead generation, reproduce the issue on a staging copy first. The Debug Add-On is useful on a live site, but staging is still the right place for destructive experiments, bulk updates, and testing questionable fixes.

What to Check Before Installation

Before installing the diagnostic add-on, do not rush. If you enable Conflict Tester without baseline information, the result will be hard to interpret. First, prepare a short map of the problem: which form is breaking, where it is embedded, how the public page differs from preview, which add-ons are involved, and whether payments, user registration, webhooks, notifications, or background tasks are part of the workflow.

Start with a basic checklist. It does not replace diagnostics, but it helps you avoid wasting time on obvious causes:

• Open the problematic form in Preview and check whether the error repeats without the theme and page builder.
• Open the page in a browser with the console enabled and note any JavaScript errors.
• Check whether the same form is embedded multiple times on the same page, including tabs, modals, sliders, and repeated blocks.
• Check whether caching, minification, deferred script loading, or JavaScript file merging is enabled.
• Open Forms - System Status and review the environment, active theme, active plugins, upload folder permissions, and log availability.
• Make sure the user has permission to access Gravity Forms settings, System Status, and logs, especially if the project uses a role management plugin.

Not every item will apply to every bug. For example, if a feed is not being sent to a third-party service, it matters more to enable core logging and the corresponding add-on log. If the page layout or calculations break on the front end, it matters more to check the theme, builder, cache, and front-end scripts.

Minimum Access You Need

To work normally with the Debug Add-On, you need access to the WordPress admin panel, the plugins page, the Gravity Forms menu, and the problematic page. Hosting or file manager access is helpful, but in a typical scenario Conflict Tester does not require manual file edits. Hosting access is a fallback: if the site is already unstable, the administrator should know how to disable a problematic plugin outside the admin panel.

If you are working on a client site, agree on a diagnostic window in advance. Even if visitors will not see the theme switches and plugin deactivations in your session, you may still submit test entries, create records, trigger feeds, touch notifications, and test payment flows. That already affects data.

What to Record Before the First Test

Before enabling diagnostic mode, it helps to create a small testing log. A text file or note is enough:

1. The page URL with the form and the form ID.
2. The exact action after which the failure appears.
3. The expected result and the actual result.
4. The currently active theme and any plugins clearly tied to the page.
5. Enabled script optimizers, cache, and CDN, if they are in use.
6. The test entry number, if the bug is related to form submission.

This simple record is not about bureaucracy. Once you start turning plugins back on one by one in Conflict Tester, it becomes very easy to lose track of the moment when the error returned.

Installation and Initial Check

Gravity Forms Debug is installed like a standard WordPress add-on. The overall flow is the same as with other Gravity Forms add-ons: through the add-ons browser in the admin panel, by uploading a ZIP under Plugins - Add New - Upload Plugin, or by uploading files into the wp-content/plugins folder. The exact method depends on how updates and file access are handled on your site.

After installation, open the plugins list and activate the add-on. Then look for the diagnostic section in the Gravity Forms menu. In older articles and practical walkthroughs, the path is described as Forms - Debug. If you do not see that menu item, do not immediately assume the add-on is broken. Check the current user's permissions, the status of the main Gravity Forms plugin, compatibility with your installation type, and any restrictions introduced by a role management panel.

The initial check should be brief:

• Open the Debug page and make sure you can see the Conflict Tester block.
• Do not enable the mode immediately if you have not documented the original symptoms.
• Check whether a link for disabling the mode is available nearby, if the interface shows one.
• Open the problematic page in a separate tab so you can quickly rerun the test.
• If you plan to test form submission, prepare safe test data.

Do not start diagnostics by mass-disabling everything in the standard Plugins section. If the goal is to test the issue without affecting visitors, make all switches inside Conflict Tester, not in the global plugins list.

If the Debug Menu Item Does Not Appear

Check four things. First, confirm that the main Gravity Forms plugin is active. Second, confirm that the add-on itself is activated. Third, check whether the user role restricts access to Gravity Forms system capabilities. Fourth, check whether your installation type is one for which the documentation or support recommends a manual conflict test.

If the Gravity Forms interface itself is acting strangely, try the official No Conflict Mode for the admin panel first. It applies specifically to Gravity Forms admin pages and helps when third-party scripts and styles interfere with the form editor. But it is important to understand the limitation: this mode does not fix the public side of the site where a visitor submits the form.

Conflict Tester: How to Isolate the Theme, Plugins, and Page Builder

Conflict Tester is the core of Gravity Forms Debug. Its purpose is to create a diagnostic environment for the current administrator where the theme is replaced with a default one and plugins are disabled or enabled based on your choices. Visitors continue to see the normal site. That is exactly why the add-on is often recommended in support discussions when a manual check on a live site is too risky.

Once the mode is enabled, do not rush to turn all plugins back on. The logic works in the opposite direction: first reproduce the issue in the cleanest environment possible. If the problem disappears, that means it is being caused by the theme, a third-party plugin, a combination of plugins, script optimization, or the way the form is embedded. If the problem remains even in clean mode, the cause may be in the form configuration itself, an official add-on, the server environment, the database, permissions, an external service, or a specific component version.

Basic Sequence

The most reliable approach is to move from a clean environment back to the real one. The order can look like this:

1. Enable Conflict Tester on the Forms - Debug page.
2. Reproduce the issue with only Gravity Forms and the Debug Add-On active, if the mode interface allows it.
3. If the form now works, keep the default theme active and start restoring plugins one by one.
4. After each change, save the selected set and repeat the exact same test.
5. When the error returns, note the last enabled element and test it separately.
6. If the issue appears only when two elements are combined, test each one individually and then together.

Do not change the theme, cache, builder, and payment add-on at the same time. A test like that proves nothing. Good diagnostics are boring: one change, one retest, one recorded result.

How to Test the Theme

The theme often affects Gravity Forms through JavaScript, its own jQuery handling, field styles, modal windows, tab handlers, lazy loading, input masks, and rewritten templates. If the issue disappears on a default theme, do not rush into code changes. First check for theme and child theme updates, disable questionable theme optimization settings, create a clean page with a standard Gravity Forms block instead of a page builder, and rerun the test.

If the form works on a clean page but breaks inside a builder or modal, the problem may not be in Gravity Forms Debug or even in the core Gravity Forms plugin. Often the form script is not initialized after a hidden block becomes visible, the same HTML ID appears twice, or an optimizer changes the order in which files are loaded.

Testing on a Clean Page

Create a temporary private page, insert the same form there using a standard Gravity Forms block or a normal shortcode, and do not add builder sections, popups, tabs, sliders, or custom scripts to the page. If the issue disappears there, the Debug Add-On has already given you an important conclusion: the form itself and the base scripts work, and the error is tied to the rendering method or the environment of that specific page.

Testing the Theme Without Editing Files

If the issue disappeared on the default theme, do not edit the current theme files right away. First disable theme settings that affect JavaScript and forms: built-in optimization, field animations, lazy loading, global modal handlers, and custom input masks. After each change, restore the current theme and repeat one short scenario. That way, you can separate a configuration conflict from a theme code conflict.

How to Test Plugins

Third-party plugins can be restored in groups only during the first rough pass if there are too many of them. For example, you can enable five related plugins, rerun the test, and once the error returns, go through that group one by one. But for the final conclusion, you need a precise culprit or a precise combination. A note saying "the problem is in the plugins" is not helpful for either a developer or support.

Check optimizers, caching, security plugins, page builders, popup plugins, payment add-ons, and add-ons that modify form fields separately. These are the components most likely to interfere with script loading, request submission, CAPTCHA display, calculations, and feed processing.

Order for Restoring Plugins

Start with the components without which the form cannot even reproduce the relevant scenario: the official payment add-on, a registration add-on, webhooks, SMTP, or an integration plugin. Then restore the plugins that affect the page itself: the builder, popup, cache, optimizer, security, and analytics. Turn on unrelated plugins last. This order gets you to the cause much faster than alphabetically walking through the entire list.

How to Capture a Two-Way Conflict

Sometimes one plugin does not break the form, a second plugin does not break it either, but together they change the script load order or duplicate an event handler. In your testing log, record not only the last enabled component, but also the smallest combination that reproduces the issue. A note like "the error appears when A + B are both active, but does not appear with A alone or B alone" is much more useful to a developer than a long list of every active extension.

Setting Up Logs and System Status Alongside Debug

Gravity Forms Debug isolates the environment, but logs and System Status help you understand what exactly is happening inside Gravity Forms. In the official documentation, logging is enabled through Forms - Settings, after which the Logging section becomes available. There you can enable logs for Gravity Forms core and add-ons. If a log is empty, the view link may not appear, so after enabling logging you need to repeat the test action.

You should not leave logs enabled indefinitely. They can contain personal data, submission details, responses from external services, and technical information about the site. Gravity Forms applies protective measures to log files, but the documentation itself emphasizes that logging should be disabled after the investigation and the files should be deleted when they are no longer needed.

Which Logs to Enable First

Do not enable every log without a reason. For a typical investigation, it is enough to choose logs based on the type of problem:

• If form submission is failing, enable the Gravity Forms core log and repeat the submission.
• If an integration is not firing, enable the corresponding add-on log and check the feed.
• If background tasks are involved, review background processing in System Status and check the core or add-on logs.
• If the problem exists only in the admin panel, check No Conflict Mode and the browser console.
• If the issue affects export, file uploads, or the system report, check folder permissions, database tables, and active plugins.

A log should answer a specific question. For example: "Did the feed run?", "Why did the external service reject the data?", "Is there a background processor error?", or "Was an entry created after the test submission?" Without a clear question, a log quickly turns into noise.

System Status as an Environment Map

System Status is useful before opening a support ticket and before running a deeper investigation. It shows the Gravity Forms version, active add-ons, database status, WordPress settings, theme, plugins, PHP, web server, upload folder permissions, and log information. If the user cannot access System Status, the reason may be related to the Gravity Forms version or the role capabilities.

For Gravity Forms Debug diagnostics, four areas matter most: the active theme, active plugins, No-Conflict Mode, and Log Files. They help you connect the Conflict Tester result to the real environment. If the error disappears in clean mode, a System Status snapshot helps you decide which elements should be reintroduced first.

What You Should Not Hide from Support

When contacting support, do not send a stream of random guesses. Send a short report instead: the form, the page, reproduction steps, the result in preview, the result on the public page, what Conflict Tester showed, which plugins brought the issue back, which logs were enabled, and what was found. That speeds up the response and reduces the chance that you will be asked to repeat the same process from scratch.

Mini Report After Testing

A good report fits into a few lines: "Form ID 12 on the request page works in preview but freezes on the public page after selecting a field. In Conflict Tester, it works on the default theme without third-party plugins. The issue returns when the script optimizer with deferred loading is enabled. After excluding Gravity Forms files from deferred loading, the test submission, entry creation, and notification all work." A report like this immediately shows the source, the verification process, and the temporary fix.

Practical Scenario: The Form Calculates Total in Preview but Breaks on the Page

Let us look at a concrete example. The site has an event registration form with a custom product field and a total. In Preview, the amount updates immediately after the user selects options, but on the public page the total never changes. In Gravity Forms support discussions, symptoms like this are often tied to a JavaScript error, a theme conflict, an optimizer, or the way the form is embedded.

Goal

You need to find out what is preventing the Gravity Forms front-end scripts from updating the calculation, without disabling the site for visitors. The result of the investigation should not be just "the form does not work," but a concrete conclusion: the theme is responsible, a specific plugin is responsible, script optimization is responsible, the form is duplicated, or the form configuration itself is responsible.

Preparation

Before testing, record the page URL, form ID, selected options, expected amount, and actual behavior. Open the browser console and check for JavaScript errors. Verify that the same form is not repeated inside a modal, tab, or hidden block. If caching or minification is enabled, note which modules are active.

Testing Steps

1. Open the problematic form in Preview and confirm that the total updates.
2. Enable Conflict Tester through Forms - Debug.
3. Open the public page in the same admin session and repeat the option selection.
4. If the total starts working, begin restoring plugins: first the page builder, then cache, then form-related add-ons.
5. After each change, click save in Conflict Tester and repeat the exact same test.
6. When the total stops updating again, disable the last item and repeat the test to confirm.
7. If an individual plugin does not break the form but does break it when paired with an optimizer, test exclusions for Gravity Forms scripts from minification and deferred loading.

Checking the Result

The correct result is not just a working total. You need a reproducible chain: "the clean environment works," "after enabling plugin X it still works," "after enabling optimization Y the error returns," and "after excluding the form scripts the error disappears." Only that kind of chain lets you make safe changes on a real site.

Do not fix the conflict by editing Gravity Forms files. If the source is the theme or an optimizer, fix the settings of the conflicting component, the child theme, or the optimization exclusions. Editing the plugin core will be overwritten by updates and may create new issues.

The Cache and Hidden Block Nuance

If the form is placed inside a tab, accordion, slider, or modal window, the conflict may be related not to the calculation itself, but to the moment when scripts are initialized. In that case, Conflict Tester will only show that everything works on a clean page. From there, you need to check the embed method: use a standard WordPress block, create a separate test page without a builder, use a unique copy of the form for each location on the page, and make sure scripts are triggered correctly after the hidden block is opened.

How to Read the Result and Return the Site to Normal

After the test, it is important not only to identify the conflict, but also to exit diagnostic mode cleanly. In Conflict Tester, restore the enabled elements to the correct state, save the result, and disable the mode through the interface or the provided disable link. Then check the public page in a normal browser window and again in a private window where you are not logged in.

If you enabled Gravity Forms logging, disable it through Forms - Settings and delete the logs when they are no longer needed. Do not keep them around "just in case": the files may contain personal data and technical information. If the logs are needed for a ticket, download only the relevant portion and remove the rest after the investigation is complete.

Once you have identified the conflict, choose the fix based on the type of cause:

• Theme: update the theme, check the child theme, remove duplicate jQuery loading, and review custom scripts.
• Optimization: exclude Gravity Forms scripts from merging, minification, or deferred loading, then clear the cache.
• Builder: create a clean page with a standard form block and check the modal or tab settings.
• Third-party add-on: update the component, review feed settings, and contact the developer with the test results.
• Server: check loopback requests, cron, folder permissions, Admin Ajax URL availability, and security restrictions.

Do not push a diagnostic conclusion into production without a verification check. After changing settings, clear the cache, submit a test entry, and check the entry, notification, feed, and public-facing result. If the form is connected to payments, use a safe test mode in the payment tool rather than a real transaction.

Diagnostic Map: Symptoms, Causes, and Fast Checks

What follows is not a universal list of every Gravity Forms error. It is a practical map for cases where the Debug Add-On is especially useful. It helps you decide what to check first and when to move from Conflict Tester to logs, System Status, or WordPress developer tools.

Common Symptoms When Troubleshooting Gravity Forms

Symptom	Possible Cause	What to Check	How to Fix It Carefully
The form works in Preview, but not on the page	Theme, page builder, cache, JavaScript error, or hidden block	Conflict Tester, browser console, clean page with a standard embed	Exclude form scripts from optimization, change the embed method, update the theme or plugin
Total or calculation does not update	The form script did not load or was modified by an optimizer	Preview, public page, enabling the optimizer in Conflict Tester	Disable the problematic minification mode, restore script load order, clear the cache
Part of the form editor does not open	Third-party scripts in the Gravity Forms admin area	No Conflict Mode, browser console, list of active admin plugins	Enable No Conflict Mode as a temporary workaround and identify the source of the conflicting script
A feed does not run or the wrong feed runs	Conditional logic, field mapping, spam status, external service, or background tasks	Add-on logs, test submission entry, feed conditions, System Status	Fix the conditions, fields, service connection, or background processing based on the logs
The form keeps submitting forever or hangs	The same form is embedded multiple times, a JavaScript conflict, or an AJAX issue	Number of embeds on the page, console, GF_DEBUG for the AJAX iframe if needed	Use separate copies of the form or a single embed, and eliminate the script conflict

When It Is Better to Roll Back a Change

Roll back the last change if it made the problem broader: the form stops submitting entirely, PHP errors appear, fields disappear, payments stop working, or unauthenticated users start having issues. Diagnostics should not create more damage than the original failure. If the result is unstable, restore the last working combination, clear the cache, and repeat the test on a staging copy.

Why the Debug Add-On Sometimes Does Not Find the Culprit

Conflict Tester checks the theme and plugins within WordPress, but it does not always isolate network rules, server-side cache, CDN behavior, external APIs, hosting restrictions, mu-plugins, drop-ins, or web server settings. The official Gravity Forms documentation specifically notes that must-use and drop-in plugins may not be disabled in a standard test. So a negative Conflict Tester result does not mean there are no conflicts at all. It only means the cause did not appear within the set you tested.

Safe Improvements Without Editing Core Files

In most cases, Gravity Forms Debug does not require snippets. But there are a few safe techniques that make diagnostics cleaner. They do not fix the conflict by themselves, but they reduce the risk of data exposure and confusion.

Hide the Persistent Logging Notice Only Deliberately

Gravity Forms shows a visible warning when logging is enabled. The documentation allows you to hide this warning with a constant, but that should not become a way to forget logging is on. Use this option only in a controlled environment where the team understands that logging is enabled temporarily.

define( 'GF_LOGGING_DISABLE_NOTICE', true );

You should add the constant to wp-config.php, not to Gravity Forms files. Once the investigation is complete, disable logging and remove the constant if it is no longer needed. The check is simple: open Forms - Settings - Logging and make sure logging was not left enabled without a purpose.

GF_DEBUG for AJAX Scenarios

If the issue is related to AJAX form submission, the Gravity Forms documentation describes the GF_DEBUG constant, which helps you view the contents of the AJAX iframe. This is a technical developer tool, not a setting you should keep enabled for normal site operation.

define( 'GF_DEBUG', true );

Enable it only for a targeted check and remove it after the test. If you do not know exactly what you want to see in the AJAX iframe, it is better to start by enabling the regular Gravity Forms logs and checking the browser console.

gform.console for Custom Code

If the issue is caused by your own JavaScript, it is often better to use the built-in gform.console wrapper described in the Gravity Forms documentation instead of scattering random console.log calls across the project. It helps you write diagnostic messages in a way that fits the Gravity Forms ecosystem. But add those messages only to your own code, child theme, or a separate safe snippet. Do not edit plugin files.

Any temporary improvement should have a clear rollback path: where it was enabled, where to disable it, who is responsible for removing it after the investigation, and which test confirms that the site has returned to a normal state.

Where the Debug Add-On Falls Short Compared to Other Tools

Gravity Forms Debug is strong when you need to check conflicts around Gravity Forms. But if the task is broader, such as finding a slow SQL query, understanding a PHP error stack, tracing an HTTP request, inspecting REST API behavior, looking at blocks, or tracking arbitrary WordPress hooks, the add-on alone is not enough. That is where specialized tools are more useful.

You can break the approach down like this:

• Gravity Forms Debug - when you need to check whether a theme or plugin is interfering with a specific form.
• Gravity Forms logs - when you need to understand submission handling, feeds, notifications, or background tasks.
• System Status - when you need to see the environment, active components, and technical conditions.
• Query Monitor - when you need a broad view of PHP, queries, hooks, HTTP API, REST API, and the error source.
• WP Debugging or manual WordPress constants - when you need to enable the system debug log for development.

Do not keep the full diagnostic toolkit active all the time. These tools are helpful during an investigation, but they can add overhead, expose unnecessary information to administrators, or store technical data that is no longer needed after the fix.

When Gravity Forms Debug Is the Right Choice

Gravity Forms Debug is worth using when the issue looks like an environment conflict and you need to test it without globally disabling the theme and plugins for visitors. The add-on is especially strong when the form works in preview but breaks on the public page, and when the likely suspects are a page builder, script optimization, the theme, or a third-party add-on.

Before you begin, save the original symptoms, enable diagnostic mode only for a specific check, restore elements one by one, use Gravity Forms logs for feeds and background tasks, and once you are done, disable logging and delete unnecessary files. That approach turns the Debug Add-On from a "button of hope" into a proper working support tool.

If you already have a backup, understand the symptom, and want to test a conflict on your site, you can download Gravity Forms Debug, install the add-on, and run your first test using the steps in this guide. The key is not to skip the final verification: the public page, a test submission, the entry, the notification, the feed, and the diagnostic logs being turned off.