The core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-privacy team are currently working on three modular, but complementary initiatives, with the aim of merging into 5.6.
These are: The Consent API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. (website visitor level privacy); the Disclosures Tab (site-level privacy) and collaborating with the core-media team on the Local Avatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. Project.
The Consent API in its current form does not distinguish between consent preferences for users who are registered and logged in, vs. those who are either not registered, or registered, but not logged in.
This means that all consent preferences are currently saved in cookies.
This means that there are two approaches available to the team. Either we can use the
wp_set_consent() function from the user’s profile page to allow them to manage their preferences and prevent unnecessary API calls (proposal 1 – status quo), or we can let the database be the ultimate source of truth to provide a more robust API, rather than an interface for an analytics opt-out (proposal 2).
There has been a lot of discussion in the channel lately. I will post a separate P2 A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs. post for discussions such as prompting logged in users who previously opted in for consent again if new cookies are added – or at the very least least providing the necessary hooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and filters for plugins to do so. Those are concerns can be realistically and effectively addressed in the UI User interface design requirements.
This is a fundamental design choice and while the window is wide open now, it will not remain so for long, as 5.6. approaches.
For purposes of this discussion, we please need input on the following, so that we can take the matter to dev chat:
1. Should consent preferences for registered users (applicable when logged in) be saved in cookies, or should they be saved in the database?
If consent preferences are saved in cookies, these could be displayed (and updated) in the user profile, but the choice would be transient and would effectively need to revert to site defaults every time the cookie is cleared.
2. If they are saved in the database, should the REST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. be used to expose the logged in user’s consent preference on the front end?
3. If the REST API is used, should a new REST endpoint be created, or should
register_meta() be used instead?
4. Should the consent preference be exposed on the front end using
wp.data? The trade-off being that this provides nicer abstraction and makes it easier to move towards object-oriented, rather than event-orientated programming, but adds a few KB to the front-end?
wp.data is used, should only this be used, or should the consent preference still be exposed to the front end by a method in point 3?
Thank you for everyone who has participated in this discussion on Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. so far. I intentionally did not include who made which proposals for this P2 post, in order to focus on the merits of the alternative solutions, but will credit participants in tickets if those need to be created.
Participants in the Slack discussion are of course very welcome to express their opinions here! 😀
Your inputs are appreciated!