An optional vendor script in the TermsFeed AutoTerms Cookie Consent kit runs once the visitor accepts its category, or, before the visitor answers, on page load when page_load_consent_levels lists it. The plugin prints each JavaScript vendor script in the footer of your WordPress website as <script type="text/plain" data-cookie-consent="...">, which the browser does not run. TermsFeed Free Cookie Consent 4.2.0 runs a strictly-necessary script at once.

Open the page source with Ctrl+U (Cmd+Option+U on a Mac). Each vendor script sits between 2 HTML comments that carry its name in capitals followed by "Vendor Script", such as GOOGLE ANALYTICS Vendor Script. Compare it with the examples before and after consent in Cookie Banner Code on WordPress Pages.

Cause 1: The visitor has not accepted the vendor script category

An optional vendor script waits until the visitor accepts its category, so under the default GDPR preference it never runs for a visitor who declined or has not answered. The ePrivacy preference instead runs every category on page load by default, from the first page on. With the ePrivacy preference, the script stays blocked only for a visitor who turned its category off in the Preferences Center, or when a hand-edited page_load_consent_levels leaves its category out.

The Preferences Center shows the saved answer, or, for a visitor who has not answered, the categories that run on page load. The kit adds an "Update cookies preferences" link at the end of the page while "Insert link for users to open Preferences Center" is on. Click the link and find the category that the Type of the vendor script names. A category turned off, or a consent banner that still waits for an answer, points to this cause.

Close every private window, open a new one, and test with the "I agree" button. Read how the Cookie Consent script stores and releases each category in The 4 Cookie Categories in Free Cookie Consent.

Cause 2: The vendor script has no "Type"

A vendor script without a Type prints with an empty data-cookie-consent attribute, which does not match any category, so it never runs. The add form always asks for a Type, and the Vendor Scripts list flags any stored script that has none.

The Vendor Scripts tab flags the row in red with "No Type: this script never loads. Choose a Type, then click Save Changes." The Type column of the row holds a "- Select Type -" select, and in the page source the script carries data-cookie-consent="".

Give the stored script its category from the row itself.

  1. Choose the category in the "- Select Type -" select of that row.
  2. Click the "Save Changes" button.
  3. Clear the page cache, close every private window, and test in a new one.

Cause 3: The code is HTML with no script tag

The plugin adds only <script> code to your WordPress pages, because other HTML runs at once and does not wait for consent. The plugin drops a pasted <noscript> fallback or <img> tracking pixel, and drops code that has no <script> tag and starts with HTML. Plain JavaScript without a <script> tag is the exception: the plugin wraps it in one, and by default that script waits for consent like any other vendor script.

The row on the Vendor Scripts tab shows "No <script> tag: this code is not added to your website. Delete it and add the <script> code of the vendor." In the page source, the 2 comments with the script name hold nothing between them.

Replace the row with the <script> part of the code alone. Check what the plugin keeps and drops from pasted code in Block WordPress Scripts Until Consent.

  1. Click the "Delete" button in the row and confirm "Are you sure you want to delete this Vendor Script?".
  2. Copy only the <script> part of the code from the vendor, without its <noscript> or <img> fallback.
  3. Add it again with Name, Type, and Script, and click the "Add vendor script" button.
  4. Click the "Save Changes" button.
  5. Clear the page cache, close every private window, and test in a new one.

Cause 4: A script tag has no closing tag

The plugin does not print a <script> whose </script> closing tag is missing, so code cut off while you copied it never reaches the page. A copy from an email, a PDF, or a chat app that cuts off the last line leaves the closing tag out. The add form refuses such code with "A <script> tag in the Script code has no closing </script> tag, so that script would not be added to your website. Please paste the complete code of the vendor script."

A row whose code lacks a closing tag carries its own warning on the Vendor Scripts tab: "Incomplete <script> tag (e.g. no closing </script>): this code is not added to your website, or only in part. Delete it and add the complete code of the vendor." Compare the Code column with the code the vendor gives you, and look for the last </script>.

Paste the code again in full.

  1. Delete the row.
  2. Copy the complete code again from the vendor, from the first <script to the last </script>.
  3. Add it with the "Add vendor script" button and click the "Save Changes" button.
  4. Clear the page cache, close every private window, and test in a new one.

Vendor scripts print only while the Cookie Consent kit is on, so a kit that is off removes every vendor script from the page. The plugin never prints them unblocked as a fallback, so the tracking tools behind them send nothing for any visitor.

The Cookie Consent box on the Compliance Kits screen shows "Disabled", and the page source does not hold a comment ending in "Vendor Script".

Turn the kit on from the Compliance Kits screen. Follow the remaining checks for the consent banner in WordPress Cookie Banner Not Appearing.

  1. Click the "Enable" button in the Cookie Consent box.
  2. Clear the page cache.
  3. Close every private window, open a new one, and load your page. Confirm in the page source that the comments ending in "Vendor Script" are back.

Cause 6: The "Configuration Parameters" are invalid

With invalid Configuration Parameters, the plugin prints every vendor script but never starts the Cookie Consent script, so no vendor script runs for any visitor. The consent banner is missing too, because the same JSON starts it. The Customization tab shows the notice "The Configuration Parameters are not valid JSON, so changes made here are not applied. Please correct them on the Configuration Parameters tab."

The page source shows a script that never starts. The vendor scripts carry type="text/plain", and the script with the id termsfeed-autoterms-cookie-consent-script does not hold a cookieconsent.run call.

Correct the JSON on the Configuration Parameters tab, or rebuild it from the Customization settings. Follow the invalid JSON steps in WordPress Cookie Banner Not Appearing.

Cause 7: The vendor script waits for page load or uses document.write

The Cookie Consent script adds a released vendor script to the page after the HTML has loaded, so a DOMContentLoaded handler in it never runs. A load handler never runs after a click on the consent banner, and on later page loads it runs only if Cookie Consent releases the script before the page finishes loading. document.write replaces the whole page from inline code and does nothing from a src file.

The vendor code shows whether this is the cause. Read the Code column of the row on the Vendor Scripts tab, and look for DOMContentLoaded, a load handler, or document.write.

Replace the code with an asynchronous tag that runs without waiting for page load. Check the new tag against the rules in Block Scripts Until Consent With Free Cookie Consent.

  1. Ask the vendor for its asynchronous tag.
  2. Add the tag as a new vendor script with the same Name and Type, and delete the old row.
  3. Click the "Save Changes" button, clear the page cache, close every private window, and test in a new one.

Cause 8: The Vendor Scripts list was never saved

The "Add vendor script" button adds the script to the list on screen only, and the "Save Changes" button stores the list. Leaving the tab with the "Back to Compliance Kits" link or another menu item before you save drops the new row. The "Save Changes" button adds a script you filled in and forgot to add.

Reload the Vendor Scripts tab. The row is gone, and the page source of the website does not hold a comment with the script name.

Add the script again and store the list before you leave the tab. On a save by an account without unfiltered_html, the plugin keeps the old list and shows an error, so fix that error with Code or HTML Not Saving in WordPress.

  1. Add the script again.
  2. Click the "Save Changes" button before you leave the tab.
  3. Reload the tab and confirm that the row is still in the list.
  4. Clear the page cache, close every private window, and test in a new one.

The checks assume the default GDPR preference with page_load_consent_levels at ["strictly-necessary"].

A working vendor script stays text/plain before the answer and sends its first request right after a click on the "I agree" button. Filter the Network tab by the tool host, such as googletagmanager.com for Google Analytics 4. A strictly-necessary script, and by default every vendor script under the ePrivacy preference, sends its request on page load instead, before you answer. Save your change and clear the page cache first.

  1. Close every private window, open a new one, open DevTools with F12, and load your page.
  2. Search the page source for the script name in capitals and confirm type="text/plain" with the right data-cookie-consent category.
  3. Open the Network tab, type the tool host in the filter, and confirm that no request appears before you answer.
  4. Click the "I agree" button and confirm that the first request to the tool appears, such as gtag/js, with status 200.
  5. Open the Console tab and confirm that no red line names the tool.