arrigoo/wp-block-control
最新稳定版本：1.2.5
Composer 安装命令：
composer require arrigoo/wp-block-control
包简介
Control display of your blocks based on segments from the Arrigoo CDP.
README 文档
README
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
What this plugin does
A WordPress plugin that adds a "CDP Segment control" panel to every Gutenberg block's inspector. Editors pick segments (from the Arrigoo CDP) that the block should be shown to or hidden from. All blocks still render server-side; a frontend script reads the visitor's segments from the Arrigoo CDP and either reveals or removes the marked blocks in the DOM.
Commands
npm run build— Builds both JS entry points with@wordpress/scripts(webpack) and copiessrc/bundle.jstobuild/bundle.js. The copy step is required becausebundle.jsis a pre-built CDP SDK artifact, not a webpack entry — webpack would otherwise overwrite or skip it.npm start—wp-scripts start(watch mode forsrc/index.jsandsrc/frontend-loader.js). Note: this does not copybundle.js; runnpm run buildonce to seed it.composer install— Installs thearrigoo/cdp-php-sdkdependency and sets up the PSR-4 autoloader for theArrigoo\WpCdpBlockControl\namespace. The plugin relies on a Composer autoloader being loaded by WordPress (see README.md — the deliciousbrains "WP in git" pattern).
No test suite or linter is configured.
Architecture
Two-stage rendering (the core trick)
- Server: every block with selected segments is rendered with a
data-segments="seg1 seg2 !seg3"attribute. A<style>*[data-segments]{display:none}</style>block in<head>hides them all by default (EndUser.php:34-38). - Client: frontend-loader.js waits for the CDP bundle to emit
ao_loaded, reads the visitor's segment list fromwindow.argo.get('s')(falling back to the base64-encodedarrigoocdpsessionStorage entry), then either unhides each block (display: block) or removes it from the DOM.
The ! prefix means "hide from this segment". The literal segment unknown matches visitors the CDP has not recognized.
PHP side (src_php/, namespace Arrigoo\WpCdpBlockControl\)
Hooks are registered in index.php. Three classes, all static:
- BlockControl — registers the editor JS bundle (
build/index.js) and injectswindow.arrigooCdpSegmentsviawp_add_inline_script. Adds aselectedSegmentsarray attribute to every block viaregister_block_type_args. Owns the CDP segment fetch (cached 5 min in theARRIGOO_CDPoption). - EndUser — emits the frontend
<style>,window.arrigooConfig, and the loader script inwp_head. - AdminSettings — Settings API page under Settings → Arrigoo CDP. Stores credentials and cookie-consent prefs in option
arrigoo_cdp_config. Clearing settings deletes the segment cache.
Config resolution order (see AdminSettings::get_config_value): WP option → env var → PHP constant. Only api_url, api_user, api_secret participate in the fallback chain — they map to CDP_API_URL / CDP_USER / CDP_API_KEY. Cookie/frontend flags only come from the option.
JS side (src/)
Three files, two webpack entries (see webpack.config.js):
src/index.js(entryindex) — Editor-side. ThreeaddFiltercalls:editor.BlockEditadds the<InspectorControls>panel with twoFormTokenFields ("Only show to" and "Hide from"). The UI shows segment titles to editors but stores sys_titles inselectedSegments; hide entries are stored with a!prefix.blocks.registerBlockTypemirrors the PHP attribute registration so the editor knows aboutselectedSegments.blocks.getSaveContent.extraPropswritesdata-segments(space-joined) onto the saved block markup. This is the contract the frontend loader reads.
src/frontend-loader.js(entryfrontend-loader) — Vanilla IIFE that wires up consent providers (none/cookieinformation/cookiebot) and gatesloadArrigooScript()(which injectsbundleUrl) on the chosen category. WhenfrontendScriptEnabledis false under providernone, the loader still runsprocessBlocks(after a 300ms grace period) so segment markup is resolved even if the CDP script is loaded elsewhere (e.g., a tag manager).src/bundle.js— Minified Arrigoo CDP SDK, copied verbatim tobuild/. Not webpack-compiled. Exposeswindow.argoand dispatchesao_loaded/ao_recognized. Treat as a vendored binary — don't edit by hand.
Data flow at a glance
Editor: CDP API → BlockControl::get_segments (cached) → window.arrigooCdpSegments → FormTokenField
Save: selectedSegments attr → data-segments="..." on block HTML
Render: wp_head emits hide-all CSS + frontend-loader.js
Frontend: consent gate → bundle.js → window.argo.get('s') → show/remove [data-segments] elements
Things to know when editing
- The
build/directory is committed. Runnpm run buildand commit the output when changing JS — WordPress loads frombuild/, notsrc/. - Don't refactor
bundle.js. It's the externally-built CDP SDK. Replace it as a whole if it needs updating. - The PHP attribute registration and the JS attribute registration must stay in sync (BlockControl.php:41-50 and src/index.js:199-216). The server-side filter is what makes the attribute survive REST/render; the client-side one is what makes it available in the editor UI.
- Cache invalidation:
AdminSettings::sanitize_settingsdeletesARRIGOO_CDPon save. If you change how segments are fetched/shaped, also clear that option or bump the cache key, or stale data will hide for 5 minutes. - Segment string convention: bare
sys_title= show;!sys_title= hide;unknown/!unknowntarget visitors with no CDP profile. The show/hide split is enforced in the editor (selecting a segment on one side removes it from the other) but the frontend just applies whatever it reads fromdata-segments.
统计信息
- 总下载量： 15
- 月度下载量： 0
- 日度下载量： 0
- 收藏数： 2
- 点击次数： 8
- 依赖项目数： 0
- 推荐数： 0
其他信息
- 授权协议： MIT
- 更新时间： 2025-11-07