WordPress Consent for Membership Sites: The Logged-In User Problem

A membership site has two visitors, and the consent banner only sees one of them. The guest sees the banner, makes a choice, and the CMP stores it in a cookie. The member logs in, and the cookie is still there, but the member is now a person with an account, a profile, and a history, and the banner treats them like a stranger who has never visited. The consent the member gave as a guest is stored in a cookie that expires. The consent the member should have is stored in the account, where it survives the cookie, the browser, and the device. The banner that cannot tell a member from a guest is a banner that loses the member's choice every time the cookie dies.

The cookie expires, the account does not

Consent stored in a cookie lasts as long as the cookie does, and on a membership site that is the wrong lifetime. The member logs in on a new device, and the cookie is not there, so the banner appears again and the member has to choose again. The member clears cookies, and the choice is gone. The member's consent should live in the user meta, tied to the account, not in the browser. The WordPress Consent API gives you the mechanism: the consent state is stored per user, the CMP reads it on login, and the banner does not appear for a member whose account already holds a choice. The cookie is the fallback for guests. The account is the record for members.

The problem is that most WordPress CMP plugins were built for guests. They store consent in a cookie, they show the banner to everyone, and they have no setting for logged-in users. The member sees the banner on every new device, clicks accept to make it go away, and the CMP records a fresh consent that overwrites the old one, with no history of what changed. The record that matters, the member's actual preference, is lost in a pile of cookie-based accepts that all look the same. The Jetpack Cookie Consent Block documentation describes the block-based approach, where the banner lives in the theme and the consent state is available to blocks, and that is the right shape: the consent state has to be readable by the site, not just by the CMP, so the member's account page can show it and the member can change it there.

Let the member change it in the account

A member who wants to change their consent should not have to find the banner again. The account page should show the current choice and let the member change it, and the change should propagate to the CMP and to the cookie at once. That is the GDPR Article 7(3) requirement in practice: withdrawing consent must be as easy as giving it, and for a member, the account page is where easy lives. The banner is for guests. The account page is for members. Caching has the same member problem: the banner shows the wrong state because the cache served a guest's page to a member, and the consent state has to vary by login, not just by cookie. The consent log has the same gap: what to record when a visitor changes their mind, and on a membership site the log has to record the account, not just the cookie, or the change is untraceable.

Test it as a member, not as a guest

Log in as a test member, set a consent choice, log out, clear cookies, and log in again on a different browser. If the banner appears, the consent lives in the cookie and not in the account. If the account page shows the choice and the banner stays hidden, the consent lives where it should. The test takes five minutes and it is the test every member runs without knowing it, every time they switch devices. Run it after every CMP update, because updates reset the logged-in handling more often than anyone admits, and the member who sees the banner again is the member who stops trusting the site with their data.

Document which consent lives where. Guests in the cookie, members in the account, and the sync between them in the login hook. A consent record that cannot say where it lives is a record that cannot be defended.

Frequently asked questions

Why does consent need to live in the account for members?

Because a cookie expires, gets cleared, or does not exist on a new device, and the member's choice goes with it. The WordPress Consent API lets you store consent per user, so the choice survives the cookie, the browser, and the device. The cookie is the fallback for guests; the account is the record for members.

Should logged-in members see the consent banner?

Not if their account already holds a choice. The CMP should read the consent state from the user meta on login and keep the banner hidden. A member who sees the banner on every new device is a member whose consent lives in the wrong place.

How should a member change their consent?

From the account page, where the current choice is shown and can be changed. GDPR Article 7(3) requires withdrawing consent to be as easy as giving it, and for a member the account page is where easy lives. The change should propagate to the CMP and the cookie at once.

How do I test member consent?

Log in as a test member, set a choice, log out, clear cookies, and log in again in a different browser. If the banner appears, consent lives in the cookie. If the account page shows the choice and the banner stays hidden, it lives in the account where it belongs.