REST API – Head Tags vs WP Consent API

This plugin adds all the tags in the head section of a website to WordPress REST API responses. It is perfect if you are using WordPress for a headless set-up and would like to add the meta tags generated by your WordPress SEO plugin (like Yoast SEO or All-in-One SEO Pack) to the WordPress REST API output. Requirements This package depends on the PHP DOM library. Most PHP environments have it by default so you don’t have to worry about that. In case you get some errors regarding this dependency make sure you have this library installed (you can take a look at this thread in the code repository). Compatibility This plugin is compatible and works out of the box with some of the most popular WordPress SEO plugins. These are the ones that we tested: Yoast SEO – (up to 13.5) All in One SEO Pack – (up to 3.4.2) WP SEO – Are you using a different SEO plugin and want to know if it’s compatible? Feel free to ask in our community forum. If you tested any other plugin, please let us know as well so we can update the list. How to use this plugin Entities with head tags The plugin has been developed to include the head_tags field to the REST API response of most of the WordPress core entities: Posts, pages, attachments and custom post types. Post types: for archive pages. Categories, tags and custom taxonomies. Authors. In a Frontity project If you are using Frontity, you just have to install the @frontity/head-tags package and it will work automatically. In a different project You need to understand better how it works and add the data manually. How to fetch the head_tags field manually You have to get each entity from its respective REST API endpoint. For example: for fetching the posts, you should go to /wp-json/wp/v2/posts&id=123 endpoint; for fetching the categories, you have to go to wp-json/wp/v2/categories&id=123, and for custom post types or custom taxonomies, it would be a different url in each case. In the case of the homepage, it’s less intuitive and you should go to /wp-json/wp/v2/types/post. As previously said, each entity has a different endpoint so if you aren’t familiar with this, you should check out the WordPress REST API reference for more information. Inside each endpoint, it will be a new field named head_tags, which will be an array of objects representing the tags that WordPress would normally include inside the html head element. These objects have the properties tag, attributes and content. For example for these HTML tags: Hello wordl! - My Site " /> This would be the content of the head_tags field: "head_tags": [ { "tag": "title", "content": "Hello world! - My Site" }, { "tag": "meta", "attributes": { "name": "robots", "content": "max-snippet:-1, max-image-preview:large, max-video-preview:-1" } }, { "tag": "link", "attributes": { "rel": "canonical", "href": " " } } ] Settings The settings of this plugin are really simple. Purge cache In order to not affect the performance of your site, the head_tags field is cached for all your responses. Each time you update a post/page/cpt or a taxonomy, the cache for that entity will be purged automatically. In case you make global changes (i.e. your permalinks or your global Yoast settings) use the Purge button to clean the whole cache. Enable output By default, the head_tags field is included in the common endpoint of each entity. You can configure it so it doesn’t appear by default and to be shown when you include the head_tags=true query. For example, with the output disabled, https://test.frontity.org/wp-json/wp/v2/posts won’t show the head_tags field unless you have the query ?head_tags=true at the end. Skip cache In case you want to skip the cache, you can do so by adding to the query the parameter skip_cache. There are some cache plugins for the REST API which also use the same parameter. In case you want to ignore the cache for the REST API call but not for the head tags, you can use skip_cache&head_tags_skip_cache=false. Problems and Questions If you have any trouble with the REST API – Head Tags, you can check out our docs or join our community forum and let us know. We’ll be happy to help! Bug reports for REST API – Head Tags plugin are welcomed in our repository on GitHub. Before opening an issue, please be sure to review the contributing guidelines. More Information About Frontity Framework Guide on SEO for Headless WordPress Themes Follow Frontity on Twitter and GitHub Get help on the Frontity Community Forum

WP Consent API is a plugin that standardizes the communication of accepted consent categories between plugins. It requires a cookie banner plugin and, at least, one other plugin that supports the WP Consent API. With this plugin, all supporting plugins can use the same set of methods to read and register the current consent category, allowing consent management plugins and other plugins to work together, improving compliance with privacy laws. WARNING: the plugin itself will not handle consent. It will show you how many plugins you have without Consent API support and will improve compliance on your site by ensuring smooth communication between cookie banner plugins and plugins that set cookies or track user data. What problem does this plugin solve? Currently, it is possible for a consent management plugin to block third-party services like Facebook, Google Maps, Twitter, etc. But if a WordPress plugin places a PHP cookie, a consent management plugin cannot prevent this. Secondly, some plugins integrate the tracking code on the clientside in javascript files that, when blocked, break the site. Or, if such a plugin’s javascript is minified, causing the URL to be unrecognizable and won’t get detected by an automatic blocking script. Lastly, the blocking approach requires a list of all types of URL’s that tracks data. A generic API where plugins adhere to can greatly facilitate a webmaster in getting a site compliant. Does usage of this API prevent third-party services from tracking user data? Primary this API is aimed at compliant first-party cookies or tracking by WordPress plugins. If such a plugin triggers, for example, Facebook, usage of this API will be of help. If a user embeds a Facebook iframe, a blocking tool is needed that initially disables the iframe and or scripts. Third-party scripts have to blocked by blocking functionality in a consent management plugin. To do this in core would be to intrusive, and is also not applicable to all users: only users with visitors from opt-in regions such as the European Union require such a feature. Such a feature also has a risk of breaking things. Additionally, blocking these and showing a nice placeholder requires even more sophisticated code, all of which should in my opinion not be part of WordPress core, for the same reasons. How does it work? There are two indicators that together tell if consent is given for a specific consent category, e.g., “marketing”: 1) the region based consent_type, which can be opt-in, opt-out, or other possible consent_types; 2) and the visitor’s choice: not set, allow, or deny. The consent_type is a function that wraps a filter, “wp_get_consent_type”. If there’s no consent management plugin to set it, it will return false. This will cause all consent categories to return true, allowing cookies to be set on all categories. If opt-in is set using this filter, a category will only return true if the value of the visitor’s choice is “allow”. If the region based consent_type is opt-out, it will return true if the visitor’s choice is not set or is “allow”. Clientside, a consent management plugin can dynamically manipulate the consent type and set several cookie categories. A plugin can use a hook to listen for changes or check the value of a given category. Categories and most other stuff can be extended with a filter. Existing integrations Categorized, and sorted alphabetically Example plugin Example plugin. The plugin basically consists of a shortcode, with a div that shows a tracking or not tracking message. No actual tracking is done 🙂 Consent Management Providers Abconsent Sirdata CMP. Beautiful Cookie Consent Banner. Clickio Consent Cookie Consent CMP. Complianz GDPR/CCPA. Consent Studio. consentmanager. Conzent. Cookiebot. CookieFirst. CookieHub. CookieTractor. CookieYes – Cookie Banner for Cookie Consent. GDPR Cookie Compliance. GDPR Cookie Consent Plugin – CCPA Ready. GetTerms. iubenda | All-in-one Compliance. Lawwwing. Pressidium Cookie Consent. TrustArc Cookie Consent Manager Consent Requiring Plugins AddToAny. AFL UTM Tracker Plugin. Burst Statistics. Google Site Kit. Pixel Manager for WooCommerce. Woo. WP Statistics. Demo site wpconsentapi.org Below are the plugins used to set up the demo site: Complianz The example plugin javascript, consent management plugin //set consent type window.wp_consent_type = 'optin' //dispatch event when consent type is defined. This is useful if the region is detected server side, so the consent type is defined later during the pageload let event = new CustomEvent('wp_consent_type_defined'); document.dispatchEvent( event ); //consent management plugin sets cookie when consent category value changes wp_set_consent('marketing', 'allow'); javascript, tracking plugin //listen to consent change event document.addEventListener("wp_listen_for_consent_change", function (e) { var changedConsentCategory = e.detail; for (var key in changedConsentCategory) { if (changedConsentCategory.hasOwnProperty(key)) { if (key === 'marketing' && changedConsentCategory[key] === 'allow') { console.log("just given consent, track user") } } } }); //basic implementation of consent check: if (wp_has_consent('marketing')){ activateMarketing(); console.log("set marketing stuff now!"); } else { console.log("No marketing stuff please!"); } PHP //declare compliance with consent level API $plugin = plugin_basename( __FILE__ ); add_filter( "wp_consent_api_registered_{$plugin}", '__return_true' ); /** * Example how a plugin can register cookies with the consent API * These cookies can then be shown on the front-end, to the user, with wp_get_cookie_info() */ function my_wordpress_register_cookies(){ if ( function_exists( 'wp_add_cookie_info' ) ) { wp_add_cookie_info( 'AMP_token', 'AMP', 'marketing', __( 'Session' ), __( 'Store a unique User ID.' ) ); } } add_action('plugins_loaded', 'my_wordpress_register_cookies'); if (wp_has_consent('marketing')){ //do marketing stuff } Service-level consent In addition to category-based consent, the API supports service-level consent control. This allows consent management plugins to grant or deny consent for specific services (like ‘google-analytics’ or ‘facebook-pixel’) independently from their category. When checking service consent with wp_has_service_consent(), the API first checks if explicit consent exists for that service. If no explicit consent is set, it falls back to the consent status of the service’s category. This enables fine-grained control: a user might accept statistics cookies in general, but explicitly deny a specific analytics service. Service consent can be checked and set both server-side (PHP) and client-side (JavaScript): PHP: //check if a specific service has consent if ( wp_has_service_consent( 'google-analytics' ) ) { //activate google analytics } //check if a service is explicitly denied if ( wp_is_service_denied( 'facebook-pixel' ) ) { //service was explicitly denied by user } //set service consent wp_set_service_consent( 'google-analytics', true ); //grant consent wp_set_service_consent( 'facebook-pixel', false ); //deny consent //listen for service consent changes add_action( 'wp_consent_service_changed', function( $service, $consented ) { error_log( "Service {$service} consent changed to: " . ( $consented ? 'granted' : 'denied' ) ); }, 10, 2 ); JavaScript: //check service consent if ( wp_has_service_consent( 'youtube' ) ) { //activate tracking } //check if explicitly denied if ( wp_is_service_denied( 'facebook-pixel' ) ) { //service denied } //set service consent wp_set_service_consent( 'youtube', true ); //listen for service consent changes document.addEventListener( 'wp_consent_api_status_change_service', function( e ) { console.log( 'Service: ' + e.detail.service + ', consented: ' + e.detail.value ); }); Any code suggestions? We’re on GitHub as well!