Cookies Policy Notification Bar - Joomla Extension

Guide to Configuring and Testing Cookies Policy Notification Bar for Joomla

Cookies Policy Notification Bar is more than just a strip of text about cookies. When configured properly, the extension becomes a consent control center: it gives visitors a clear choice, separates cookies into categories, holds back third-party scripts until consent is granted, helps connect the banner to Google Consent Mode, and gives the administrator a way to verify that the setup actually works on the public-facing site.

This guide is written for a Joomla site owner or administrator who already understands why cookie consent matters, but does not want to stop at installing a "checkbox compliance" banner. Below, we cover preparation, installation, initial setup, cookie categories, script blocking, the cookie table for the policy page, Consent Mode, result verification, troubleshooting common issues, and similar solutions.

This material is not a substitute for legal advice. Its purpose is to help you configure the extension technically so the site's behavior is predictable: necessary cookies do not break login, analytics do not start before consent, visitors can change their decision, and the administrator knows where to look if the banner does not appear or keeps showing up again and again.

The main practical idea is simple: a good cookie banner in Joomla should not just look polished, it should also control which scripts actually make it into the page before and after the user's choice. That is why most of this guide focuses not on button colors, but on the relationship between category, script, consent, and verification.

What Problem the Extension Solves on a Joomla Site

On a typical Joomla site, cookies come from several different places. Some are created by the CMS itself, for example for the user session or the "Remember Me" feature. Others come from analytics, ad pixels, video players, live chat, maps, forms, marketing tools, and third-party widgets. Joomla documentation explicitly notes that extensions may create their own cookies, and that sites can notify visitors about cookie use in different ways - through a policy, terms, a module, or a dedicated solution.

Cookies Policy Notification Bar is useful where a simple footer notice is no longer enough. If the site uses Google Analytics, Google Tag Manager, Google Ads, Facebook Pixel, Hotjar, YouTube videos, Vimeo videos, or similar tools, the administrator needs more than a way to "inform" visitors - they need control over loading behavior. According to Web357 documentation, the extension can block JavaScript code from those services until the user accepts the required cookie category.

The extension operates on several levels:

• Notification - the visitor sees text, buttons, a policy link, and can accept, decline, or open additional settings.
• Categories - the administrator groups cookies into categories such as "Necessary," "Analytics," "Marketing," and "Preferences," or creates custom categories.
• Script blocking - analytics, advertising, video, or chat code is tied to a category and does not appear in the source HTML until consent is given.
• Repeat choice - the user can return to the settings through an icon, link, shortcode, or cookie table.
• Consent logs - the extension can save accepted and declined logs, and the IP address does not have to be stored if that creates an unnecessary personal data trail in your jurisdiction.
• Consent Mode integration - for Google services, you can set a default denied state and update the status after the user's decision.

That leads to a practical selection criterion. If the site does not use analytics, ad pixels, external videos, or other non-essential cookies, a cookie policy and a clean notification may be enough. But if the site collects statistics, fires marketing tags, or embeds third-party widgets, the extension becomes valuable as a technical loading control layer, not just a decorative banner.

A quick question before installation: which scripts and embeds create cookies before consent? If you do not know the answer, audit the site with browser tools first, then configure categories. Otherwise, the banner may look correct while failing to solve the core problem.

Who Cookies Policy Notification Bar Is For, and When Another Approach May Be Better

The extension is a strong fit for Joomla sites where the administrator wants to manage cookies inside the CMS without connecting an external SaaS widget for every domain. The product page and JED listing show that the solution is built specifically for Joomla, supports current CMS branches, uses the Joomla Update System, and has evolved as a system plugin with additional capabilities. That makes it convenient for agencies, corporate sites, directories, media projects, small stores, and multilingual websites where it is important to keep the settings close to the rest of the site's configuration.

When it is a good choice

Cookies Policy Notification Bar is worth considering if you need to:

• Display a cookie notification bar or modal settings on a Joomla site without a separate cloud-based control panel.
• Split cookies into categories and let users change their choice.
• Block analytics, advertising, video, or chat scripts until consent is granted.
• Add a cookies info table to the policy page and give users a way to revisit their decision.
• Connect the setup to Google Consent Mode v2 and verify default and update states.
• Control output by pages, languages, positions, colors, and button behavior.
• Keep consent logs, while optionally disabling IP address storage.

The extension is especially useful when the site already relies on multiple third-party services. If all you need is a basic notice, its feature set may feel excessive. But for a setup that combines analytics, video, a cookie policy, and multilingual support, it covers far more real-world needs than a lightweight one-button module.

When the product may not be the right fit

The extension should not be treated as an automatic legal shield. It will not write a compliant cookie policy for you, classify every external service without administrator input, or prove by itself that the site meets the legal requirements of a specific country. The documentation includes features and settings for consent, logs, categories, blocking, and Consent Mode, but responsibility for the wording, legal basis, service inventory, and behavioral verification still belongs to the site owner.

If you need a fully automated scanner, policy generator, centralized management for dozens of domains, a separate consent database outside Joomla, or a deeper enterprise CMP infrastructure, it makes sense to compare this product with larger platforms. But if you want to manage cookies directly in Joomla and are ready to assign scripts to categories carefully, Cookies Policy Notification Bar gives you a flexible enough foundation.

What to understand before buying or installing

According to JED, the product is a paid download, and the Web357 product page lists subscription plans with updates and support. This article does not include pricing as a working configuration detail, because pricing can change. Technically, something else matters more: you can continue using the extension after installation, but updates and support depend on Web357 subscription terms. On a production site with privacy requirements, that is not a minor detail. A cookie consent extension needs ongoing fixes when Joomla, browsers, Consent Mode, or third-party script behavior changes.

What to Check Before Installation

Before you head straight to System - Extensions and upload the ZIP, build a minimal map of the site. Which pages use third-party scripts? Which modules output embeds? Is there login, a cart, forms, video, a map, comments, ad tags, or analytics? This takes less time than diagnosing later why cookies still appear.

Platform and dependencies

JED and the Web357 site list compatibility with Joomla 3, 4, 5, and 6, along with support for the Joomla Update System. If the site is older, check more than just the Joomla version. Review PHP, the template, optimization tools, caching plugins, and the state of Web357 Framework if the installed package requires it. The Web357 changelog mentions improvements and fixes related to the Framework and Cookie Manager parameters, so a missing framework plugin or an outdated version can lead to non-obvious symptoms.

For Joomla 4 and later, it also makes sense to consider Scheduled Tasks. Web357 documentation describes a task for deleting old Cookies Policy Notification Bar logs, and Joomla documentation explains that scheduled tasks are used for routine maintenance inside the CMS. If you plan to keep consent logs, decide in advance whether automatic cleanup should be enabled.

Privacy policy and text content

The extension can output a privacy policy link, a modal, and a cookie table, but the policy content itself must be prepared by the site owner. Before installation, it is best to have:

• A privacy policy or cookie policy page with a clear URL.
• A list of the third-party services actually used on the site.
• Short cookie descriptions for the table, if you plan to use the {cookiesinfo} shortcode.
• Separate wording for different languages, if the site is multilingual.

Web357 documentation shows that cookie descriptions can be translated through Joomla language overrides and tied to constants in the settings. For a multilingual site, that works better than duplicating ad hoc text across templates or modules.

Audit scripts before configuration

Open the site in a private browser window, then inspect cookies and network requests before clicking the banner. If analytics, advertising, or video provider cookies are already present before consent, you will need to configure the extension not as "bar only," but through block cookies functionality or {cpnb} wrappers. A practical pre-install checklist looks like this:

• Google Analytics or Google Tag Manager: where is the code inserted - via the template, a module, custom HTML, Tag Manager, or a separate extension?
• Video: which pages use YouTube, Vimeo, or AllVideos?
• Marketing: are Meta Pixel, LinkedIn Insight Tag, Hotjar, or live chat enabled?
• Cache: are System Cache, System - Page Cache, JCH Optimize, or CDN cache enabled?
• Template: are there JavaScript conflicts, legacy frameworks, or template options such as Helix3 Mootools Fix?

If you skip these checks, you can end up with false confidence: the button is there, the visitor clicks accept, but the script was already loading before consent. Or the reverse: the script is correctly blocked, but after consent it still does not appear because of cache or an AJAX conflict.

Installation and Initial Verification in Joomla

Web357's official installation instructions for the Joomla extension are straightforward: download the ZIP package, log in to the admin panel, open the extensions manager, and upload the package. For updates, Web357 recommends installing the new version over the old one without deleting the previous version, because removal may cause parameter loss. In modern Joomla, the interface path may be labeled a little differently, but the meaning is the same: the installation package is uploaded through the CMS's standard installer.

A safe installation sequence

1. Create a backup of the files and database. This is especially important if the site already uses cache, optimization tools, and custom scripts.
2. Install the extension package through Joomla's standard installer.
3. Verify that the system plugin is published and visible in the plugins list when you search for System - Web357 Cookies Policy Notification Bar.
4. If the package reports a missing Web357 Framework, install or update the framework the way Web357 recommends.
5. First enable a minimal banner without block cookies functionality, just to make sure it appears on the public site.
6. Then enable categories, scripts, shortcodes, Consent Mode, and logs one block at a time, checking the result after each step.

This order may feel slow, but it reduces the risk of getting several symptoms at once: the banner is not visible, cookies are not being blocked, the buttons do not close the modal, analytics does not update the consent status, and a custom module shows the shortcode as plain text.

Initial check after installation

After publishing the plugin, open the site in a private window or a separate browser profile. Do not test only inside your administrator session: the extension has behavior settings for logged-in users, and your regular browser may already store an earlier choice. A minimal check should confirm the following:

• The banner appears on the first page where it is supposed to appear.
• The accept, decline, cancel, or more info buttons respond without console errors.
• After accept, the banner does not reappear on every page.
• After clearing cookies or changing the cookie name, the banner appears again.
• If the modal manager is enabled, it opens and closes without leaving the overlay stuck.

The Web357 changelog includes fixes for modal buttons and the More Info modal, so if the modal behaves strangely, the first thing to check is the installed version and whether an update is available. Do not try to patch the overlay with your own CSS if the issue is already fixed in the extension version you should be using.

Basic Banner Setup: Text, Position, Buttons, and the Policy Link

After installation, do not start with button colors. Start with meaning: what exactly the banner says, where the link goes, which choices are available to the user, and whether the interface nudges people too strongly toward "accept all." Different countries and industries may have different requirements, so it is best to review the wording with legal counsel or whoever is responsible for privacy compliance.

Notification text and policy link

The notification should briefly explain that the site uses cookies not just "in general," but for understandable purposes: essential site operation, analytics, marketing, and external content. If you use Cookie Manager, do not turn the first screen into a wall of legal text. Give users a short statement, a policy link, and a path to the settings.

A practical text structure looks like this:

• One sentence explaining that the site uses cookies and similar technologies.
• A link to the privacy policy or cookie page.
• A consent button.
• A decline or cancel button, if your model requires one.
• A button or link that opens detailed settings.

If the site is multilingual, do not mix languages inside one message. For cookie descriptions and interface text, Web357 shows two approaches: plugin parameters and Joomla language overrides. Overrides are especially convenient for individual cookie descriptions because they let you manage translations through Joomla's standard mechanism instead of hunting for the same text across multiple modules.

Banner position and behavior

The JED description mentions multiple display positions, and the Web357 product page highlights control over appearance, colors, sizes, animation duration, button styling, custom CSS, and custom JavaScript. In practice, the right position depends on the template:

• A bottom bar works well for content-heavy sites and does not cover the main menu.
• A centered dialog is more noticeable, but needs especially careful testing on mobile screens.
• A corner block works for a softer notice, but may conflict with chat widgets and sticky buttons.
• A top position requires checking the sticky header, z-index, and spacing so the banner does not overlap navigation.

Do not leave "Always Display" enabled on a live site as a permanent mode. In the Web357 changelog, this feature is described as useful for debugging. In production, it will annoy visitors and make it harder to verify whether the consent state is actually being saved.

Buttons and visual fairness

Button styling is not just about aesthetics. If the accept button is bright and the decline button is nearly invisible, the user's choice starts to feel manipulated. Set contrast, focus states, hover states, and size so the buttons are clearly distinguishable on both desktop and mobile. In recent updates, Web357 explicitly highlights keyboard navigation, screen reader support, focus indicators, and WCAG 2.1 AA. That matters because a cookie banner is an interactive control and must be accessible from the keyboard.

Mini accessibility check: open the page without using a mouse and navigate with Tab, Enter, and Space. Focus should be visible, the element order should make sense, and accept, decline, and settings should all work from the keyboard.

Cookie Categories and Cookie Manager: How Not to Confuse the Visitor

Cookie Manager is one of the key parts of Cookies Policy Notification Bar. According to Web357 documentation, the administrator can create multiple categories, assign a unique ID without spaces or special characters, and define the name, description, default checked state, and status. These fields directly affect how the settings appear to the user in the modal window and which scripts will be loaded.

How to design categories

Do not create too many categories just for the sake of appearing more granular. The more complicated the list, the more likely the visitor is to misunderstand it and the administrator is to misassign scripts. For a typical site, four groups are usually enough:

• Necessary - cookies without which the site, login, cart, or basic navigation cannot work.
• Analytics - visitor measurement, event tracking, conversions, and site statistics.
• Marketing - ad pixels, remarketing, and ad personalization.
• Preferences - language, interface, and user preference cookies, if they are not strictly necessary.

If the site does not run ads, do not create an empty marketing category. If it only uses YouTube videos, it may make sense to create a separate category for video cookies or external media. Web357 documentation for video providers shows that such a category can be useful when you need to display a placeholder before consent and load the iframe only after the user makes a choice.

Default state and locked categories

Web357 documentation describes three checked-by-default models: a locked necessary category, an enabled but user-changeable category, and a disabled but user-changeable category. In practice, that means:

• The Necessary category can be locked if those cookies are truly required for the site to work.
• Analytics should not be locked on, because it is not a basic technical necessity for the visitor.
• Marketing is usually best left disabled by default if the site's policy requires explicit choice.
• Preferences depend on the use case: language selection may be important, while widget personalization may not be.

Do not label every cookie as "necessary" just because it matters to the business. If it is not required for the user to receive the page, it is not a technical necessity. That is not a limitation of the extension, but a matter of correct classification. This article cannot offer a universal legal framework, but technically the extension lets you make the choice honest: locked only where needed, changeable where user choice matters.

Descriptions, translations, and readable naming

The unique category ID is for the administrator and the code, while the category name and description are for the user. So the ID may be analytics-cookies, but the description should explain what actually happens, for example that cookies in this category help measure traffic and improve site structure. For multilingual sites, use Joomla language overrides anywhere the description should change by language.

Web357 documentation shows an example of a language constant for a cookie description. In a working project, you can define constants such as COOKIE_GANALYTICS_DESC, translate them into the required languages, and use the constant in the description field. That reduces the risk of updating the Russian version of the policy while leaving the English modal with outdated wording.

Script Blocking: The Extension's Core Mechanism

If Cookies Policy Notification Bar is installed only as a visual notification, you are using the smaller part of the product. Its most important technical feature is blocking scripts that create tracking cookies or contact third-party services before consent is granted. In Web357 documentation, this is described through Block Cookies Functionality, cookie categories, rows in "Block Cookies by blocking their Javascript Code," and wrapper tags {cpnb}.

The method that uses the script list in settings

Web357's official instructions recommend going to the plugin settings, opening Advanced Settings, enabling block cookies functionality, turning on the Cookie Manager modal and icon, and then creating the necessary groups in the categories section. After that, in the "Block Cookies by blocking their Javascript Code" block, you add rows with category, an admin-only name, JavaScript code, and status.

This approach is convenient for standard tracking snippets. For example, if Google Analytics code was previously added in custom template code, you can move it into the extension field and assign it to the analytics category. In that case, the script should not appear in the page source before consent to that category is granted. After accept or category consent, it loads according to the extension's logic.

What to verify after moving a script

• The code is no longer duplicated in the template, a module, Tag Manager, or a separate plugin.
• Before consent, the script is absent from the source code or not executed.
• After consent, the script appears or changes the consent status as intended.
• Decline does not trigger marketing or analytics cookies.
• The console does not show JavaScript errors after button clicks.

Duplication is a common source of false conclusions. The administrator moves one snippet into Cookies Policy Notification Bar, but an identical snippet remains in the template or Tag Manager. That makes it look like the extension "is not blocking cookies," when in fact it is only blocking the code it was actually given to manage.

The method that uses {cpnb} tags

For individual embeds and scripts, Web357 documents wrapper tags. The idea is simple: the code goes between opening and closing {cpnb}-compatible tags, optionally with a category ID and a user-facing message. The HTML fragment below shows a safe markup pattern as an example, not a universal copy-and-paste snippet for every site:

<cpnb
  data-cpnb-cookie-category-id="analytics-cookies"
  data-cpnb-no-consent-message="Please, consent to load analytics content">
  <script>
    // Analytics, video provider, or advertising code goes here.
  </script>
</cpnb>

Web357 documentation explicitly states that data-cpnb-cookie-category-id must match the category ID from the plugin settings. If the ID in settings is analytical-cookies but the wrapper uses analytics-cookies, the blocking logic will not match the expected category. That is why it is useful to keep a working note with the exact category IDs for the project.

Video and third-party content

For YouTube, Vimeo, and similar providers, Web357 offers a separate tutorial using AllVideos and a GDPR-compliant template. The point is not that you must use that exact method on every site, but that an iframe from an external domain should not load before consent to the relevant category is granted. Before consent, the user can see a clear message; after consent, the embedded video can load.

If the site contains a lot of videos, it is usually better to create a category such as video-cookies or external-media. That is clearer than hiding videos under Analytics. The visitor can then see that they are accepting external media loading, not just "statistics," and that data may be sent to the provider.

Google Consent Mode v2

Web357 documentation includes a dedicated guide for Google Consent Mode v2. It describes a model with a default state, a consent update after consent, and an update after decline. Google's official documentation confirms the core logic: first set a default consent state, then update the state after the user's action; for v2, the additional parameters ad_user_data and ad_personalization are used.

In a practical configuration, it is important not to blur two separate layers:

• Script blocking determines whether third-party code loads before consent.
• Consent Mode tells Google tags which consent state applies to analytics and advertising.

If you use Google Tag Manager, verify the load order carefully. Google emphasizes that default consent must be set before commands that send measurement data. In a recent changelog entry, Web357 mentions dynamic Consent Mode updates without a page reload when Reload after accept is disabled. That is useful for UX, but it does not remove the need to verify the actual status through Tag Assistant or Consent Mode Inspector.

The Cookie Table, Repeat Consent, and Managing the User's Choice

Cookie consent does not end with the first click. The visitor should have a way to see which cookies are described on the site and to change their choice. For that, Web357 provides shortcode functionality, a cookies info table, a custom link for opening Cookies Manager, and the option to force re-consent by changing the cookie name.

The {cookiesinfo} shortcode for the policy page

Web357 documentation describes the following workflow: enable Block Cookies and Shortcode Functionality, then place {cookiesinfo} in a content item or module. After that, the user sees the cookies table and can reconsider the policy. This is especially useful after decline: Web357 explicitly explains that after the user clicks Decline, the banner should not automatically reappear, and the best way to let them change their decision is through the shortcode on the policy page or in a module.

If the shortcode appears as plain text instead of a table, check the context. For a custom module, Web357 points to the Prepare Content parameter. It must be enabled, otherwise Joomla will not process the shortcode and the visitor will see {cookiesinfo} literally.

Where to place a way to reopen settings

Several placements work well:

• The cookie policy page next to the category descriptions.
• A footer link labeled "Cookie settings."
• A small Cookie Manager icon button, as long as it does not interfere with the interface.
• A custom link with the ID cookies, if you want to open the modal from your own block.

Web357 shows that the modal can be opened via a button, link, or image with the ID cookies, and that if the hashlink is changed in settings, the ID in the HTML must be updated as well. This is a good way to embed the settings in the footer without permanently displaying a large banner.

Force re-consent by changing the cookie name

If the cookie policy changes, a new tracking service is added, or the categories change, previously saved consent can become outdated. Web357 describes a simple technical method: change the cookie name in Base Settings. Then the old consent cookie is ignored, and users will see the banner again.

Use this carefully. Do not change the cookie name without a reason, or visitors will keep seeing the prompt over and over. But if you added an advertising category or a new analytics provider, forcing re-consent is more sensible than quietly applying an old decision to a new setup.

Accept, Decline, Cancel, and cookie expiration times

Web357 documentation describes separate expiration times for plugin cookies: accept, decline, and cancel. The meaning is straightforward: accept can be stored longer, decline can have its own retention period, and cancel can have a shorter lifetime after which the notification appears again. If a value is set to 0, the cookie behaves as a session cookie and disappears when the browser is closed.

The distinction between Decline and Delete matters for support. According to Web357, Decline stores a special declined-state cookie so the system knows the user refused. Delete removes cookies, including the cookie that stores the accepted or declined decision. So after delete, the behavior resembles a first visit, while after decline the banner does not need to pop up again until the declined cookie expires.

Consent Logs, IP Addresses, and Automatic Cleanup

Consent logs are useful when a site needs to show that the user's choice was recorded. According to the JED description, the extension can automatically log consent with a timestamp and IP address, and Web357 documentation separately explains how to disable storing the IP address in the database. That is an important setting for data minimization: in some cases, the fact of consent is enough, while the IP address creates unnecessary risk.

When to keep logs

It makes sense to enable logs if the site operates in a context where you may need to confirm the user's action, or if you have an internal compliance process. But logging should not turn into endless accumulation of personal traces. Before enabling it, answer these questions:

• Why exactly do we need to store consent logs?
• Which fields are actually necessary?
• Do we need to store the IP address, or is status and time enough?
• Who has access to the logs in the admin panel?
• When should old logs be deleted?

Web357 points to the IP setting path as follows: Advanced Settings - Store Acceptance / Declined logs into the Database - Store IP Address into the database. The yes/no choice should align with your country's requirements and your site policy. This article cannot provide a universal legal answer, but from a technical risk perspective, it is safer not to store extra data if you do not need it.

Automatic cleanup through Joomla Scheduled Tasks

For Joomla 4+, Web357 describes the Scheduled Task named "Delete Cookie Policy Notification Bar Logs." The administrator can create the task, choose the execution rule, interval, and the number of days after which logs should be deleted, then run a test and review the execution history. Joomla documentation confirms that Scheduled Tasks are used for routine maintenance and can run through the lazy scheduler or web cron.

A practical workflow looks like this:

1. Define the retention period for consent logs together with the person responsible for privacy.
2. Create a scheduled task with a clear title, for example "Delete Cookie Policy Notification Bar Logs."
3. Set the interval and the age threshold for log deletion.
4. Run a test on staging or during a quiet period.
5. Check the execution history and make sure the task completed successfully.

Do not enable automatic cleanup randomly if you have not yet decided which logs you actually need. But do not let the database grow for years without a reason either. A consent extension works with data about user decisions, so database maintenance is part of the setup, not a secondary option.

Practical Scenario: A Banner with Categories, Analytics, and Repeat Choice

Let us walk through a realistic setup for a Joomla content site with Google Analytics, several YouTube embeds, and a cookie policy page. The goal is not to build a perfect legal model, but to create predictable technical behavior: analytics does not start before consent, videos do not load provider cookies without a choice, and the user can reopen the settings later.

Goal

The objective is to create a cookie banner with three clear actions: accept, decline, and open settings. The modal should contain the categories "Necessary," "Analytics," and "External media." Google Analytics should load only after consent to Analytics, and YouTube videos should display a placeholder until consent to External media is granted. The policy page should contain a cookie table and a link for revisiting the decision.

Preparation

Before you begin, make sure you have access to the Joomla admin panel, a site backup, Cookies Policy Notification Bar installed, a working privacy policy page, and a list of the places where analytics and YouTube are currently inserted. Temporarily disable duplicate analytics code in the template or modules if you are moving it into Web357 settings.

Configuration steps

1. Open System - Web357 Cookies Policy Notification Bar in the plugins list and enable the plugin.
2. In the base settings, define the notification text, the privacy policy link, and the button behavior.
3. In Advanced Settings, enable Block Cookies Functionality and the Cookie Manager modal.
4. Create the necessary-cookies category as locked if it is truly required for site operation.
5. Create the analytics-cookies category as user-changeable and do not load it by default if explicit consent is required.
6. Create the external-media category for YouTube or Vimeo embeds.
7. Add the Google Analytics script to the "Block Cookies by blocking their Javascript Code" block and assign it to analytics-cookies.
8. For YouTube embeds, use the method shown in Web357 documentation for video providers or use a {cpnb} wrapper with the category ID external-media.
9. Place {cookiesinfo} on the policy page. If it is used in a module, enable Prepare Content.
10. Add a footer link or button with the ID cookies if you want to open Cookies Manager from the footer.

Verification

Open the site in a private window. Before consent, verify that analytics provider cookies are absent and that the video placeholder does not load an external iframe. Click accept only analytics or accept all if the modal supports the choice you need, then refresh the page and check that the analytics state changed. Click decline in a new clean profile and confirm that the banner does not reappear on every page as if something were broken, and that the user can still change the decision through the policy page.

If you use Consent Mode, verify the default denied state and the update after the user's choice through Web357's recommended Consent Mode Inspector or Google Tag Assistant. Google's official documentation emphasizes the order of default before measurement commands, so do not just check the final state - check when that state appears.

One important detail

If videos or the cookie table appear only after a second refresh, inspect the cache settings. Web357 documentation for Joomla Cache recommends conservative caching, disabling System - Page Cache, and setting no caching for modules that contain shortcodes or video shortcodes. That is not a universal ban on caching, but it is a useful diagnostic point when dynamic consent-dependent content lags by one page reload.

Verifying the Result: How to Make Sure the Banner Does More Than Just Appear

The weakest possible test is to open the homepage and see the banner. That is not enough. You need to verify source code, cookies, network requests, the console, repeat choice behavior, and how different actions behave. Only then can you tell whether Cookies Policy Notification Bar works as a consent management layer rather than a decorative block.

Browser-side verification

1. Open the site in a clean profile or incognito mode.
2. Before clicking anything, open developer tools and inspect cookies for the current domain.
3. Check network requests to analytics, ad, video, and chat providers.
4. Click decline and make sure disallowed scripts did not load.
5. Clear cookies, repeat the test, click accept, and verify that the required scripts load.
6. Open the settings modal and change categories. Make sure the change takes effect after saving.
7. Check the mobile viewport, keyboard navigation, and visible focus.

Use a separate verification pass for Google Consent Mode. Web357 recommends Consent Mode Inspector, while Google provides Tag Assistant and documentation for consent troubleshooting. The important states are default denied before choice, update granted after consent, and denied after refusal. If the default state appears too late, Google tags may fire before the consent setup is in place.

Source code verification

If you moved a script into the extension settings, inspect the page source before consent. The code should no longer remain in the template. Searching for your analytics ID or GTM ID can help you spot duplicates. If you find the snippet in two places, remove the old copy first, then test again. Do not try to solve this with CSS, because a hidden element is not the same thing as a blocked network request.

Verification after updates

After updating Joomla, the template, an optimization tool, or Cookies Policy Notification Bar itself, run a short regression test:

• The banner appears for a new visitor.
• The modal opens and closes.
• Accept, decline, and cancel save the expected state.
• The cookies table appears on the policy page.
• Blocked scripts do not appear before consent.
• Consent Mode default and update fire in the correct order.

The Web357 changelog shows that fixes often affect modal buttons, {cpnb} tags, Consent Mode, accessibility, and compatibility. So after an update, do not stop at "the page loads." Verify the actual scenarios the extension is supposed to control.

Common Problems and Troubleshooting

Cookie consent issues often look similar: the banner is missing, keeps reappearing, the buttons do not close the dialog, cookies still show up, the shortcode does not work, or analytics disappears from reports. Below is a troubleshooting map specifically for Cookies Policy Notification Bar in a Joomla environment.

The banner does not appear

Symptom: the plugin is published, but no notification bar appears on the public site.

Possible causes: the user has already accepted or declined cookies, the banner is hidden for logged-in users, page cache is enabled, there is a JavaScript conflict, include/exclude pages are set, or the template is covering the element through z-index.

What to check: open a clean browser profile, clear cookies, temporarily enable debugging-friendly display, and inspect the console. Web357 documentation specifically mentions jQuery conflicts and scenarios involving System - Page Cache or JCH Optimize where disabling jQuery/Ajax functionality in the plugin settings may help.

How to fix it: first rule out a stored consent state, then check cache and JavaScript errors. If the problem is tied to a specific template, inspect the template options and z-index. If the banner appears in one template but not another, do not start changing cookie categories - look for an output conflict.

The banner appears on every page after accept or decline

Symptom: the user clicks a button, but the notification bar comes back again and again.

Possible causes: the choice cookie is not being saved, Ajax functionality is not working, the Ajax Interface component is missing on an older Joomla build, cache is serving an outdated page, or the cookie name is being changed too often.

What to check: verify whether a consent cookie exists after the click, whether there are Ajax errors in the network panel, and whether the com_ajax test URL for the cookies table opens. Web357 documentation describes the missing Ajax Interface case: accept/decline do not help, and the cookies info table does not display.

How to fix it: restore the Ajax component using the standard method for your Joomla version, check cache, and do not change the cookie name without a reason. If the issue started after an update, inspect the changelog and the installed extension version.

The {cookiesinfo} shortcode is displayed as text

Symptom: the page or module shows {cookiesinfo}, but no cookie table appears.

Possible causes: shortcode functionality is disabled, the module does not process content plugins, or the wrong shortcode is being used. Web357 also clarifies that {cpnb_cookies_info_table} and {cpnb_buttons} work only in the three textarea fields on the "Texts for Languages" tab, while {cookiesinfo} is meant for arbitrary placement.

What to check: make sure shortcode functionality is enabled, confirm that the correct shortcode is being used, and verify that Prepare Content is enabled in the custom module.

How to fix it: replace the shortcode with the correct one, enable content processing in the module, and clear cache. If the table appears in an article but not in a module, the problem is almost certainly in module processing.

Cookies still load before consent

Symptom: analytics or marketing cookies appear in browser storage before the user makes a choice.

Possible causes: the script is still present in the template or Tag Manager, the code was assigned to the wrong category, the category is enabled by default, a third-party extension loads the service independently of Web357, or the iframe was inserted without a {cpnb} wrapper.

What to check: find every place where the tracking code is inserted. Inspect the source, modules, template custom code, GTM container, analytics extension, and layout overrides. Compare the category ID in the wrapper with the ID in the plugin settings.

How to fix it: keep a single source of script loading, assign it to the correct category, and rerun the test in a clean profile. If a third-party extension does not let you control script output, use its own privacy settings or move the code into Web357 if it is safe to do so.

Videos or the cookie table appear only after a second refresh

Symptom: after accept, the content does not appear immediately, but everything works after a second refresh.

Possible causes: cache is serving an older module variant, page cache is interfering with dynamic content, or the shortcode module is cached.

What to check: Web357 documentation for Joomla Cache recommends conservative caching, disabling System - Page Cache, and setting No caching for the module that contains the info shortcode or video shortcode.

How to fix it: adjust caching selectively. Do not disable all cache blindly, but modules with consent-dependent content must update after the user's choice.

Consent Mode shows the wrong status

Symptom: the Consent Mode inspector shows granted before the user makes a choice, no update appears after accept, or the status does not change after decline.

Possible causes: default consent code loads after Google tags, the selected script loading time is wrong, the GTM snippet is duplicated, or Consent Mode is configured both in Web357 and in GTM without a consistent logic.

What to check: review the order of the default command, the presence of ad_user_data and ad_personalization, Web357 rows for always load, after consent, and after decline, and the GTM consent settings.

How to fix it: bring the setup back to a single coherent logic. Default denied must be set before measurement commands, and the update must happen immediately after the user's choice. If you use GTM templates, validate behavior against Google's documentation, not just the visual state of the banner.

The administrator gets logged out of the backend after enabling Block Cookies

Symptom: after aggressive cookie blocking is enabled, login or session problems start appearing.

Possible causes: session cookies required for Joomla or the admin panel were blocked. Web357 documentation for "How to Not Load Any Cookies" shows that the Allow Session Cookies parameter affects session cookie loading, and you need to understand that before turning it off.

What to check: verify whether you disabled session cookies, whether that affects the public site and the backend, and whether there are separate settings for logged-in users.

How to fix it: do not block session cookies on a site that uses login, a user area, a cart, or admin-dependent functions unless you fully understand the consequences. Test on staging first.

Safe Enhancements and Careful Customization

Cookies Policy Notification Bar supports custom CSS and custom JavaScript, but that is not an invitation to rewrite the extension's behavior. In most cases, adjusting colors, sizes, focus states, and text is enough. Code should be used only for small, testable improvements.

CSS for visible focus and cleaner spacing

If the template hides the focus outline or the banner buttons are hard to see when navigating by keyboard, you can add a small CSS snippet either to the extension's custom CSS field or to the template's custom.css. The selectors below depend on the actual markup on the site, so inspect the classes in the browser first before applying them.

/* Make keyboard focus more visible in the cookie banner area */
.cpnb-button:focus,
.cpnb-button:focus-visible,
#cookies:focus,
#cookies:focus-visible {
  outline: 3px solid #1d6fdc;
  outline-offset: 3px;
}

/* Keep the bottom banner from sticking to the screen edges on mobile */
.cpnb-container {
  max-width: calc(100% - 24px);
  margin-left: auto;
  margin-right: auto;
}

The check is simple: open the page, press Tab, and make sure the active button is visible. Then verify the layout at mobile width. Rollback is equally simple - remove the snippet and clear cache. Do not use display: none on consent choice elements, because that can break both accessibility and the user's decision flow.

Custom JavaScript: when it is better to leave it alone

Web357 publishes documentation about trigger events and custom behavior for specific buttons. Those capabilities can be useful for developers, but on a typical site it is better to start with the built-in settings: button sorting, the modal, category descriptions, the custom link ID, and expiration times. Any custom JS around accept/decline touches the critical consent path, so it must be retested after every extension update.

If you need decline to open the modal on a specific category, use the official Web357 example as a reference and adapt only the category ID. Do not paste someone else's snippet without checking the actual IDs on your site. If the button stops closing the modal after adding code, roll back the custom JS and review the changelog - some modal button issues have already been fixed in product updates.

When Cookies Policy Notification Bar Is the Right Choice

Cookies Policy Notification Bar is a good fit if you need a Joomla-native tool that combines a banner, Cookie Manager, category-based script blocking, repeat choice, a cookie table, consent logs, and integration with Google Consent Mode. It is especially useful when the site does more than rely on technical session cookies and also uses analytics, advertising, videos, or external services.

Before deployment, do not skip the script audit, policy page review, or cache checks. After deployment, do not stop at a visual banner check - inspect cookies, network requests, source code, consent status, keyboard navigation, and shortcodes. Those checks are what show whether the extension is actually controlling site behavior instead of just adding a polished strip to the page.

If you are ready to go through that setup and verify the result on your own site, you can move to the download block and download Cookies Policy Notification Bar. After installation, start with a minimal configuration, then add categories, scripts, Consent Mode, and logs one layer at a time so you can quickly roll back any questionable setting.