Digitizer Pro Tools

One toolbox plugin by Digitizer. Modules: multilingual cookie-consent banner, one-click post duplication, auto-update email silencing.

Description

Digitizer Pro Tools is a modular plugin that consolidates the tools Digitizers deploys on client sites. Modules can be toggled on and off from the Modules dashboard.

Every module ships disabled. Activating the plugin adds its Modules screen and does nothing else - each module below stays dormant until you switch it on, so a site runs exactly what you chose for it. On a new site, Onboarding is usually the first one you turn on.

Module: Onboarding

Brings a new site up to the Digitizer baseline in one pass:

• Checklist of the baseline - Hello Elementor with the Hello Digitizer child theme, and twelve plugins - showing what this site already has
• Untick anything a given client does not need, then install the rest
• Only the child theme and Elementor are switched on. Everything else is installed and left inactive, so you decide per client what actually runs
• Installs from WordPress.org, and from the public GitHub repositories for Hello Digitizer, Elementor MCP and MCP Adapter
• Optionally turns on WordPress's automatic updates for the items it installed, and for Digitizer Pro Tools itself
• Reports updates for the baseline's GitHub items - Hello Digitizer, Elementor MCP and MCP Adapter - which are not in the WordPress.org directory and are installed inactive, so nothing else on the site would ever check them. Switch the module off and those offers stop with it
• Optionally removes the unused default themes, always keeping the newest one and the theme this WordPress is configured to fall back to if the active theme ever breaks. The active theme, any theme another theme depends on, and anything that is not actually one of WordPress's own themes are never removed. Not offered on a multisite network, where one directory of themes is shared by every site
• Nothing already installed is updated, downgraded or reconfigured
• Safe to run again: the second pass finds everything in place and does nothing
• One request per item, so a slow download cannot time out the whole run, and each row reports what happened
• The theme is switched only while the site is still on a WordPress default - a site with a live custom theme keeps it, and the summary says so
• The list is fixed in code. There is no field for pasting a plugin URL

Module: Update Policy

Decides when this site takes a major WordPress release:

• A major release is held back for a set number of days - 30 by default - after this site is first offered it, so the plugins and themes running here have time to catch up with it
• Security and maintenance releases are never held. They are what keeps a site safe, WordPress installs them on its own, and this module does not look at them
• A held release is removed from the update offer rather than merely discouraged: a warning does not stop someone pressing the button, and a button that is not there does
• The Updates screen says which release is held, when this site first saw it, and when the hold ends - a hold nobody can see is indistinguishable from a site whose updates are broken
• The hold can be lifted from that notice at any time, permanently for that release line
• The window is counted from the day this site first saw the release, not from the day it was published: nothing is asked of any external service, and a site checks for updates twice a day
• Nothing is ever installed automatically. When the window passes the release is simply offered again, and updating stays a deliberate act
• On a multisite network the policy is the main site's, since the WordPress it governs belongs to the network
• Also available as a standalone plugin, Digitizer Update Hold, for sites that do not run Digitizer Pro Tools. When that plugin is active this module stands down and says so

Module: REST Bridge

Puts this site's own custom fields on the REST API (disabled by default; enable it on the Modules screen):

• Fields are discovered from the definitions JetEngine already stores - meta boxes and their fields, including repeaters with their sub-fields - so a field added in JetEngine appears in the API without anyone writing code for it
• Discovered fields are added to the standard wp/v2 posts, pages and terms endpoints, reading and writing exactly like a post title or any other core field
• Discovered fields are readable only by someone logged in (with context=edit), because this module cannot tell which of a site's fields were meant for the public - a field holding internal notes or a client's details is not put on an anonymous request. The fields the old plugin already published - reading_time, the author bio fields and the FAQ - stay public, and a site can make any other field public with the dpt_rb_field_context filter
• Reading and writing a field goes through the same per-field permission check WordPress applies to custom fields of its own, which the posts and terms endpoints do not apply on their own: a key the site has restricted with an auth_postmeta or auth_termmeta filter is neither readable nor writable here either, and a key WordPress protects outright - one whose name begins with an underscore - is not put on the API at all, since nobody, administrators included, would be allowed to use it. The fields the old plugin published stay readable without logging in, exactly as they were
• A repeater keeps the columns this module does not understand - an icon, a gallery, a nested repeater - exactly as they were: read the field, change one value, write the whole list back, and nothing else in the row is lost. A repeater with no column this module understands at all is left off the API rather than exposed as an empty shape, and the info endpoint says so
• A field whose name is one the REST API already uses on that endpoint - title, excerpt, meta, or the name of a taxonomy attached to the post type - is never registered over it: that would replace the real property rather than sit beside it, and would break the endpoint for everything else reading it, the block editor included. The field is exposed under another name instead, and never dropped - the FAQ section title, whose meta key really is title, is jet_faqtitle, the name the old plugin gave it, and anything else takes a jet prefix. The info endpoint names every field this happened to and the name it answers to now
• Legacy field names from the standalone Digitizer API Extensions plugin - reading_time, the author bio fields, the FAQ section title as jet_faq_title, and the qna FAQ repeater under its old name jet_qna - keep working wherever a discovered field does not already claim that name, including a fallback for jet_qna on a site whose JetEngine definitions this module cannot see
• Exposes Rank Math's SEO fields on posts and pages - title and meta description overrides, focus keyword, robots directives, canonical URL, primary category, SEO score, and the Open Graph and Twitter card fields - only while Rank Math is active
• Elementor endpoints (GET/POST /digitizer/v1/elementor/{post_id}) for reading and merging widget settings by widget ID, without touching the rest of the page's layout. A page is only editable here if Elementor itself would let this user edit it - the same rules the editor applies, including a role excluded under Elementor > Settings > Advanced, a page in the trash, and a post type Elementor was not switched on for. After a save the page's own generated CSS and cached HTML are cleared and its plain-text content is rewritten, exactly as saving in Elementor does, so search results, excerpts and RSS reflect the edit
• One limitation worth knowing: rewriting that plain-text content needs Elementor's own rendering, so on a site where Elementor is deactivated a page edited through these endpoints keeps its layout change but its old search text. Nothing is lost - opening and saving the page in Elementor rewrites it - and this module will not guess at a text that would differ from the one the editor produces
• An /digitizer/v1/info endpoint reports exactly what was discovered, registered and skipped on this site, and why - each registered field with the schema it was given, so an automation can see what a field will accept before it writes to it. Restricted to users who can edit posts
• Two notes for anything reading and writing these fields: a number field that was never saved reads back as 0 rather than as empty, so a read-modify-write cycle stores a 0 where there was nothing; and the Elementor endpoint saves widget settings as Elementor itself does, without stripping HTML, so anyone who may edit a page may put markup in it - the same as editing that page in Elementor
• Replaces the standalone Digitizer API Extensions plugin and stands down while that plugin is active, since both would register the same fields and the same routes

Module: Cookie Banner

A multilingual cookie-consent banner:

• Texts per language (Hebrew and English seeded out of the box; add any language by code, e.g. ru or pt_BR)
• Language auto-selected by the current page locale - works with WPML, Polylang, TranslatePress and any plugin that switches the WordPress locale per page
• Automatic RTL/LTR direction per displayed language
• 5 banner positions (bottom/top bar, centered modal, corners), 5 entry animations
• 4 cookie categories (essential, functional, analytics, marketing) with per-category script blocking until consent (GA, GTM, Facebook Pixel, any snippet)
• Floating "manage cookies" button so visitors can change preferences at any time
• Rich design controls: colors, background image with overlay, typography with shadows, per-button styling, border, page overlay
• Separate box width for desktop and mobile - a narrow corner card on desktop, full-width on phones
• Font control: inherit the site font (default), follow Elementor's primary global font, or set a custom font stack
• Cache-proof: banner renders hidden and an inline head precheck decides visibility, so page caches / CDNs never show it to visitors who already answered
• Consent stored in a cookie and localStorage (cross-healing), with correct cookie domain on double-suffix TLDs (.co.il, .co.uk, .com.au)
• Consent version field - bump it to re-prompt all visitors (popular page caches are purged automatically on change)
• Consent lifetime in days, optional show delay, optional auto-accept on scroll
• Admin-only live preview (?dpt_cb_preview=1) and debug panel (?dpt_debug=1)
• JS API window.DPTCB (open/close/getConsent/acceptAll/rejectAll) and a dpt:consent event
• WP Rocket and Cloudflare Rocket Loader compatibility built in

Module: Duplicate Post

One-click duplication of posts, pages and custom post types:

• "Duplicate" and "Duplicate & Edit" links in the post list rows, plus a bulk action
• Copies are created as drafts with a configurable title suffix
• Copies custom fields - including page-builder data such as Elementor's - taxonomies, featured image, page template, menu order and parent
• Configurable per post type; respects each post type's edit capabilities

Module: Update Emails

Silences the routine "site updated" notifications WordPress emails after automatic updates:

• Separate toggles for plugin, theme and core auto-update emails
• Core updates: only SUCCESS notifications are silenced - failure and critical emails always go out
• Neutralizes the well-known legacy functions.php snippets on these hooks (blanket __return_false and the WPBeginner-style core callbacks), so they cannot hide failure emails or fatal the cron - still, remove those snippets once the module is active

Module: Disable Comments

Turns comments off - dynamically (disabled by default; enable it on the Modules screen):

• Everywhere, or only on selected post types
• Closes comment/trackback forms, hides existing comments, strips editor support
• Removes the admin comments UI (menu, admin-bar bubble, dashboard widget, edit-comments screen) - only when comments are disabled for every relevant post type
• WooCommerce product reviews are comments under the hood - a dedicated toggle (on by default) keeps them working

Module: Hide Login

Moves the login page to a custom URL (disabled by default; enable it on the Modules screen):

• Custom login slug (default: /login), configurable per site
• wp-login.php returns the theme's real 404 page; logged-out wp-admin requests land on a 404 as well
• All generated login/logout/lost-password/registration URLs are rewritten automatically, including the links in password-reset emails
• Post-password forms, admin-ajax, admin-post and cron keep working
• Reserved WordPress slugs are rejected to avoid lockouts

Module: User Role Editor

Full control over what every role can do (disabled by default; enable it on the Modules screen):

• Per-role capability matrix - grant or revoke any capability with a live "select all" toggle
• Add a new role, optionally cloning the capabilities of an existing one
• Delete a role and move its users to another role in one step
• Register custom capabilities and grant them to any roles
• Gated by a dedicated dpt_manage_roles capability (granted to administrators), so a delegated manage_options account cannot open the editor and escalate its own privileges
• Lockout-proof: the administrator role always keeps the capabilities needed to manage the site, and you can never strip your own access
• Protected roles (administrator) and the default new-user role cannot be deleted

Module: Content Control

Restrict who can see what (disabled by default; enable it on the Modules screen):

• Per-page/post restriction metabox: everyone, logged-in users, logged-out visitors only, or specific roles - with a custom restriction message
• Whole-site protection: require login (or specific roles) for the entire site, redirecting to the login form, a page, or showing a message; exempt individual pages by ID
• Per-menu-item visibility so navigation entries appear only to the right audience (descendants of a hidden item are hidden too)
• [dpt_restrict role="editor,author"]...[/dpt_restrict] shortcode to gate partial content (works in the block editor and Elementor)
• Restricted content is replaced in listings, single views, feeds and the REST API - not just hidden with CSS
• Administrators always retain access so they cannot lock themselves out

Module: Code Highlighter

Syntax-highlight code on the front end - dependency-free, no external CDN (disabled by default; enable it on the Modules screen):

• "Code Highlighter" block for the block editor
• [dpt_code lang="php"]…[/dpt_code] shortcode (works in the classic editor and Elementor)
• Optional automatic highlighting of every existing <pre><code class="language-…"> block
• Elementor "Code Highlighter" widget when Elementor is active
• Languages: PHP, JavaScript, CSS, HTML/XML, SQL, Bash, Python, JSON (and plain text)
• Light, dark and auto themes (auto follows the visitor's colour scheme), optional line numbers and a copy button
• Code is always HTML-escaped and highlighted client-side from the escaped text, so nothing in a snippet can inject markup or scripts
• Migration-friendly: code already saved with data-enlighter-language attributes or EnlighterJSRAW classes - the markup format of the standalone Enlighter plugin - is recognised and highlighted without editing the post. Its shortcode tags are not claimed unless you ask: [enlighter] is enabled with the dpt_en_legacy_shortcode filter and stands down while that plugin is active and already owns the tag, and per-language tags such as [php]/[js] with dpt_en_language_shortcodes. The two are designed to coexist

Module: Site Tweaks

Small site-wide tweaks that replace assorted functions.php snippets - each an independent toggle (disabled by default; enable it on the Modules screen):

• HTTP security headers on front-end responses: X-Frame-Options (SAMEORIGIN), X-Content-Type-Options (nosniff), an optional legacy X-XSS-Protection, and optional HSTS (Strict-Transport-Security) sent over HTTPS only, with an extra opt-in for includeSubDomains/preload
• Sanitised SVG uploads: every SVG is cleaned on upload (scripts, event handlers, javascript: URLs, external references and entity/DOCTYPE payloads are stripped), and uploads are limited to users with a configurable capability (administrators by default)
• Hide the WordPress version: removes the generator meta tag/RSS marker and the ?ver= core version from asset URLs, while keeping plugin/theme asset versions so cache-busting still works
• Elementor helpers (only when Elementor is active): disable Elementor's Google Fonts, validate phone numbers in Elementor Pro tel form fields, and drop Elementor's icon fonts (Font Awesome and eicons) on a design that uses no icons - a page that does use one shows an empty square, so check first
• Lock Elementor pages to the Elementor editor: users without the bypass capability (manage_options by default, filterable) are sent from the native WordPress editor straight to Elementor for pages built with Elementor, edit links point there directly, and the "Back to WordPress Editor" switch - the button that makes a page render its Gutenberg content instead of the Elementor layout - is hidden from them. Administrators are never affected, trash and the Elementor editor itself always pass through, and the whole thing is a no-op while Elementor is inactive
• Front-end weight: drop the block editor stylesheets from public pages on a site built entirely in Elementor (the editor itself is unaffected, and any page that does contain a block loses its styling), and switch the block editor off for posts and pages so there is one way to edit content rather than two

Module: WooCommerce Checkout

Checkout-field helpers for WooCommerce (disabled by default; enable it on the Modules screen):

• Email typo suggestions: when a customer types an email whose domain looks like a misspelling of a known provider (Gmail, Outlook, Walla, etc.), a one-click correction is offered. The provider list is editable, and matching uses edit-distance so only genuine near-misses are suggested
• Israeli phone-number validation: accepts numbers starting with 05 (10 digits), 972 (12) or +972 (13), with a live in-browser hint and an authoritative server-side check that blocks checkout on an invalid number
• All suggestion/error text is inserted as plain text, so nothing typed into the fields can inject markup

Module: Rank Math Breadcrumbs

Adds extra crumbs to the Rank Math breadcrumb trail (disabled by default; enable it on the Modules screen):

• A "Blog" crumb after Home on single posts and blog archives (category, tag, author, date)
• A "Shop" crumb after Home on WooCommerce product pages
• URLs and labels are auto-detected - the Blog crumb from the posts page set under Settings > Reading, the Shop crumb from the WooCommerce shop page - and each can be overridden manually
• A crumb is not added if the same URL is already present in the trail
• Applies only when Rank Math is active

Module: Resend Mail

Delivers all site email through the Resend API (disabled by default; enable it on the Modules screen):

• Routes every wp_mail() call - order emails, form notifications, password resets - through Resend's HTTP API via the pre_wp_mail short-circuit; no SMTP credentials on the server
• Verified-domain sender with an optional "force sender" mode (on by default), so plugins cannot send from unverified addresses that Resend would reject
• Full wp_mail compatibility: To/Cc/Bcc and Reply-To headers, HTML and plain-text content types, custom headers and file attachments
• Send log (last 100 emails) with per-email delivery status - delivered, bounced, opened, marked as spam - fed by a signed Resend webhook (Svix signature verification, replay protection)
• Automatic fallback to the default WordPress mailer when the API errors, so emails are never silently dropped
• Test-email button, masked API key storage with an optional DPT_RESEND_API_KEY wp-config.php constant override

Module: Name Your Price

Let customers set their own price on chosen WooCommerce products (disabled by default; enable it on the Modules screen):

• Enable per product on the product edit screen (Product data > General), with optional minimum, maximum, suggested and default (pre-filled) prices
• A price input replaces the fixed price on the product page, with an optional allowed-range hint
• The price is enforced on the server: an out-of-range or invalid price is rejected at add-to-cart, re-validated when the cart line is created, and re-clamped to the range at total calculation - a tampered client value can never bypass the limits
• Configurable field label; applies only when WooCommerce is active
• Replaces the WPC "Name Your Price" plugin

Admin interface is in English with a full Hebrew translation.

Module: Checkout Field Editor

Tailor the WooCommerce (classic/shortcode) checkout without a snippet (disabled by default; enable it on the Modules screen):

• Show, hide, require and reorder the standard Company, Address line 2, Phone and Order notes fields
• Add up to 10 custom fields - text, dropdown or checkbox - in the billing, shipping or additional-info section
• Custom values are validated on the server (a dropdown value outside the configured options is rejected), saved to the order, and shown on the admin order screen and in order emails
• Covers the common checkout-field edits without a dedicated field-editor plugin; applies only when WooCommerce is active

Admin interface is in English with a full Hebrew translation.

Module: Embed

Embed the sources WordPress core does not oEmbed on its own, with the [dpt_embed] shortcode (disabled by default; enable it on the Modules screen):

• PDF files and Google Docs / Sheets / Slides / Forms / Drive links in a responsive frame
• Per-shortcode aspect ratio or fixed pixel height, optional accessible title, optional lazy-loading
• Only http(s) PDF URLs and docs.google.com / drive.google.com links are embedded; anything else is left to core oEmbed
• Usage: [dpt_embed url="https://example.com/file.pdf" ratio="16:9"]

Module: Copy URL

A copy-this-page-address widget as one shortcode (disabled by default; enable it on the Modules screen):

• [digitizer_copy_url] renders a read-only field carrying the current page address and a one-click copy button - clicking anywhere on the block copies, the button confirms, and the labels are set per shortcode (label_copy, label_copied)
• Copies through the browser clipboard API with a fallback for contexts that lack it; styling inherits the theme's font and colours and is overridable through CSS custom properties
• [digitizer_geturl] prints the current page address on its own, for use as a dynamic value (an Elementor form field's default, for instance). The address is built from the site's canonical home URL - correct behind a reverse proxy - decoded so a Hebrew slug stays readable, with markup-breaking characters stripped
• Replaces the functions.php snippet and the three-widget Elementor construction (form, absolutely positioned heading, raw HTML script) this used to take

Admin interface is in English with a full Hebrew translation.

External services

This plugin is self-contained: every script, style and font it ships is bundled locally, so no module loads assets from a CDN or a font service. There is no telemetry and no usage tracking. The outside connections it can make are listed below - the first two are made by your server, the third by the visitor's browser and only for content you choose to embed.

Resend (email delivery)

The Resend Mail module - disabled by default - delivers your site's email through the Resend API instead of the server's mail function. It is only ever contacted after you enable the module and enter an API key.

• Service: Resend, https://resend.com
• Endpoint: https://api.resend.com/emails
• When: on every email WordPress sends (wp_mail), while the module is enabled and configured
• Data sent: the sender and recipient addresses (including cc/bcc and reply-to), the subject, the message body, any attachments, any custom headers the sending code added to the message, and your API key for authentication. In other words, the complete message - whatever a plugin, theme or WordPress itself puts in an email passes through Resend.
• Data received: delivery status events (delivered, bounced, opened, clicked) sent back to this site's webhook endpoint, which are stored in the module's local send log
• Terms of Service: https://resend.com/legal/terms-of-service
• Privacy Policy: https://resend.com/legal/privacy-policy

The module keeps a local send log (recipient, subject, status - not the message body) of the most recent messages. It can be switched off in the module settings, and it is deleted when the plugin is uninstalled.

GitHub (update checks, and the Onboarding module)

Two things reach GitHub, both only from your server and never from a visitor's browser.

This plugin can update itself from its public GitHub repository, periodically asking for the latest published release.

The Onboarding module additionally installs three items from public GitHub repositories - the Hello Digitizer child theme, Elementor MCP and MCP Adapter. It asks for each repository's latest release and then downloads the archive. Installing happens only when an administrator opens the Onboarding screen and presses its button.

While that module is enabled it also keeps those three items' update information current, asking each repository for its latest release while WordPress runs one of its own update checks, and answering from that cache in between. This is what lets WordPress offer them updates at all: they are not in the WordPress.org directory, and the wizard leaves most of them inactive, so their own code cannot check for them. Nothing is looked up while a page is merely being displayed, to the admin or to a visitor: those requests use what is already cached or report nothing.

• Service: GitHub, https://github.com
• Endpoints: https://api.github.com/repos/Digitizers/digitizer-pro-tools/releases for updates; https://api.github.com/repos/{owner}/{repo}/releases/latest for each onboarding item, followed by the archive download it points to (codeload.github.com, objects.githubusercontent.com or release-assets.githubusercontent.com)
• When: updates during WordPress's normal update checks and when an administrator installs an offered update; onboarding installs only while a run is in progress; the baseline's update lookups only while WordPress performs an update check of its own, never on an ordinary page load. A lookup made for an install is cached for six hours; one made for the baseline's update information is asked again at every update check and kept for three days between them, so the gap between two checks never leaves it empty. A failed lookup is kept for fifteen minutes
• Data sent: nothing about the site, on any of these requests. No site URL, admin details or usage data - the plugin replaces WordPress's default user agent (which would otherwise include the site address) with just its own name and version, on the lookups and on the downloads alike. As with any HTTP request, GitHub sees the originating IP address.
• Terms of Service: https://docs.github.com/site-policy/github-terms/github-terms-of-service
• Privacy Policy: https://docs.github.com/site-policy/privacy-policies/github-privacy-statement

WordPress.org (Onboarding module)

The Onboarding module installs the rest of its list from the WordPress.org plugin and theme directories, using the same APIs the built-in "Add Plugin" screen uses.

• Service: WordPress.org, https://wordpress.org
• Endpoints: https://api.wordpress.org/plugins/info/1.2/ and https://api.wordpress.org/themes/info/1.2/, followed by the package download at https://downloads.wordpress.org
• When: only while an administrator is running the Onboarding wizard
• Data sent: the slug being installed, plus whatever WordPress itself attaches to its API requests. Nothing is added by this plugin
• Privacy Policy: https://wordpress.org/about/privacy/

Content you embed yourself (Embed module)

The Embed module - disabled by default - does not contact anything on its own. It is worth understanding, though, that the [dpt_embed] shortcode places the URL you give it in an iframe, so the visitor's browser loads that document directly from wherever it is hosted. Nothing is proxied through your site.

• When: whenever a page containing a [dpt_embed] shortcode is viewed
• Who: the visitor's browser, not your server
• Data disclosed to that host: at minimum the visitor's IP address, browser user agent and the referring page, plus any cookies that host has already set in the browser
• Typical hosts: Google (docs.google.com / drive.google.com) for Docs, Sheets, Slides, Forms and Drive previews - see https://policies.google.com/terms and https://policies.google.com/privacy - or whichever server hosts a PDF you link to

If your site shows a cookie or privacy notice, embedded documents are third-party content and normally belong in it.

Frequently Asked Questions

Do I have to use every module?

No. Modules are toggled independently from the Modules screen, so you can enable only what a given site needs.

Which modules are active right after activation?

None. Every module ships disabled, so activating the plugin changes nothing on the front end, nothing in the admin beyond its own Modules screen, and nothing for visitors.

Open Digitizer Pro Tools in the admin menu and switch on what this site needs. On a new site that usually means starting with Onboarding, which installs the standard theme and plugin set for you.

Updating an existing site does not change what it already has: a module you switched on stays on, and one you switched off stays off. The new default applies only to modules that site has never saved a choice for.

Does the plugin send any data anywhere?

There is no telemetry, no analytics and no "phone home": the plugin never collects information about your site or its visitors and sends it anywhere on its own initiative.

Data does leave, but only where a module's job is to send it, and only for the modules you switch on. Everything below is described in full under "External services" above:

• Resend Mail, if you enable it and enter an API key, sends your site's email through the Resend API - the complete message, including recipients, subject, body and attachments. That is what the module is for.
• Embed makes the visitor's browser load the document you embedded straight from its host, so that host sees the visitor. The request comes from the visitor, not from your server.
• Onboarding, while an administrator is running it, asks WordPress.org and GitHub for the packages it installs. While enabled, it also asks GitHub for the latest release of the three items it installs from there, so WordPress can offer them updates. Nothing about the site is sent.
• The update check asks GitHub for the latest release, on WordPress's normal schedule. Nothing about the site is sent.

Nothing else in the plugin makes an outbound request.

Does the cookie banner work with page caching?

Yes. The banner is rendered hidden and an inline head precheck decides whether to show it, so cached pages and CDNs never display it to visitors who already answered. Consented third-party tags are injected client-side rather than baked into cached HTML.

Which languages does the admin support?

The admin interface is English with a complete Hebrew translation. The cookie banner texts themselves can be set for any number of languages.

Installation

1. Upload the plugin folder to /wp-content/plugins/
2. Activate the plugin through the Plugins menu
3. Open "Digitizer Pro Tools" in the admin menu. Every module ships disabled; switch on the ones this site needs
4. On a new site, switch on "Onboarding" first and run it to install the standard theme and plugin set. It activates the child theme and Elementor, and leaves the rest installed for you to enable per client
5. Configure each module you enabled from its own screen. For the Cookie Banner that means reviewing the texts per language and pasting your analytics/marketing snippets in the Scripts tab, then checking the site

Changelog

1.37.0

• Agent Log: a dpt_agent_log_record filter, applied to every entry once the channel and the application name are known and inside the site the change happened on, so a site can silence a writer it does not care about - a plugin that rewrites its own settings on load, say. Nothing is filtered by default: what is absent from this log is meant to mean it did not happen over an API.

1.36.0

• New module: Copy URL - the copy-this-page-address widget as one shortcode. [digitizer_copy_url] renders the field-plus-button block (clipboard API with a fallback, theme-inherited styling, per-shortcode labels), and [digitizer_geturl] keeps printing the bare address for dynamic values, exactly as the functions.php snippet did - existing pages keep working, new pages need one shortcode widget instead of three Elementor widgets and a script

1.35.0

• Site Tweaks: new "Lock Elementor pages to the Elementor editor" toggle (off by default). Users without the bypass capability are redirected from the native WordPress editor to Elementor for pages built with Elementor, edit links on the post lists and admin bar point straight there, and the "Back to WordPress Editor" switch is hidden from them - the switch that makes a page render its Gutenberg content instead of the Elementor layout. Administrators keep full access, trash/untrash and the Elementor editor itself are never redirected, and deactivating Elementor makes the toggle a harmless no-op. Filters: dpt_st_elementor_lock_bypass_cap, dpt_st_elementor_lock_enabled, dpt_st_elementor_lock_hide_switch

1.34.0

• Content Control learns the standalone plugin's global restrictions: rules that pick content (post types, selected IDs, taxonomies, archives, page templates - AND/OR with an optional group), an audience with any/match/exclude role matching, and a choice of what refusal looks like - redirect to login/home/a URL, replace with a page, or show the message, with per-archive hiding or replacement, forced hiding from search, and teaser excerpts above the notice. Classic widgets gain visibility controls, and the [dpt_restrict] shortcode gains excluded_roles, inline and class. Per-page settings, menu visibility and whole-site protection keep working exactly as before - and a per-page setting always wins over a global rule.

1.33.0

• Agent Log recognises the standalone plugin under its new name, Digitizer AI Agent Log. WordPress.org judged the first name too generic to list, so it was renamed before approval. Both names count as the standalone being present, because the earlier build is installed on machines it was tested on - and the notice on the Modules screen names whichever of the two that site actually has, so it never sends anyone looking for a plugin that is not there.

1.32.1

• REST Bridge preview: compatibility names are listed on their own instead of marking rows in the fields table. The module records those names without the targets they landed on, so a site's own field could be labelled as somebody else's - on the screen used to decide whether to deactivate a working plugin.

1.32.0

• REST Bridge: a preview screen that runs the module's discovery and registration without registering anything, and reports what it would put on the API. The fields are discovered from the site's own JetEngine definitions, so until something reads them nobody knows what the module will expose - and the module stands down while the plugin it replaces is active, so there was no way to look without first deactivating a plugin that works.

1.31.0

• Agent Log stands down when the standalone AI Agent Activity Log plugin is active, the way Update Policy already does for Digitizer Update Hold. Two logs of one thing, in two tables, from two sets of listeners on the same hooks, is worse than either alone.

1.30.0

• New module: Agent Log - records what automations changed on this site. Anything that arrived over the REST API, WP-Cron, WP-CLI or XML-RPC is recorded; a change made by a person in the admin is not recorded at all
• Each entry names who, what and when, and which fields were touched - never the values, so the log never becomes a second copy of the site's content
• Readable at /digitizer/v1/activity, which requires the capability to manage options, and on the module's own screen. Nothing erases it over the API
• Entries are kept for thirty days or twenty thousand rows, whichever comes first. Both limits are filterable, and switching the module off leaves the log where it is

1.29.0

• Update Policy now answers in Site Health as well as on the Updates screen and the dashboard. A hold looks exactly like a missing update, and Site Health is where someone goes when an update looks missing - so the entry says which release is held, when the site first saw it and when the hold ends, and says plainly when nothing is held at all
• Site Health also raises the one setting that contradicts the Modules screen: a hold of zero days, where the module is on and holding nothing back
• The hold's refusal of unattended major updates is now registered late, so it is heard over update plugins that deliberately hook the same decision last

1.28.0

• Update Policy: the standalone plugin was renamed to Digitizer Update Hold for the WordPress.org directory, and the module now recognises it under either name - a site that adopted it before the rename still stands the module down, rather than quietly running a second filter on the same update transient
• The stand-down note names the screen the installed build actually has, so it no longer sends anyone looking for a menu item that is not there

1.27.0

• New module: REST Bridge - puts this site's own custom fields on the REST API, discovered from the definitions JetEngine already stores, repeaters included. Also exposes Rank Math's SEO fields on posts and pages, and endpoints for reading and editing Elementor content
• The module replaces the standalone Digitizer API Extensions plugin and stands down while that plugin is active

1.26.0

• Update Policy stands down when the standalone Update Policy plugin is active. The module was extracted into a plugin of its own for the WordPress.org directory; a site running both would have two filters on one update transient and two screens saying the same thing, so the module now does nothing on such a site and says so on the Modules screen

1.25.0

• Site Tweaks: three more toggles, all off by default, taken from the snippets the Hello Digitizer child theme used to carry
• Do not load Elementor icon fonts - drops Font Awesome and eicons, four stylesheets a design without icons never needs. A design that does use one shows an empty square, so the switch says to check first
• Do not load block styles on the front end - a site built entirely in Elementor never uses them, and the editor is unaffected
• Edit in the classic editor - one way to edit content on a site built in Elementor rather than two

1.24.0

• New module: Update Policy - holds a major WordPress release back for a set number of days after this site is first offered it, so the plugins and themes running here have time to catch up with it. Disabled