{"id":398360,"date":"2026-11-05T20:24:32","date_gmt":"2026-11-05T20:24:32","guid":{"rendered":"https:\/\/wordpress.org\/plugins\/dt-pm-consent\/"},"modified":"2026-11-05T20:24:05","modified_gmt":"2026-11-05T20:24:05","slug":"dt-pm-consent","status":"publish","type":"plugin","link":"https:\/\/wordpress.org\/plugins\/dt-pm-consent\/","author":23562684,"comment_status":"closed","ping_status":"closed","template":"","meta":{"version":"1.1.4","stable_tag":"1.1.4","tested":"7.1.4","requires":"6.2","requires_php":"7.4","requires_plugins":null,"header_name":"DT-PM Consent","header_author":"DT PM GmbH","header_description":"GDPR and ePrivacy consent management for cookies and third-party services. Blocks scripts that require consent before they are executed.","assets_banners_color":"13233f","last_updated":"2026-11-05 20:24:05","external_support_url":"","external_repository_url":"","donate_link":"","header_plugin_uri":"","header_author_uri":"","rating":0,"author_block_rating":0,"active_installs":0,"downloads":92,"num_ratings":0,"support_threads":0,"support_threads_resolved":0,"author_block_count":0,"sections":["description","installation","faq","changelog"],"tags":{"1.1.4":{"tag":"1.1.4","author":"dtpm","date":"2026-11-05 20:24:05","revision":3786727}},"upgrade_notice":{"1.0.13":"

Only the name: the plugin is now called DT-PM Consent, without the addition\n"for WordPress". Your settings, your records and the cookie are untouched.<\/p>","1.0.11":"

The analysis page now says what it does not know. If the collector has never\nrun, the result says so instead of looking like an all-clear. Adopting\nservices got clearer, and adopting several at once is now recommended in one\ngo, because every single adoption asks all your visitors again.<\/p>","1.0.10":"

The banner now takes its accent colour and font from your website, with no\nconfiguration. If you style the banner with your own CSS, a plain class no\nlonger overrides it - use the same specificity. Some themes were overriding\nthe banner's own buttons, which is why this was needed.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3786727,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3786727,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256},"icon.svg":{"filename":"icon.svg","revision":3786727,"resolution":false,"location":"assets","locale":false}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3786727,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3786727,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":{"dt-consent\/cookie-policy":{"name":"dt-consent\/cookie-policy","title":"Cookie declaration"}},"tagged_versions":["1.1.4"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3786727,"resolution":"1","location":"assets","locale":"","width":1440,"height":1000},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3786727,"resolution":"2","location":"assets","locale":"","width":1440,"height":1063},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3786727,"resolution":"3","location":"assets","locale":"","width":1440,"height":1400},"screenshot-4.png":{"filename":"screenshot-4.png","revision":3786727,"resolution":"4","location":"assets","locale":"","width":1440,"height":1400},"screenshot-5.png":{"filename":"screenshot-5.png","revision":3786727,"resolution":"5","location":"assets","locale":"","width":1440,"height":1000}},"screenshots":{"1":"The banner as a first-time visitor sees it. Every category names the services behind it, with the provider; \"Reject all\" carries the same weight as \"Accept all\".","2":"The guided setup. A script the plugin does not recognise is not guessed at - it is handed to you with its origin, the pages it turned up on, and a category to choose.","3":"One service in the list: provider, purpose, storage period, third-country transfer and the safeguard it rests on, plus the cookie names and script handles that are blocked and deleted on withdrawal.","4":"The scan compares what your website loads with what your service list declares, and says what is still open. It changes nothing by itself.","5":"The cookie declaration on the website, from the [dt_consent_cookies]<\/code> shortcode. It is generated from the same service list - there is no second place to maintain."}},"plugin_section":[],"plugin_tags":[20011,389,154545,131785,278163],"plugin_category":[],"plugin_contributors":[283911],"plugin_business_model":[],"class_list":["post-398360","plugin","type-plugin","status-publish","hentry","plugin_tags-consent","plugin_tags-cookies","plugin_tags-dsgvo","plugin_tags-gdpr","plugin_tags-tdddg","plugin_contributors-dtpm","plugin_committers-dtpm"],"banners":{"banner":"https:\/\/ps.w.org\/dt-pm-consent\/assets\/banner-772x250.png?rev=3786727","banner_2x":"https:\/\/ps.w.org\/dt-pm-consent\/assets\/banner-1544x500.png?rev=3786727","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":"https:\/\/ps.w.org\/dt-pm-consent\/assets\/icon.svg?rev=3786727","icon":"https:\/\/ps.w.org\/dt-pm-consent\/assets\/icon.svg?rev=3786727","icon_2x":false,"generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/dt-pm-consent\/assets\/screenshot-1.png?rev=3786727","caption":"The banner as a first-time visitor sees it. Every category names the services behind it, with the provider; \"Reject all\" carries the same weight as \"Accept all\"."},{"src":"https:\/\/ps.w.org\/dt-pm-consent\/assets\/screenshot-2.png?rev=3786727","caption":"The guided setup. A script the plugin does not recognise is not guessed at - it is handed to you with its origin, the pages it turned up on, and a category to choose."},{"src":"https:\/\/ps.w.org\/dt-pm-consent\/assets\/screenshot-3.png?rev=3786727","caption":"One service in the list: provider, purpose, storage period, third-country transfer and the safeguard it rests on, plus the cookie names and script handles that are blocked and deleted on withdrawal."},{"src":"https:\/\/ps.w.org\/dt-pm-consent\/assets\/screenshot-4.png?rev=3786727","caption":"The scan compares what your website loads with what your service list declares, and says what is still open. It changes nothing by itself."},{"src":"https:\/\/ps.w.org\/dt-pm-consent\/assets\/screenshot-5.png?rev=3786727","caption":"The cookie declaration on the website, from the [dt_consent_cookies]<\/code> shortcode. It is generated from the same service list - there is no second place to maintain."}],"raw_content":"\n

DT-PM Consent stops third-party scripts and embeds from loading before the\nvisitor has consented. It shows a banner with equally weighted buttons for\naccept and reject, allows a choice per purpose, and records every\nconfiguration change as evidence.<\/p>\n\n

What you get<\/h4>\n\n
    \n
  • A guided setup in four steps. It shows what your site loads, proposes an\nentry for every service it recognises, and names what is still open before\nit lets you call the setup finished.<\/li>\n
  • A scanner in two parts, both included. The server side reads the scripts and\nstylesheets WordPress knows about; a collector records what actually loads in\nyour own browser while you are logged in, so a script injected at runtime is\nfound as well \u2014 not only one that sits in a registry. It finds and names;\nwhere it cannot block, it says so instead.<\/li>\n
  • 24 ready-made service templates, each with provider, purpose, storage period\nand third-country transfer, and each backed by a source. Where a provider\nstates nothing, the template says so rather than inventing a value, and for\npayment services and tag managers the category is deliberately left to you.\nYour own code can add entries through a documented filter.<\/li>\n
  • A cookie declaration for your privacy policy, as a shortcode or a block. It\nis built from the same data as the banner and through the same code, so the\ntwo cannot end up saying different things.<\/li>\n
  • An archive of every configuration change, exportable as CSV. It records what\nyour banner said and when \u2014 it is not a log of individual visitors, and the\nplugin keeps none.<\/li>\n
  • One consent cookie, carrying a fingerprint of the configuration rather than a\nbare counter: when the service or purpose list changes in substance, the\nfingerprint no longer matches and the banner asks again. The decision can\noptionally be shared across your own subdomains \u2014 switched off by default,\nand the FAQ below says when to leave it off.<\/li>\n
  • Warnings where an entry would be worthless. A service without a cookie name\ncannot have its cookies deleted on withdrawal, and a service with nothing\nthis plugin can hold back is listed as a defect instead of counting as\nconfigured.<\/li>\n
  • Keyboard operation, stated rather than implied: Escape rejects while no\ndecision has been made and only closes the dialog once one exists, and the\nbanner says which of the two applies. The banner passes axe-core against the\nWCAG 2.2 AA rule set without a violation (Chromium, Twenty Twenty-Five, at\n1280 and 640 pixels and at 200 % text size). No screen reader was used, so\nwhether the error message is actually announced (4.1.3) is untested, and the\ncheck covered the visitor's banner, not the admin screens.<\/li>\n
  • German and English included.<\/li>\n
  • GPLv2 or later. Nothing is held back for a paid version, and the plugin sends\nno request to any server of ours \u2014 not on a schedule, not at all.<\/li>\n<\/ul>\n\n

    No page-view limit, no domain limit, no seat count, and no switch that trips\nonce your site grows. There is nothing to count against: the plugin contacts no\nserver of ours, so no number about your site ever leaves it.<\/p>\n\n

    What the plugin does<\/h4>\n\n
      \n
    • Rewrites registered scripts of consent-requiring services into inert\nplaceholders. The browser neither loads nor executes them.<\/li>\n
    • Blocks the inline snippets WordPress attaches to a script as well \u2014 with\nanalytics integrations, that is usually where the call that sets the cookie\nlives.<\/li>\n
    • Replaces embedded iframes of known providers with a placeholder that names\nthe provider and offers a button to load it.<\/li>\n
    • Names each service and its provider visibly on the first banner level.\nPurpose, storage period, third-country transfer and the cookie names sit\nnext to it, expandable \u2014 on the same level, without having to consent first.<\/li>\n
    • Offers a way to withdraw consent from every page. Withdrawing deletes the\naffected cookies and reloads the page, so that scripts already running\nactually stop.<\/li>\n
    • Compares today's state against the last scan at the press of a button and\nreports what is new. Reminds you when the last scan is more than 30 days\nold.<\/li>\n
    • Raises a configuration version whenever the service or purpose list changes\nin substance. Existing consents become invalid and the banner appears again.<\/li>\n<\/ul>\n\n

      What the plugin explicitly does NOT do<\/h4>\n\n

      It blocks nothing on its own.<\/strong> Whatever is not in the service list is not\nblocked. The setup helper shows the scripts that loaded and suggests an entry\nfor the ones it recognises \u2014 but it adopts nothing without your confirmation.\nThat is a deliberate decision: a plugin that decides by itself which scripts\non someone else's website perform tracking would either block too little (and\npretend safety) or too much (and take the site down).<\/p>\n\n

      Detection is not complete.<\/strong> It knows a limited number of common services.\nAn unrecognised script is marked as unknown and presented with empty fields \u2014\nthe plugin guesses neither provider nor purpose nor storage period. An empty\nrow you have to fill in is more honest than a filled-in one that is wrong.<\/p>\n\n

      The setup helper puts two cases first: external servers and recognised\nservices.<\/strong> Everything else \u2014 WordPress itself, your theme, plugins on your\nown server \u2014 sits below, collapsed but complete. That is a display decision\nand not a legal assessment: a plugin can live on your server and still set\ncookies. Go through the second list instead of relying on the first.<\/p>\n\n

      It does not catch scripts written into the markup around the WordPress\nAPI.<\/strong> The collector finds<\/em> them and tells you they are there \u2014 block them\nthe plugin cannot. You then have to act yourself: remove the integration from\nthe theme, register it through wp_enqueue_script<\/code>, or serve the file from\nyour own server.<\/p>\n\n

      It stops nothing that is loaded from inside a stylesheet.<\/strong> An\n @import url('https:\/\/fonts.googleapis.com\/\u2026') or a font in an @font-face<\/code>\nrule keeps loading even when the service is listed as blocked: the plugin can\nstop a stylesheet by its ADDRESS, but it does not read what a stylesheet does\ninside. Four routes are affected \u2014 @import<\/code> in a <style><\/code> block, @import<\/code>\nin an enqueued stylesheet, url()<\/code> in an @font-face<\/code> rule, and\n background-image.<\/p>\n\n

      The setup helper finds<\/em> and names these cases for every stylesheet enqueued\nthrough WordPress, under \"Stylesheets that load from elsewhere\". Acting on\nthem is up to you: serve the font from your own server, or remove the\nreference in the theme. Many themes have a setting for exactly this. A\n <\/p>\n\n

      In detail: blocking applies to scripts registered through\n wp_enqueue_script(), to their inline snippets, to snippets entered in the\nadmin area, and to iframes in post content, text widgets and oEmbed output. A\ntheme that writes a tracking script directly into a template file is not\ncovered. Check this after setup with your browser's developer tools: open the\nnetwork tab, load the page without consenting, go through the list.<\/p>\n\n

      \"Inline snippets\" means less than it sounds like, and the difference\nmatters.<\/strong> It is the snippet WordPress attaches to a registered script \u2014 not\nany <script><\/code> you put into a post. And a script that builds a further script\nwhile the page runs (document.createElement('script')<\/code>) loads in any case:\nthe address it assembles exists only in the browser, and the plugin never sees\nit. This route is measured and open; it was the same in earlier versions.<\/p>\n\n

      It stores no consent of individual visitors.<\/strong> No server-side log, no IP\naddress, no visitor identifier. The duty to demonstrate consent is met through\nthe configuration archive: it records which services, purposes and texts were\nserved at which point in time. The guidance of the German data protection\nauthorities for providers of digital services states in para. 84 that\ndemonstrating consent does not require long-lived identifiers.<\/p>\n\n

      It is not legal advice.<\/strong> Whether your website meets the requirements with\nthis plugin depends on which services you use and how you describe them. The\nplugin provides the technology; the substantive accuracy of the entries and\nthe legal assessment remain with you.<\/p>\n\n\n

        \n
      1. Copy the dt-pm-consent<\/code> directory into wp-content\/plugins\/<\/code>.<\/li>\n
      2. Activate the plugin.<\/li>\n
      3. Under \"DT-PM Consent\", enter every service that sets cookies or transfers data\nto third parties.<\/li>\n
      4. Check the result: open the site in a private window and use the network tab\nto confirm that no request goes to a third party before consent.<\/li>\n<\/ol>\n\n

        Step 4 is not optional. A consent banner whose blocking does not work is worse\nthan none \u2014 it documents that the obligation was known.<\/p>\n\n\n

        \n

        How do I find the script handle of a service?<\/h3><\/dt>\n

        As a rule, no longer by hand: open \"DT-PM Consent \u2192 Setup helper\", visit your\nsite's front end while logged in, and come back. The scripts that loaded are\nlisted there with their handle and source.<\/p>\n\n

        If you do want to look it up yourself: in the page source the handle sits in\nthe id<\/code> of the script tag, with -js<\/code> appended. So\n <\/p><\/dd>\n

        Why does the page reload after a withdrawal?<\/h3><\/dt>\n

        Because a script that has already run cannot be unloaded again. It keeps\nlistening for events and would immediately set the deleted cookies anew. Only\na fresh page load, in which the scripts are never activated, actually enforces\nthe withdrawal.<\/p><\/dd>\n

        Why can I not change the label of \"Reject all\"?<\/h3><\/dt>\n

        Because supervisory authorities regularly object to banners in which the\nrejection has been renamed, hidden or removed altogether. The plugin therefore\ndoes not allow that configuration.<\/p><\/dd>\n

        Do I lose the evidence archive when I uninstall?<\/h3><\/dt>\n

        Yes. Deleting the plugin removes all of its data, the archive included. If you\nstill need it for an ongoing or expected audit, back it up first.<\/p><\/dd>\n

        May I share consent across subdomains of a shared domain?<\/h3><\/dt>\n

        Only if every subdomain is yours.<\/strong> If you share the parent domain with\nother people's websites \u2014 typical for site-builder and hosting offers of the\nform yourname.provider.com<\/code> \u2014 please do not switch on \"Valid on subdomains\".<\/p>\n\n

        The reason is a limit that cannot be closed technically: whoever can set\ncookies on a neighbouring subdomain can also write a consent cookie for your\nsite. Since 0.16.0 the plugin reliably detects that a cookie comes from a\nDIFFERENT installation and rejects it. That does not help against deliberate\nforgery: the check value sits in the source of every page and can be read from\nthere. Only a server-side check would be forgery-proof \u2014 and that cannot be\nreconciled with this plugin's cache compatibility (see the next question).<\/p>\n\n

        With the setting switched off \u2014 the default \u2014 the problem does not arise.<\/p><\/dd>\n

        Does a withdrawal also delete cookies from neighbouring subdomains?<\/h3><\/dt>\n

        Possibly, yes \u2014 and that is a deliberate decision. Many tracking cookies,\n _ga from Google Analytics among them, do not sit on your host but on the\nparent domain. Without deleting there, a withdrawal would have no effect.\nWhether \"the parent domain\" is yours alone cannot be decided without a\nconstantly maintained list of every domain suffix in the world.<\/p>\n\n

        The trade-off: either the withdrawal fails to delete what it is supposed to\ndelete, or on a shared domain someone else's statistics lose a counter. The\nfirst would be a breach of the law, the second an annoyance. Your own consent\ncookie has not been affected since 0.16.0 \u2014 a neighbour's decision is no\nlonger deleted along with it.<\/p><\/dd>\n

        Why do I see an empty area instead of a notice when JavaScript is off?<\/h3><\/dt>\n

        Since 0.19.0 the server only renders a blocked embed harmless; the visible\nnotice and its button are built by the plugin script in the browser.<\/p>\n\n

        The reason is the safety of the blocking itself: as long as the server\nassembled the placeholder, it carried over the remaining attributes of the\noriginal embed \u2014 and two routes arose along which an embed kept loading inside\nthe placeholder. The server now outputs no foreign attribute at all.<\/p>\n\n

        Without JavaScript nobody can consent anyway; the button had no effect there\nbefore either. Nothing loads without JavaScript \u2014 the blocking does not depend\non the script.<\/p><\/dd>\n

        Why is an embed blocked although no third party appears in it?<\/h3><\/dt>\n

        This concerns embeds that carry their content in the srcdoc<\/code> attribute. If\nthere is a <script><\/code> inside, the plugin blocks \u2014 even when no known provider\nis recognisable. A script can load anything when it runs, and the plugin\ncannot judge what. In case of doubt it does not allow it.<\/p>\n\n

        That is the only place where more is blocked on purpose than might be\nnecessary. A srcdoc<\/code> without outward references is left alone.<\/p><\/dd>\n

        Does the plugin work with caching plugins?<\/h3><\/dt>\n

        Yes, and that is measured rather than merely argued. The HTML served is\nidentical for every visitor; the decision about consent is made exclusively in\nthe browser.<\/p>\n\n

        Tested against a real page cache on Apache: a visitor without consent is\nserved exactly the page that was previously generated and cached for a\nconsenting visitor \u2014 and still loads no script that requires consent.<\/p>\n\n

        An upstream proxy cache (Varnish or Cloudflare, say) has not been measured. It\npasses on the same HTML, so the statement holds there too \u2014 but it is not\ndemonstrated for it.<\/p><\/dd>\n

        Which cookie does DT-PM Consent set itself, and who provides the plugin?<\/h3><\/dt>\n

        One cookie, named dt_consent<\/code>. It stores the visitor's consent decision - which\ncategories were accepted - together with a fingerprint of the configuration, so\nthat only the services consented to are loaded and the banner does not appear\nagain on every page. When the service or purpose list changes in substance, the\nfingerprint no longer matches and the banner appears again.<\/p>\n\n

        It is kept for 365 days by default; the period can be changed on the \"Banner\"\ntab. The plugin sets it in the visitor's browser and sends it to no one: there\nis no transfer to a third party and none to a third country.<\/p>\n\n

        DT-PM Consent is provided by DT PM GmbH, Forckenbeckstr. 10, 48431 Rheine, Germany.<\/p><\/dd>\n

        Can I extend the plugin from my own code?<\/h3><\/dt>\n

        Yes, and without touching its files. Four hooks are documented and will not\nchange their names:<\/p>\n\n

          \n
        • dt_consent_service_catalogue<\/code> (filter) adds your own service to the built-in\ncatalogue, so the plugin recognises it like any other.<\/li>\n
        • dt_consent_scan_report<\/code> (action) hands you every finished scan report, for\nyour own monitoring or ticket system.<\/li>\n
        • dt_consent_configuration_archived<\/code> (action) hands you every configuration\nthat went into the evidence archive, for your own records.<\/li>\n
        • dt_consent_banner_classes<\/code> (filter) adds a CSS class to the banner, so a\ntheme can style it without copying markup.<\/li>\n<\/ul>\n\n

          The content of the banner is deliberately not filterable: both buttons, the\npurposes and their order are what this software is measured against.<\/p><\/dd>\n

          How do I style the banner with my own CSS?<\/h3><\/dt>\n

          Add your rules to your theme or to a custom-CSS field. The banner uses the\nclasses dtc-banner<\/code> (the overlay), dtc-banner__inner<\/code> (the box) and\n dtc-button (both level-one buttons). The filter\n dt_consent_banner_classes adds a class of your own to the banner, so you\ncan target your site without copying any markup.<\/p>\n\n

          Since 1.0.10 a plain class is no longer enough.<\/strong> The plugin's own rules\nrepeat their class four times, so<\/p>\n\n

          .dtc-button { background: #123456; }\n<\/code><\/pre>\n\n
          will not take effect. Use the same specificity:<\/p>\n\n
          .dtc-button.dtc-button.dtc-button.dtc-button { background: #123456; }\n<\/code><\/pre>\n\n
          The reason is measured, not theoretical: some themes raise the specificity of\ntheir own button rules above a plain class, and on those themes none of this\nplugin's buttons showed the colour the plugin sets - not the two level-one\nbuttons, not the save button, not the revoke entry that sits on every page.\nRepeating the class is what wins against that pattern. It is not a guarantee\nagainst every theme, and a theme using !important<\/code> still wins.<\/p>\n\n
          Whatever you change, change it for both level-one buttons.<\/strong> \"Accept all\"\nand \"Reject all\" share one class on purpose. Supervisory authorities treat a\nprominent accept button next to a quiet reject button as unlawful influence\n(DSK guidance, para. 60), and this plugin is built so that there is no place\nwhere only one of the two can be coloured. A rule that singles one of them\nout defeats that, and it is your installation that has to answer for it.<\/p>\n\n
          The save button (dtc-button--quiet<\/code>) is deliberately quieter. It confirms a\nselection you have already made; it is not a third alternative to accepting\nand rejecting, so the equivalence requirement does not apply to it.<\/p><\/dd>\n
          Why does the cookie declaration name DT PM GmbH?<\/h3><\/dt>\n
          Because the plugin sets the dt_consent<\/code> cookie on your site, and a visitor is\nentitled to know who is behind a cookie (Art. 13 GDPR). The cookie declaration\ntherefore lists DT-PM Consent like any other service, and the provider line names\nthe company that provides the plugin.<\/p>\n\n
          This is information about a cookie, not a credit. It is plain text: no link, no\nlogo, no promotional wording. It appears only where you place the cookie\ndeclaration (the [dt_consent_cookies]<\/code> shortcode or the block) - never in the\nbanner, the footer or anywhere else on your pages. It disappears when the\nplugin is deactivated, because then the cookie is no longer set.<\/p><\/dd>\n\n<\/dl>\n\n\n
          1.1.4<\/h4>\n\n
          Housekeeping after the first round of the WordPress.org review.<\/strong> Nothing you\nhave configured is touched: your services, texts and record archive stay as\nthey are.<\/p>\n\n
            \n
          • A snippet of your own can no longer break the page.<\/strong> Where a necessary\nservice carries its own snippet, a closing script tag inside it - which\nseveral providers' installation instructions include - used to end the tag\nearly, and the rest of it landed in the page as markup, banner included. The\nsnippet is now written so that cannot happen, on every WordPress version this\nplugin supports.<\/li>\n
          • The check for third-party fonts now looks in the right places.<\/strong> Where a\nsite keeps its plugins or themes outside wp-content<\/code>, style files there were\nnot examined at all, and the check reported nothing found. It now resolves\nthose directories too.<\/li>\n
          • The page address the collector records is cleaned before it is stored, and\nthe service fields that take one entry per line - script handles, script and\niframe hosts - now drop an entry that cannot be one instead of storing it.<\/li>\n
          • Two internal names got a longer prefix so they cannot collide with another\nplugin's. One of them is a cache; it refills by itself.<\/li>\n<\/ul>\n\n
            1.1.3<\/h4>\n\n
              \n
            • Housekeeping for the WordPress.org listing.<\/strong> The plugin's text domain is\nnow dt-pm-consent<\/code>, matching the slug the directory assigned. Nothing about\nthe plugin's behaviour changes, and nothing you have configured is touched:\nyour services, texts and record archive are stored under names that stay as\nthey are, and the [dt_consent_cookies]<\/code> shortcode and the cookie\ndeclaration block keep working in the pages you already published.<\/li>\n<\/ul>\n\n
              1.1.2<\/h4>\n\n
                \n
              • The overview no longer sends you to a page where there is nothing to\ndo.<\/strong> It said \"14 findings from the last scan are not assigned to any\nservice\" and offered \"Go to setup\"; the setup then said \"Nothing open:\nevery finding assigned\" - and finishing it led back to the overview with\nthe same 14. The overview was counting from the scan report, which is\nfrozen at the moment of the scan, while the setup counts today's state.\nAssigning a finding changes the second and not the first, so the number\nonly ever cleared by running another scan. Both screens now read the same\nsource: what is open today. The scan report still says what a scan found -\nit no longer says what is still open.<\/li>\n
              • A third party that blocking cannot reach is now named on its own, as a\nnote.<\/strong> It used to be counted into the number above, which sent you off to\nassign it - the one thing that does not help: assigned, it would stand in\nthe banner as if it were handled and keep loading. It is not a task either,\nbecause the fix is to change how the script is loaded, and that is often\nnot yours to do. So the overview says it, the scan page lists it per host,\nand neither pretends you have something to tick off.<\/li>\n<\/ul>\n\n
                1.1.1<\/h4>\n\n
                  \n
                • The destination-country field no longer shows an internal marker.<\/strong> Where\na provider says nothing about transfers, the field was printing\n  keine-angabe - a German word on an English screen, and a token that means\nnothing to a reader. It is empty now, and the placeholder says what belongs\nthere. The banner and the record export already put it into a sentence; only\nthis field did not. Nothing about blocking changes, and no entry of yours is\naltered.<\/li>\n
                • The same field is wide enough for its own hint now. It stood at the\nbrowser's default of about twenty characters, so \"Destination country, e.g.\nUSA\" was cut off - which nobody saw while the field was never empty.<\/li>\n<\/ul>\n\n
                  Older entries of this changelog have moved to changelog.txt<\/code> in the plugin\nfolder.<\/p>","raw_excerpt":"GDPR and ePrivacy consent management for cookies and third-party services. Blocks scripts that require consent before they are executed.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/398360","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=398360"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/dtpm"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=398360"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=398360"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=398360"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=398360"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=398360"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=398360"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}