If a CookiePro cookie-settings button does nothing, check whether the OneTrust preference-center method is available and whether the button reaches it. A returning visitor may correctly see no banner but must still be able to use the site's intended preference controls. Reinstalling the CMP can create a duplicate without fixing the button.
Separate the button from the consent service
Use a fresh test browser and a returning-browser test where you have already made a choice. Record which public templates contain the control: footer, checkout, landing page or translated page. Test the published site while logged out, because optimization rules often differ for administrators.
OneTrust documents ToggleInfoDisplay as its public method for displaying the preference center. A developer can make this read-only availability check in the browser console:
typeof window.OneTrust?.ToggleInfoDisplay
A result of function means the method exists at that moment. It does not prove your button calls it, the panel is visible, or consent is correctly enforced. If it is unavailable, inspect the CMP script and configuration requests first. Use the missing CookiePro banner guide for that branch.
Follow a single click
On staging, compare a working page with a failing one. Check whether the control is a real button, whether its click handler is attached after the footer renders, and whether the first console error prevents subsequent scripts from running. Avoid adding a second handler before finding the first, since two toggles can immediately open and close the panel.
If the panel is added to the page but cannot be seen, inspect custom CSS and fixed overlays. A mobile chat widget, sticky footer or aggressive display rule may cover the interface. Remove only the conflicting rule on staging, then verify desktop and mobile focus behavior.
New visitor: Expected interface appears. Returning visitor: Settings reopen. Keyboard: Focus remains usable. Withdrawal: Approved tag behavior follows. Explanatory checklist, not a customer test result.
Treat navigation without reload as a separate case
Some WordPress frontends replace page content without a full reload. A button that works on the initial page but fails after navigation may have lost its binding. OneTrust's SPA documentation describes additional integration work for this architecture. Use that guidance only when your frontend actually behaves as an SPA, not merely because it uses JavaScript.
Do not use AllowAll, delete saved consent, or force a banner redisplay as a substitute for opening preferences. Those actions have different meanings. Preserve the visitor's actual selection and the organization's approved consent behavior.
Verify that the changed choice matters
Open settings by mouse and keyboard, change one optional category, save, navigate and reopen. Confirm both the displayed selection and the relevant tag behavior. Test withdrawal as carefully as acceptance. Record the page, visitor state and expected result without storing personal identifiers.
This is a technical control test, not legal certification. If the control is tied to a theme footer, consent plugin and delayed scripts, HandL WP can trace that integration and verify that the repair survives the next page navigation.
References reviewed October 12, 2026. Examples are explanatory, not customer test results.