Generated banner for Rp Source Wordpress
Generated logo for Rp Source Wordpress

Rp Source Wordpress

WixOfficialPublished by Wix

  • Skill
  • Tool integration
  • Automation and integrations
  • MIT
  • Medium risk
  • Has scripts

From the author

WordPress and WooCommerce source adapter: REST capture, auth, pagination, and read contract for codegen. Use when the source platform is WordPress or WooCommerce.
— the description by Wix

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides the necessary logic to interface with WordPress and WooCommerce REST APIs. It handles authentication, pagination, and schema discovery, ensuring that platform-specific quirks are managed consistently. It acts as a reference for discovery and code generation stages, allowing the broader migration workflow to remain platform-agnostic. The skill includes mechanisms for plugin detection, handling non-standard response envelopes, and managing authenticated versus public data access.

What it does

  • Samples WordPress and WooCommerce REST APIs to discover site structure and data schemas.
  • Manages authentication using WordPress Application Passwords and WooCommerce consumer keys.
  • Detects and profiles installed plugins to determine migration feasibility.
  • Provides a standardized transport layer for generated readers to extract data reliably.
  • Handles complex data scenarios like parent-child resource relationships and non-standard API response envelopes.
  • Identifies and flags data that requires manual user intervention, such as plugin-specific database tables.

When to use it

  • When the source platform for a migration is identified as WordPress or WooCommerce.
  • During the discovery phase to sample source data and generate a source profile.
  • During the code generation phase to create reliable data extractors.
  • When needing to determine if installed plugins can be migrated natively or require custom development.

Advantages

  • Centralizes platform-specific logic, preventing hardcoded dependencies in the main migration workflow.
  • Ensures consistent handling of authentication and rate-limiting across different migration projects.
  • Provides a deterministic approach to plugin coverage, reducing guesswork.
  • Supports robust data extraction by reusing a shared, tested transport module.

Usage examples

“Run the discovery process for a WordPress site.”
The agent executes the discovery script, samples the REST index, and generates a source profile including entity schemas and plugin inventory.
“How do I handle WooCommerce plugins that do not have a REST API?”
The agent identifies the plugin, flags it as requiring manual intervention or a database export, and records the status in the plugin inventory.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/wix/rp-source-wordpress-c7wf/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip rp-source-wordpress.zip -d .agents/skills

Documentation by Wix

rp-source-wordpress

WordPress / WooCommerce source adapter. Owns every WordPress-specific detail the platform-agnostic skills must not hardcode: how to capture the schema, how to read the data, auth models, pagination, and REST quirks.

When this skill is used

This is not a stage in the migration flow — it is a reference consulted by two stages:

  • rp-discovery consults the Capture section to sample the source and produce the canonical source-profile.md + source-schema.json.

  • rp-import-codegen consults the Read contract section to generate a reader that bulk-extracts WordPress data correctly (auth, pagination, wc/v3 vs wp/v2) into durable project-local files for the later import step.

rp-execute-import never consults this skill — by the time execution runs, the WordPress-specific knowledge is already baked into the generated reader code. Keeping the WordPress knowledge here is what lets the rest of the workflow stay platform-agnostic.

Platform identity

  • Source platform: WordPress (core REST wp/v2), optionally WooCommerce (wc/v3).

  • Detect by hitting <base-url>/wp-json/ — the REST index lists advertised namespaces.

  • Set "platform": "wordpress" (and note WooCommerce presence in sourceMeta) in the emitted source-schema.json.

Capture (discovery-time)

Sampling the source to learn its shape — not a bulk export.

The Wix domain knowledge base may be used as a classifier supplement during synthesis, but not as a sampling mandate. When a discovered WordPress/WooCommerce route matches a known alias, annotate the emitted entity with sourceMeta.candidateTargetRefs[]; do not turn that hint into a target decision here. Keep frontend, theme, runtime, admin, and transient routes skipped by default even if a knowledge entry exists for a related setup/config target.

Before capture, verify migrations/<project>/config/source.wordpress.env. Create it if missing with empty values:

WP_BASE_URL=
WP_USERNAME=
WP_APPLICATION_PASSWORD=
WP_MEDIA_URL_REWRITE_FROM=
WP_MEDIA_URL_REWRITE_TO=
WC_CONSUMER_KEY=
WC_CONSUMER_SECRET=

Before requesting any WordPress / WooCommerce credentials for a URL-based migration, ask the user which data scope they want:

  • public content only

  • also include private/authenticated data

This choice is mandatory and must be explicit. Do not ask for WP_USERNAME, WP_APPLICATION_PASSWORD, or WooCommerce keys until the user chooses also include private/authenticated data. After that choice, collect sensitive values through the secure Secrets Manager flow; do not ask the user to paste them into chat.

Key sensitivity is predefined and does not change at runtime. Requiredness is separate and may depend on the selected acquisition mode or source behavior.

KeySensitivityRequiredness
WP_BASE_URLnon-sensitiveRequired for URL-based capture
WP_USERNAMEsensitiveRequired for private/authenticated WordPress capture
WP_APPLICATION_PASSWORDsensitiveRequired for private/authenticated WordPress capture
WP_MEDIA_URL_REWRITE_FROMnon-sensitiveOptional
WP_MEDIA_URL_REWRITE_TOnon-sensitiveOptional
WC_CONSUMER_KEYsensitiveOptional unless WooCommerce rejects the WordPress Application Password for wc/v3 reads
WC_CONSUMER_SECRETsensitiveOptional unless WooCommerce rejects the WordPress Application Password for wc/v3 reads

Required for a complete WordPress/WooCommerce capture:

  • WP_BASE_URL

  • WP_USERNAME

  • WP_APPLICATION_PASSWORD

WC_CONSUMER_KEY and WC_CONSUMER_SECRET are optional when WooCommerce accepts the WordPress Application Password for wc/v3 reads; ask for them only if WooCommerce routes return 401/403 with the WordPress Application Password.

WP_MEDIA_URL_REWRITE_FROM and WP_MEDIA_URL_REWRITE_TO are optional. Use them when the WordPress API is reached through a public tunnel but media/file URLs inside records still point at localhost or another private origin. If they are blank, generated readers may rewrite localhost/private origins to WP_BASE_URL when WP_BASE_URL is public.

config/source.wordpress.env is a secret-bearing file once it may contain real values. Do not read it with whole-file commands that print its contents into tool output. Check only whether the file exists and whether each required key is present/blank/missing; when describing status, name keys only and never echo values.

  1. Run the deterministic capture script from this skill's directory (the folder containing this SKILL.md; see CONVENTIONS.md):

    node scripts/wp-discovery.js --env-file <migrations-root>/<project>/config/source.wordpress.env --out-dir <migrations-root>/<project>/data/wp-discovery

    It walks the REST index, runs one OPTIONS + a small GET sample per entity, and writes per-entity markdown (routes, schemas, sample records, record counts, relationships). --env-file is the preferred launch path for project-local credential-bearing config because it avoids shell sourcing of secret-bearing files. Pass direct auth options only when there is no project-local config yet. For long runs, pass --progress-log <path> and poll it per CONVENTIONS.md#progress-log-polling.

  2. If the user chose public content only, run unauthenticated and keep the scope framed as public-only. Do not pivot into asking for credentials unless the user changes scope.

  3. Credentials are required for a complete capture. Without auth, only published public content is reachable; drafts, WooCommerce (wc/v3), user PII, and private fields return 401/403, making their recordCount/inUse unreliable. The script flags this in its README under "Incomplete Capture (Authentication)" — do not treat an unauthenticated run as authoritative.

    Author identity is a specific casualty of public-only capture. Public /wp/v2/users lists only users who authored public posts and exposes no roles and no emails — admin vs editor vs contributor vs subscriber is indistinguishable. Roles/capabilities require context=edit (App Password with list_users) or a DB dump (wp_usermeta → wp_capabilities); WXR exports carry author login/email/display name but no roles either. Vanilla WP has no guest-byline concept (every byline is a user); plugin guest authors (Co-Authors Plus guest-author entities) are separate non-user records. Record author capture mode in the source profile — it determines the blog authorAttributionMode downstream (public-only → fallback/owner attribution; authenticated → per-author mapping: administrators → owner user-member, content roles → per-author members; subscribers/customers → Wix contacts by default — a contact is the no-login CRM person entity and Contacts V5 upserts in bulk — promote to full site members (MEM-01: 1/sec serial, re-registration) only when member-gated features are in scope. Every Wix member auto-creates its contact, so member-first ordering: never pre-create a contact for someone who will become a member. Note contacts cannot author blog posts or comments — bylines need members).

  4. Distinguish supported entities (advertised by the REST index) from used entities (those with recordCount > 0). Entities advertised but empty should be flagged, not mapped as if they hold data.

  5. Backend data scope. The capture script classifies REST routes before per-route OPTIONS or sample GET requests. By default it samples backend data routes and skips frontend, theme/editor, runtime session, admin dashboard, diagnostics, marketplace setup, and integration/helper APIs. It writes the skipped-route audit trail to skipped-routes.json.

    For WooCommerce, prefer canonical durable data APIs such as wc/v3 over duplicated wc/v2/wc/v1 routes for authenticated/private commerce reads. For public content only discovery, probe public Store API catalog routes before declaring commerce deferred: wc/store/v1/products and wc/store/v1/products/categories are in-scope public commerce data when present. Cart and checkout Store API routes remain out of scope as runtime session state.

  6. Plugin coverage runs automatically. Plugin handling is a deterministic pre-pass plus declarative profiles, not prose guesswork — see "Plugin coverage" below. The capture script writes plugin-inventory.json and plugin-coverage.json alongside the per-entity files. Never hand-map a plugin from memory; consult the profiles through scripts/plugin-knowledge.js.

  7. Localhost sources and media URLs. A source at localhost, 127.0.0.1, or another private-only host is valid for discovery and source reads from the user's machine. However, Wix Media import fetches files from the URL using Wix servers, so media URLs like http://localhost:8090/wp-content/uploads/... are not reachable by Wix during a live import. This is optional setup and, as far as we know today, only affects media import:

    • Prefer exposing the local source through a temporary public HTTPS tunnel such as ngrok before live media import.

    • Or explicitly skip/defer media import and continue with non-media entities.

    • If using ngrok on macOS:

      1. Install: brew install ngrok

      2. Add an authtoken from the ngrok dashboard: ngrok config add-authtoken "<YOUR_AUTHTOKEN>"

      3. Expose the local source port, for example: ngrok http 8090

      4. Set the source base URL to the HTTPS forwarding URL: export WP_BASE_URL=https://<id>.ngrok-free.app Record this in source-profile.md when the captured source URL is localhost, and note whether media will use the tunnel or be skipped/deferred.

The raw capture is evidence, not a hand-off artifact. rp-discovery synthesizes it into the canonical artifacts and records traceability pointers (rawDiscovery, per-entity rawFile).

Plugin coverage

A real WooCommerce site is mostly plugins. Handling them is deterministic and has its own knowledge base: plugins/ (profiles + no-migration-needed.json + README.md), read through scripts/plugin-knowledge.js, detected by scripts/wp-plugin-inventory.js.

Every installed plugin lands in exactly one of the four statuses, and every status produces a row the user sees. Nothing is silently ignored.

PopulationEvidenceResult
recognizeda profile matchednamed entities, declared read channels, Wix target refs; mapping confirmed
derivedno profile, data is REST-visiblederived from wp/v2/types + wp/v2/taxonomies, mapping proposed (CMS, or native on a domain-KB match)
named onlydetected, no read channelPending with its reason, resolved by the no-migration-needed list or at the review gate

A plugin therefore does not need a profile to migrate — it needs one to migrate natively.

Detection

Runs before route classification so profile-declared routes are already in scope. Signals, strongest first:

  1. GET /wp/v2/plugins — the authoritative installed list (plugin, status, name, version). Administrator credential required. On 401/403 the run continues and records pluginListAvailable: false; say so plainly rather than implying full coverage. Without it, installed-but-unprofiled plugins cannot be enumerated at all — this is the concrete argument for the authenticated acquisition mode.

  2. Declared routes present in the REST index.

  3. GET /wp/v2/types / GET /wp/v2/taxonomies entries matching a profile's restBases.

  4. Record payload keys from the samples — a second pass after sampling. This is not optional polish: several major WooCommerce extensions (Product Bundles, Composite Products, Product Add-Ons, ACF, Yoast) add no REST route at all and only widen wc/v3/products / wc/v3/orders payloads. Route-based discovery cannot see them.

  5. REST namespaces and public /wp-content/plugins/<slug>/ asset paths (low confidence, but they work with no credentials).

A plugin version below a profile's detect.minVersion is reported as api-below-min-version, not read as if the documented API were present.

Read channels

plugin-rest, core-cpt, core-embedded, core-meta, plugin-rest-child, export-file, db-only — see plugins/README.md. Two consequences worth stating to the user:

  • Unregistered post meta is invisible. WordPress exposes meta only when the plugin registered it with show_in_rest (and, for a CPT, declared custom-fields support). A plugin can keep its entire per-record state in postmeta and expose none of it. That data is reachable only from a WXR export or the database.

  • WXR cannot be fetched. Application Passwords authenticate the REST API and XML-RPC only, never wp-admin, so an export file is something the user produces and supplies. Treat export-file as a request to the user, never as a download.

  • Parent-scoped sub-resources (plugin-rest-child, fixed 2026-08-11). WooCommerce order notes (/wc/v3/orders/{id}/notes) and similar per-parent sub-collections cannot be listed on their own — the base classifier only samples flat collection routes (page/per_page shape). This is why a plugin that writes real data via $order->add_order_note(...) (e.g. Custom Payment Gateway for WooCommerce's payment-note field) used to report as pending · cannot-tell even though the data is real and REST-reachable in principle. plugin-rest-child fixes this: an entity declares route as a {parentId}-templated path (/wc/v3/orders/{parentId}/notes) plus parentRoute (the already-sampled collection that supplies real parent ids, e.g. /wc/v3/orders). Availability is a two-part presence check against the site's REST index — parentRoute is in scope, and the index advertises a route shaped like the template (WordPress's (?P<id>[\d]+)-style regex segments are normalized to {parentId} for the comparison, so the parameter's name never has to match). Presence alone does not confirm real data exists there: wp-discovery.js's sampleChildEntities runs a live, representative check afterward — it substitutes up to 3 already-sampled parent ids into the template and fetches each, purely to say "N of 3 sampled parents actually returned something," not to claim a full count. That result surfaces as a plain-language run note, never as a channel-status change: a small sample coming back empty does not mean the capability is absent, only that this sample did not confirm it. The infrastructure is built and tested (plugin-knowledge.js, wp-route-classifier.js's childRouteAdvertised, wp-plugin-detect.js's describeProfiledEntity, wp-discovery.js's sampleChildEntities), and plugins/woocommerce-other-payment-gateway.json is authored and live-verified against the reference store (a real order id substituted into the template found 2 of 3 sampled orders had matching notes) — do not guess a plugin's installed-directory id when authoring a similar profile; confirm detect.pluginFileIds against a live GET /wp/v2/plugins response first, it is exactly the kind of fact a stale or invented guess silently gets wrong.

  • Non-standard response envelope (responseEnvelope, fixed 2026-08-11). Sampling and counting assume a flat array (X-WP-Total/X-WP-TotalPages headers, or the array's own length) or a single object. MailPoet's REST API (/mailpoet/v1/subscribers, /segments, /newsletters, ...) broke that assumption: it is a real, paginated, GET-only REST route (VERIFIED LIVE 2026-08-11: 306 real subscribers on the reference store, readable with the standard Application Password), but the payload is wrapped as { data: { items: [...], meta: { count, pages } } } with no X-WP-Total header — the count lives inside the body instead. Before this fix the whole envelope would have sampled as one opaque record. A profile entity (route-bearing channels only) now declares responseEnvelope: { itemsPath, countPath } — a dot-path to the array of records, and an optional dot-path to the true total when there's no header. wp-discovery.js's inspectEntity unwraps to that path and otherwise treats it exactly like a flat array; a path that stops resolving (stale profile, plugin version drift) falls back to the raw payload shape and records a discovery note rather than failing the run. plugins/mailpoet.json is authored and live-verified against the reference store: crm.email-subscription now resolves to migration-planned via the existing crm/email-subscription target, with recordCount: 306 read via the declared countPath. A namespace-wide unprofiledRoutes entry is still a sign a route this shape (or any other) has never been profiled — check there before concluding a plugin has "no REST surface."

  • Route default query (ROUTE_DEFAULT_QUERY_RULES, fixed 2026-08-16). Sampling sends per_page and nothing else, so any collection route that applies a default filter to an unparameterized request is read as its filtered subset and the plan under-counts — the hidden records are invisible to the mapper, not merely misreported. Observed on /wc/v3/products/reviews, which defaults to status=approved: the reference store has 120 reviews (114 approved + 6 on hold) and discovery counted 114. This is a class of bug, so the fix is a table rather than a special case: wp-route-classifier.js carries ROUTE_DEFAULT_QUERY_RULES — [pattern, params, reason], *-suffix matching, longest pattern wins — and defaultQueryFor(routePath) / defaultQueryReasonFor(routePath) resolve it. wp-discovery.js merges the result under its paging parameters and records a discovery note naming the parameters and the reason, so generated readers know to send them too. Adding a route is one row in the table plus a fixture; a route with no row is unchanged.

Coverage statuses

The four statuses, and only the four: migration-planned (via api or cms, confidence confirmed or proposed), no-need-to-migrate, pending, requires-development. A failed or unavailable read is never a status — it attaches to the row as blocked[] (user-file / surface-changed, with a declined flag).

The split is deliberate: pending (we do not know how to migrate this yet — our open item) and requires-development (a human established Wix has no surface) call for different conversations. Only the second is a closed door, and only a human may open it — the human-signed register plugins/requires-development.json is its single source.

Interaction rules
  • The admin Application Password is the only source credential. A plugin REST namespace that honours WordPress authentication works with it, and that is the normal case — plugins with their own key systems offer them as an alternative for external callers, not a requirement (verified for Gravity Forms, which accepts Application Passwords and runs requests under the caller's plugin capabilities). Do not treat "this plugin has API keys" as "we need another credential"; that reasoning has been wrong every time it was applied. If a plugin genuinely rejects the platform credential, that is a config-gate requirement like the WooCommerce consumer keys — not a per-capability runtime state.

  • blocked[] entries are collected and asked once, batched, each individually skippable. A user-file blocker is the one state no credential can fix: unregistered post meta and plugin tables are unreachable by any WordPress API, and Application Passwords cannot reach wp-admin, so a WXR or CSV export must be produced by the user. Record each answer in orchestration/decisions.json under pluginBlocker:<capability>:<kind> (provided / declined); wp-discovery.js reads it back (--decisions, defaulting to <out-dir>/../../orchestration/decisions.json) so a declined ask renders as declined.

  • migration-planned · proposed rows never block; the proposed capability and target are reviewed at the normal mapping-review checkpoint.

  • requires-development and pending rows must reach the user. A detected but undeliverable capability the user was never told about is the failure this machinery exists to prevent. Every pending row is decided at the mapping review — the only exit.

A recognized plugin always ends in Migration planned (J2 property 1). If a profile matched we know what the plugin holds, so:

  • no readable channel (plugin tables only) → still classified by its target, with a user-file blocker on the row — not pending, and never a "cannot" verdict. A database export or a source-side bridge would reach it, and automation may not foreclose that any more than it may declare Wix incapable.

  • pending · cannot-tell is reserved for an unrecognized plugin where we genuinely found nothing; the no-migration-needed list or the agent's own reading can still resolve it to No need to migrate with a recorded rationale.

A CMS destination is not turnkey. "Kept as data" means the records land in a Wix CMS collection with their original IDs — genuinely migrated, not documented. But Wix Data must be installed first (item writes fail with WDE0110 otherwise) and collection creation has no verified writer yet, so it is a setup step. Say both on the row; a customer reading "Kept as data" should not discover the setup work later.

Guardrails
  • Never a silent native mapping. A derived entity may target a native Wix entity only when the Wix domain knowledge confirms its proposed capability; otherwise it goes to CMS. Either way the row is confidence: proposed and is confirmed at the mapping review.

  • Never a scope reopening. The generic path operates only on routes the route classifier already accepted. It does not resurrect frontend, editor, admin, runtime, or integration families because a plugin registered them.

  • Profile data routes outrank exclusion families (that is the per-capability opt-in), but a wildcard pattern must keep two concrete leading segments, so /yoast/* can never be opted in wholesale.

Commands
node scripts/plugin-knowledge.js list-plugins
node scripts/plugin-knowledge.js read-plugin --slug the-events-calendar
node scripts/plugin-knowledge.js resolve-route --route /tribe/events/v1/events
node scripts/plugin-knowledge.js resolve-property --property bundled_items
node scripts/plugin-knowledge.js list-capabilities
node scripts/wp-plugin-inventory.js --base-url <url> --out-dir <dir> [auth options]
node scripts/plugin-knowledge-validate.js --write-index

To add or correct a plugin, edit plugins/<slug>.json and add a fixture — no skill logic changes. See plugins/README.md.

Read contract (codegen-time)

What a generated WordPress reader must get right. Capture the operational facts below into source-profile.md during discovery so codegen has them without re-deriving.

The generated reader is an extractor, not an in-memory bulk loader. It should fetch WordPress/WooCommerce records page by page and write them to project-local files (for example per-entity paged JSON files plus a manifest) so the import step can read from disk later without re-fetching the source.

Reuse the shared transport — do not regenerate it. The auth, URL building, rate-limit throttling, and Retry-After-aware 429/503 backoff a reader needs already exist as a dependency-free module at lib/wp-http.js in this skill directory (the same module the capture script imports). It exports fetchJson, buildHeaders, configureRateLimit, and parseTotalHeader. Any generated WordPress reader must reuse this module rather than reimplementing transport, so the reader contains only per-project orchestration: which entities to pull, the pagination loop, _embed/_links resolution, and transform glue. One tested transport core is what makes the sampler and the reader behave identically. How the module is carried into a runnable migration project is rp-import-codegen's concern (its File targets), not this adapter's. The notes below describe what the reader does on top of that shared core:

  • Namespaces & auth differ per namespace:

    • wp/v2 (core): HTTP Basic auth with a WordPress Application Password (--username + --application-password).

    • wc/v3 (WooCommerce): consumer key / secret, sent as Basic auth over HTTPS (or as query params on some hosts). This is a different credential from the Application Password — both may be needed for a full migration.

  • Pagination: ?page=N&per_page=M (max per_page is typically 100). Total pages are in the X-WP-TotalPages response header and total records in X-WP-Total — read those rather than guessing when to stop. Some public WooCommerce Store API collection routes paginate without X-WP-TotalPages; when that header is absent, generated readers must stop on the first page whose item count is smaller than per_page.

  • Embedded relations: request ?_embed to inline related resources, or follow the _links block (author, wp:featuredmedia, wp:term) to resolve relations. The evidence pointers in source-schema.json relations come from this _links block.

  • Hierarchical taxonomies: WordPress categories (and custom hierarchical taxonomies) carry a parent field on each term (0 = top-level). When any term has a non-zero parent, the source taxonomy is nested. Discovery must elevate this into structured schema — set "hierarchical": true on that entity in source-schema.json (see source-schema.example.json → category) rather than leaving parent buried in the raw dump. The Wix Blog category target is flat (no parent/child), so this flag is what triggers the mapper's mandatory lossiness entry; without it, the flatten happens silently.

  • Rate limits / retries: not advertised; the capture script throttles (--rate-limit-rpm, default 120) and backs off on 429/503 honoring Retry-After. Generated readers should inherit the same discipline.

  • Rich content: content.rendered / title.rendered are HTML; *.raw requires context=edit (authenticated). Note which the reader should pull.

  • HTML entities in "plain text" fields (trap, hit live 2026-07-19): WordPress returns HTML-encoded entities (–, &, ’, …) not only in rendered HTML but also in fields consumed as plain text — product/category/tag name, title.rendered after tag-stripping, excerpts, even SKUs. Values sent to plain-text Wix fields (product name, blog title, tag label, CMS text columns) must be entity-decoded by the generated transforms or the encoded form appears verbatim in the Wix dashboard. HTML passed to rich-content conversion does NOT need pre-decoding — the converter handles entities.

  • Custom fields: ACF / meta often appear in sample records but are absent from the OPTIONS schema — surface them as unknowns in discovery so the mapper can decide.

  • WooCommerce variation attribute values are URL-encoded slugs, not display names (trap, hit live 2026-07-21): variations[].attributes[].value from wc/v3/products/{id}/variations is a URL-encoded taxonomy-term slug (e.g. 1-%d7%a7%d7%92 for 1 ק"ג), not the human-readable display name that the product's attributes[].options[] array contains. Generated readers must build a per-option slug→displayName map from the parent product's attributes[].options[] (which does carry display names) and resolve slug values to display names before writing to Wix. Passing slugs directly causes MISSING_VARIANT_OPTION_CHOICE because Wix compares variant choice names against option choice names and finds no match.

  • WooCommerce "Any"-style variations have null attribute values (trap, hit live 2026-07-21): When a WooCommerce variation is set to "Any" for an option (the variation applies to any value of that option), variations[].attributes[].value is an empty string or null, not a specific term. Generated transforms that filter variants by attribute value will silently drop "Any" variants, leaving options with no variants — Wix then auto-generates priceless placeholder variants, causing price-empty errors. Fix: when ALL attributes for a variation are null/"Any", treat the variation as a single cartesian entry covering all option choices at the variation's price, rather than filtering it out.

  • Route paths passed to fetchJson / buildApiUrl must NOT include /wp-json (trap, hit live 2026-07-21): buildApiUrl in lib/wp-http.js already prepends /wp-json to the routePath argument. Generated route paths must start with the namespace directly (e.g. /wc/store/v1/products, /wp/v2/posts) — never with /wp-json/.... Prefixing with /wp-json doubles the prefix and produces 404s.

  • WooCommerce consumer key/secret can 401 on some wc/v3 routes even when it reads others fine (trap, hit live 2026-08-12): WC_CONSUMER_KEY/WC_CONSUMER_SECRET are scoped at key-creation time (Read / Write / Read-Write) and can be narrower than the WordPress Application Password's access. On the reference store, the consumer key/secret 401'd woocommerce_rest_cannot_view on wc/v3/taxes, wc/v3/taxes/classes, and wc/v3/settings/tax while the very same reads succeeded immediately with the WP_USERNAME/WP_APPLICATION_PASSWORD Basic auth pair. Generated readers must not treat a 401/403 on one wc/v3 route as proof the whole consumer key is broken (which would wrongly block products/orders/coupons too) — retry that specific route with the Application Password credential before failing, and prefer the Application Password outright for admin-ish wc/v3 routes (taxes, settings) that a narrowly-scoped key is more likely to be denied on.

  • Core WooCommerce settings/tax routes are core, not plugin data: wc/v3/taxes, wc/v3/taxes/classes, and wc/v3/settings/tax are ordinary WooCommerce core collections (same auth/pagination rules as wc/v3/products etc.) — they are not profiled as a "plugin" because tax is core WooCommerce, not an extension. Per-product tax_status/tax_class fields ride along on the ordinary wc/v3/products read; no separate per-product route is needed to get them. See rp-target-wix domains/tax/ for the corresponding Wix target entities (Tax Group / Tax Region / Manual Tax Mapping / Tax Settings) and mapping-plan.json's product and tax-class entities for a live worked example (migrations/reference-run, 2026-08-12).

Schema shape

source-schema.example.json (in this skill folder) is the template rp-discovery follows when emitting migrations/<project>/source-schema.json. It is a shape to follow, not a strict schema to validate against. Keep the platform-agnostic core stable; push WordPress quirks (restNamespace, statuses, etc.) into each entity's open sourceMeta blob.

For a profiled plugin entity, sourceMeta MUST also carry requestMethod, requestBody, and responseFragmentGroupSize verbatim whenever the plugin profile declares them (spec 0044/0045) — copy them from the profile entity (surfaced structurally in plugin detection's per-entity output, wp-plugin-detect.js's describeProfiledEntity) rather than re-deriving them from discovery's prose notes. rp-import-codegen's read contract depends on finding these under exactly those sourceMeta keys; omitting them silently degrades a declared non-GET/fragmented read into an unreadable one downstream.

Files

lib/wp-plugin-detect.js

'use strict';

// Pure plugin detection, generic derivation, and coverage classification.
//
// Everything here is a pure function over already-fetched inputs (REST index, plugin list,
// types/taxonomies, sampled records) so the whole surface is fixture-testable with no live
// WordPress site. Network fetching lives in scripts/wp-plugin-inventory.js.
//
// Classification: every installed plugin lands in exactly
// one of the five statuses in COVERAGE_STATUSES, every status produces a row the user sees, and
// rows state whether the plugin was `recognized` (a profile matched) and whether the mapping is
// `confirmed` (authored by a human) or `proposed` (derived; approved at the mapping review).

const { patternMatchesRoute } = require('./plugin-knowledge.js');
const { childRouteAdvertised } = require('./wp-route-classifier.js');

const CONFIDENCE_ORDER = { high: 3, medium: 2, low: 1 };

// Signal strength, strongest first.
const SIGNAL_CONFIDENCE = {
  'wp.v2.plugins': 'high',
  route: 'high',
  'rest-base': 'medium',
  'record-property': 'medium',
  namespace: 'low',
  'asset-path': 'low',
};

// The five statuses of the plugin-classification scheme (+ manual-mapping). Every installed plugin lands
// in exactly one, every status is a sentence a merchant can act on, and there is no second
// internal vocabulary.
//
//   migration-planned    - "this comes across", via `api` (native Wix entity) or via `cms`
//                          (kept as data with its original IDs). `confidence` states whether a
//                          human authored the mapping (confirmed) or we derived it (proposed).
//   manual-mapping       - "Wix can do this — here are the exact steps you take yourself".
//                          A complete, decided mapping with no write for our code to make: no
//                          `preferredWrite` call exists, only a `manualSteps` runbook (row.
//                          manualSteps). Unlike `pending`, nothing here is undecided — it needs
//                          no human sign-off gate, only the merchant's own follow-through.
//   no-need-to-migrate   - "nothing to move": Wix already does it, it was never data, or it is
//                          a setting you reconfigure once in Wix. Two sources: the slug list
//                          (`basis: list`, unprofiled plugins) and the human-signed
//                          per-capability register (`basis: decision`, profiled plugins).
//   pending              - "we do not know how to migrate this yet". OUR open item, decided at
//                          the mapping review; never a statement about the source or about Wix.
//   requires-development - "Wix has no surface for this; build it first". Reachable ONLY from
//                          the human-signed register — automation may never conclude
//                          impossibility. Two agent-made impossibility claims (gift cards,
//                          events) were already wrong; both had a create API.
//
// Blocked — recoverable is deliberately NOT here: a failed or unavailable read attaches to the
// row as `blocked[]` and never becomes a mapping decision (see CHANNEL_BLOCKERS).
const COVERAGE_STATUSES = new Set([
  'migration-planned',
  'manual-mapping',
  'no-need-to-migrate',
  'pending',
  'requires-development',
]);

// A channel that cannot be read today attaches a blocker to the row: fix and re-run. This is
// what keeps a db-only gift-card balance "Migration planned + blocked", not "pending" —
// unreadable today, recoverable by an export, and never reported as a limitation of Wix.
const CHANNEL_BLOCKERS = {
  'needs-export-file': {
    kind: 'user-file',
    resolution: 'Provide the plugin export file produced on the source site; only you can produce it (Application Passwords never reach wp-admin).',
  },
  unavailable: {
    kind: 'user-file',
    resolution: 'The plugin keeps this data in its own database tables; provide a database export or a source-side bridge.',
  },
  'needs-user-transcription': {
    kind: 'user-file',
    resolution: 'The plugin exposes this configuration only in wp-admin; transcribe it or provide screenshots from an authenticated browser session.',
  },
  'route-absent': {
    kind: 'surface-changed',
    resolution: 'The profile declares a route this site does not expose; the profile may be stale or the plugin version differs.',
  },
  'property-absent': {
    kind: 'surface-changed',
    resolution: 'The profile declares an embedded property the sampled records do not carry; the profile may be stale or the plugin version differs.',
  },
  'api-below-min-version': {
    kind: 'surface-changed',
    resolution: 'The installed plugin version predates the REST surface this profile reads; upgrade the plugin or supply an export file.',
  },
};

function blockersForEntities(entities) {
  const blocked = [];
  for (const entity of entities) {
    const declared = (entity.pitfalls || []).flatMap((pitfall) => pitfall.blocked || []);
    if (declared.length > 0) {
      for (const blocker of declared) {
        blocked.push({
          ...blocker,
          entity: entity.entity,
          channel: entity.channel,
          declined: blocker.declined === true,
        });
      }
      continue;
    }
    const spec = CHANNEL_BLOCKERS[entity.channelStatus];
    if (!spec) continue;
    blocked.push({
      kind: spec.kind,
      entity: entity.entity,
      channel: entity.channel,
      resolution: spec.resolution,
      declined: false,
    });
  }
  return blocked;
}

const CHANNEL_AVAILABILITY = {
  'plugin-rest': 'available',
  'core-cpt': 'available',
  'core-embedded': 'available',
  'core-meta': 'available',
  'plugin-rest-child': 'available',
  'export-file': 'needs-export-file',
  'db-only': 'unavailable',
  'admin-page-only': 'needs-user-transcription',
};

function bestConfidence(signals) {
  let best = null;
  for (const signal of signals) {
    const kind = String(signal).split(':')[0];
    const confidence = SIGNAL_CONFIDENCE[kind] || 'low';
    if (!best || CONFIDENCE_ORDER[confidence] > CONFIDENCE_ORDER[best]) best = confidence;
  }
  return best || 'low';
}

function compareVersions(a, b) {
  const pa = String(a).split('.').map((part) => Number.parseInt(part, 10) || 0);
  const pb = String(b).split('.').map((part) => Number.parseInt(part, 10) || 0);
  for (let i = 0; i < Math.max(pa.length, pb.length); i += 1) {
    const diff = (pa[i] || 0) - (pb[i] || 0);
    if (diff !== 0) return diff < 0 ? -1 : 1;
  }
  return 0;
}

function routeSet(restIndex) {
  return new Set(Object.keys(restIndex?.routes || {}));
}

function namespaceSet(restIndex) {
  return new Set(Array.isArray(restIndex?.namespaces) ? restIndex.namespaces : []);
}

function restBaseSet(types, taxonomies) {
  const bases = new Set();
  for (const collection of [types, taxonomies]) {
    for (const entry of Object.values(collection || {})) {
      if (entry && entry.rest_base) bases.add(entry.rest_base);
      if (entry && entry.slug) bases.add(entry.slug);
    }
  }
  return bases;
}

// Plugin file ids look like "the-events-calendar/the-events-calendar.php". The list endpoint
// returns them without the ".php" on some versions, so compare on the directory segment too.
function pluginFileVariants(pluginFileId) {
  const variants = new Set([pluginFileId]);
  variants.add(pluginFileId.replace(/\.php$/, ''));
  const dir = pluginFileId.split('/')[0];
  if (dir) variants.add(dir);
  return variants;
}

// VERIFIED LIVE 2026-07-30: a plugin's main file basename frequently differs from its
// directory — real ids include `wordpress-seo/wp-seo`, `woo-custom-product-addons/start`,
// `chaty/cht-icons`, `print-google-cloud-print-gcp-woocommerce/index`. A profile author
// writing the conventional `dir/dir.php` guess must still match, so compare the two id
// variant SETS (which both include the bare directory) rather than comparing each declared
// string against the other's set — the latter never intersects on the directory token.
// Plugin directories are unique per install, so directory-level matching cannot collide.
function matchInstalled(profile, installed) {
  const declared = profile.detect?.pluginFileIds || [];
  if (declared.length === 0) return null;
  const declaredVariants = declared.map((declaredId) => pluginFileVariants(declaredId));
  for (const entry of installed) {
    const candidates = pluginFileVariants(String(entry.plugin || ''));
    for (const variants of declaredVariants) {
      for (const variant of variants) {
        if (candidates.has(variant)) return entry;
      }
    }
  }
  return null;
}

function detectPlugins({
  profiles = [],
  restIndex = null,
  pluginList = null,
  types = null,
  taxonomies = null,
  htmlSources = [],
  sampledRecordProperties = [],
  // The fingerprint alias map ({ aliases: { token: { displayName, slug } } }).
  fingerprintAliases = null,
} = {}) {
  const routes = routeSet(restIndex);
  const rawRoutes = restIndex?.routes || {};
  const namespaces = namespaceSet(restIndex);
  const bases = restBaseSet(types, taxonomies);
  const properties = new Set(sampledRecordProperties);
  const html = htmlSources.join('\n');
  const installed = Array.isArray(pluginList) ? pluginList : [];
  const pluginListAvailable = Array.isArray(pluginList);

  const detected = [];
  const claimedInstalled = new Set();

  for (const profile of profiles) {
    const signals = [];
    const detect = profile.detect || {};

    const installedEntry = matchInstalled(profile, installed);
    if (installedEntry) {
      signals.push('wp.v2.plugins');
      claimedInstalled.add(installedEntry.plugin);
    }
    for (const route of detect.routes || []) {
      if (routes.has(route)) signals.push(`route:${route}`);
    }
    for (const entity of profile.entities || []) {
      if (entity.route && routes.has(entity.route)) signals.push(`route:${entity.route}`);
    }
    for (const base of detect.restBases || []) {
      if (bases.has(base)) signals.push(`rest-base:${base}`);
    }
    for (const property of detect.recordProperties || []) {
      if (properties.has(property)) signals.push(`record-property:${property}`);
    }
    for (const entity of profile.entities || []) {
      if ((entity.channel === 'core-embedded' || entity.channel === 'core-meta') && entity.propertyPath && properties.has(entity.propertyPath)) {
        signals.push(`record-property:${entity.propertyPath}`);
      }
    }
    for (const namespace of detect.restNamespaces || []) {
      if (namespaces.has(namespace)) signals.push(`namespace:${namespace}`);
    }
    for (const slug of detect.assetPathSlugs || []) {
      if (html.includes(`/wp-content/plugins/${slug}/`)) signals.push(`asset-path:${slug}`);
    }

    if (signals.length === 0) continue;

    const uniqueSignals = Array.from(new Set(signals)).sort();
    const version = installedEntry?.version || null;
    // A version below the profile's documented REST threshold means the capability is
    // present but this profile's read contract does not apply. Saying so is more useful
    // than either claiming a readable entity or dropping the plugin entirely.
    const apiBelowMinVersion = Boolean(
      detect.minVersion && version && compareVersions(version, detect.minVersion) < 0,
    );

    detected.push({
      plugin: profile.plugin,
      displayName: profile.displayName,
      version,
      active: installedEntry ? installedEntry.status === 'active' : null,
      distribution: profile.distribution || 'unknown',
      confidence: bestConfidence(uniqueSignals),
      signals: uniqueSignals,
      capabilities: [...(profile.capabilities || [])],
      profileVersion: profile.profileVersion,
      apiBelowMinVersion,
      minVersion: detect.minVersion || null,
      entities: (profile.entities || []).map((entity) => describeProfiledEntity(entity, {
        routes,
        rawRoutes,
        properties,
        apiBelowMinVersion,
      })),
    });
  }

  const profiledNamespaces = new Set();
  const profiledRoutePatterns = [];
  for (const profile of profiles) {
    for (const namespace of profile.detect?.restNamespaces || []) profiledNamespaces.add(namespace);
    for (const entity of profile.entities || []) {
      if (entity.route) profiledRoutePatterns.push(entity.route);
    }
    for (const rule of profile.dataRoutePatterns || []) profiledRoutePatterns.push(rule.pattern);
  }

  const installedButUnprofiled = installed
    .filter((entry) => !claimedInstalled.has(entry.plugin))
    .map((entry) => ({
      plugin: entry.plugin,
      name: entry.name || null,
      version: entry.version || null,
      active: entry.status === 'active',
      textdomain: entry.textdomain || null,
    }))
    .sort((a, b) => String(a.plugin).localeCompare(String(b.plugin)));

  const fingerprinted = collectFingerprints({
    namespaces,
    html,
    profiles,
    installed,
    aliases: fingerprintAliases?.aliases || {},
  });

  return {
    pluginListAvailable,
    detected: detected.sort((a, b) => a.plugin.localeCompare(b.plugin)),
    installedButUnprofiled,
    fingerprinted,
    profiledNamespaces: Array.from(profiledNamespaces).sort(),
    profiledRoutePatterns: profiledRoutePatterns.sort(),
  };
}

// The fingerprinted tier: public evidence of plugins nothing else claimed.
// wp-content/plugins/<slug> asset paths and unrecognized REST namespaces are read and named
// through the alias map instead of thrown away. Names only: the tier makes no completeness
// claim (the incomplete-list warning stands unchanged) and never feeds route selection — it
// is inventory, not scope. Verified against a live WordPress installation: unauthenticated,
// dozens of plugins publicly self-announced while the function returned 1 detected + 0 unprofiled.
// Platform namespaces that are the host or the commerce platform, not a plugin: WordPress
// core, the WordPress.com hosting layer, and WooCommerce's own admin/telemetry surfaces
// (VERIFIED LIVE 2026-08-10: a stock WooCommerce store advertises eight wc-* namespaces
// that would otherwise read as eight unknown plugins). A row for one of these would tell
// the user to worry about their own platform.
const CORE_FINGERPRINT_TOKENS = new Set([
  'wp', 'wc', 'oembed', 'wp-block-editor', 'wp-site-health', 'wp-abilities', 'mcp',
  'wpcom', 'wpcomsh', 'help-center',
  'woocommerce', 'wc-admin', 'wc-admin-email', 'wc-analytics', 'wc-push-notifications',
  'wc-telemetry', 'wccom-site', 'woocommerce-email-editor',
]);

function collectFingerprints({ namespaces, html, profiles, installed, aliases }) {
  const claimed = new Set(CORE_FINGERPRINT_TOKENS);
  for (const profile of profiles) {
    for (const slug of profile.detect?.assetPathSlugs || []) claimed.add(slug);
    for (const namespace of profile.detect?.restNamespaces || []) claimed.add(namespace.split('/')[0]);
    claimed.add(profile.plugin);
  }
  // A plugin already on the installed list is inventory we hold with certainty; its public
  // fingerprint adds nothing and must not produce a second row. Match fuzzily, the same way
  // namespace attribution does — a namespace token is often a shortening of the directory
  // (acme-shop vs acme-shop-vouchers) — because the tier's claim is precision, and a
  // duplicate row costs more than a missed name.
  const installedTokens = new Set();
  for (const entry of installed) {
    const dir = String(entry.plugin || '').split('/')[0];
    if (dir) installedTokens.add(normalizeToken(dir));
    if (entry.textdomain) installedTokens.add(normalizeToken(entry.textdomain));
  }
  // VERIFIED against live WordPress installations: a fingerprint token is frequently a cryptic internal
  // namespace (wpjm-internal, fb_api, wc-facebook, mc4wp, zprint, yoast) that fails the fuzzy
  // token match above even though the alias map already resolves it to an exact installed
  // slug (wp-job-manager, facebook-for-woocommerce, mailchimp-for-wp,
  // print-google-cloud-print-gcp-woocommerce, wordpress-seo) — that is the whole reason an
  // alias exists. Skipping this check produced a second, confusing per-plugin row for five
  // different already-installed plugins in one real run, each showing both "fingerprinted"
  // and "installed but unprofiled" text glued together.
  const matchesInstalled = (token) => {
    const normalized = normalizeToken(token);
    if (!normalized) return false;
    const aliasSlug = aliases[token]?.slug;
    if (aliasSlug && installedTokens.has(normalizeToken(aliasSlug))) return true;
    for (const installedToken of installedTokens) {
      if (installedToken.includes(normalized) || normalized.includes(installedToken)) return true;
    }
    return false;
  };

  const byToken = new Map();
  const consider = (token, evidence) => {
    if (!token || claimed.has(token) || matchesInstalled(token)) return;
    if (!byToken.has(token)) byToken.set(token, { token, evidence: new Set() });
    byToken.get(token).evidence.add(evidence);
  };

  for (const namespace of namespaces) consider(namespace.split('/')[0], `namespace:${namespace}`);
  for (const match of html.matchAll(/\/wp-content\/plugins\/([a-z0-9_-]+)\//g)) {
    consider(match[1], `asset-path:${match[1]}`);
  }

  return Array.from(byToken.values())
    .map((entry) => {
      const alias = aliases[entry.token] || null;
      return {
        token: entry.token,
        evidence: Array.from(entry.evidence).sort(),
        displayName: alias?.displayName || null,
        slug: alias?.slug || entry.token,
        aliasMatched: Boolean(alias),
      };
    })
    .sort((a, b) => a.token.localeCompare(b.token));
}

// Channel status describes only whether the SOURCE exposes this entity. Credential state is
// deliberately not encoded here: it is resolved in classifyCoverage against the credentials
// actually granted for the run, so granting one later cannot leave a stale entity status.
function describeProfiledEntity(entity, { routes, rawRoutes, properties, apiBelowMinVersion }) {
  let channelStatus = CHANNEL_AVAILABILITY[entity.channel] || 'unavailable';

  if (channelStatus === 'available') {
    // plugin-rest-child's route is a {parentId} template, never a literal index route — it is
    // checked below, against both the parent collection and the templated child route.
    if (entity.channel !== 'plugin-rest-child' && entity.route && !routes.has(entity.route) && !entity.route.includes('*')) {
      channelStatus = 'route-absent';
    }
    if ((entity.channel === 'core-embedded' || entity.channel === 'core-meta') && entity.propertyPath && !properties.has(entity.propertyPath)) {
      channelStatus = 'property-absent';
    }
    if (entity.channel === 'plugin-rest-child') {
      // Presence only: the parent collection is in scope AND the site's REST index
      // advertises a sub-resource shaped like the entity's route template. Whether any real
      // parent record actually has data there is a live, per-parent question answered later
      // by wp-discovery.js's representative sample — never assumed here.
      const parentAvailable = Boolean(entity.parentRoute) && routes.has(entity.parentRoute);
      const childAdvertised = Boolean(entity.route) && childRouteAdvertised(rawRoutes, entity.route);
      if (!parentAvailable || !childAdvertised) {
        channelStatus = 'route-absent';
      }
    }
  }
  if (apiBelowMinVersion && channelStatus === 'available') channelStatus = 'api-below-min-version';

  return {
    entity: entity.entity,
    capability: entity.capability || null,
    channel: entity.channel,
    channelStatus,
    route: entity.route || null,
    parentRoute: entity.parentRoute || null,
    embeddedIn: entity.embeddedIn || null,
    propertyPath: entity.propertyPath || null,
    context: entity.context || null,
    requiresParent: entity.requiresParent || null,
    hierarchical: entity.hierarchical === true,
    // Read-mechanics fields (spec 0044/0045) that rp-import-codegen's sourceMeta contract
    // depends on — dropping them here would leave the documented contract with nothing to
    // copy from, since this is the structured (non-prose) per-entity description that
    // detection writes to disk.
    requestMethod: entity.requestMethod || null,
    requestBody: entity.requestBody || null,
    responseFragmentGroupSize: entity.responseFragmentGroupSize || null,
    candidateTargetRefs: [...(entity.candidateTargetRefs || [])],
    pitfalls: entity.pitfalls || [],
  };
}

// Unprofiled REST namespaces, so heuristic acceptance is visible rather than
// indistinguishable from known-good coverage.
function collectUnprofiledRoutes({ classifications = [], detection }) {
  const profiledPatterns = detection?.profiledRoutePatterns || [];
  const byNamespace = new Map();

  for (const classification of classifications) {
    if (classification.effectiveAction !== 'sample') continue;
    // Core WordPress and WooCommerce families are covered by the classifier's own
    // allowlist; they are not "unprofiled plugins". Profile-matched routes are filtered
    // below by pattern, not by rule id — the generic fallback rule id also begins with
    // "plugin.", so a prefix test would wrongly hide heuristic acceptances.
    if (/^(wp|wc)\./.test(classification.ruleId || '')) continue;
    if (profiledPatterns.some((pattern) => patternMatchesRoute(pattern, classification.routePath))) continue;

    const namespace = classification.namespace || classification.routePath.split('/').slice(1, 3).join('/');
    if (!byNamespace.has(namespace)) {
      byNamespace.set(namespace, { namespace, routes: [], ruleIds: new Set() });
    }
    const entry = byNamespace.get(namespace);
    entry.routes.push(classification.routePath);
    entry.ruleIds.add(classification.ruleId);
  }

  return Array.from(byNamespace.values())
    .map((entry) => ({
      namespace: entry.namespace,
      routes: entry.routes.sort(),
      ruleIds: Array.from(entry.ruleIds).sort(),
      read: true,
      reason: 'no plugin profile matched; accepted by generic collection-shape classification',
    }))
    .sort((a, b) => a.namespace.localeCompare(b.namespace));
}

// Collection-shaped routes in namespaces we do not recognize that were NOT read. Verified
// live: the REST index advertises no per-route schema, so these never reach `sample`. They
// are reported rather than sampled so the coverage report can say "this plugin looks like it
// holds records we did not read" instead of omitting it.
const CORE_NAMESPACE_PREFIXES = ['wp/v2', 'wc/v1', 'wc/v2', 'wc/v3', 'wc/store', 'oembed/1.0'];

function collectCandidateNamespaces({ classifications = [], candidates = [], detection = null }) {
  const profiledPatterns = detection?.profiledRoutePatterns || [];
  const shaped = new Map(candidates.map((candidate) => [candidate.routePath, candidate]));
  const byNamespace = new Map();

  for (const classification of classifications) {
    if (classification.effectiveAction !== 'skip') continue;
    // Only the "we had no rule for it" bucket. Anything a deliberate exclusion family
    // caught (admin, runtime, diagnostics, integration…) stays out of scope by design.
    if (classification.ruleId !== 'unsupported.default') continue;
    const candidate = shaped.get(classification.routePath);
    const hasShape = Boolean(candidate?.getEndpoint?.args?.page || candidate?.getEndpoint?.args?.per_page);
    if (!hasShape) continue;
    if (CORE_NAMESPACE_PREFIXES.some((prefix) => classification.routePath.startsWith(`/${prefix}/`))) continue;
    if (profiledPatterns.some((pattern) => patternMatchesRoute(pattern, classification.routePath))) continue;

    const namespace = classification.namespace || classification.routePath.split('/').slice(1, 3).join('/');
    if (!byNamespace.has(namespace)) byNamespace.set(namespace, { namespace, routes: [] });
    byNamespace.get(namespace).routes.push(classification.routePath);
  }

  return Array.from(byNamespace.values())
    .map((entry) => ({
      namespace: entry.namespace,
      routes: entry.routes.sort(),
      read: false,
      reason: 'collection-shaped routes in an unrecognized namespace; not read by default',
    }))
    .sort((a, b) => a.namespace.localeCompare(b.namespace));
}

// Tier B: derive entities for unprofiled, REST-visible plugin post types and taxonomies.
// Built from /wp/v2/types and /wp/v2/taxonomies, which is what makes broad coverage the
// default rather than a per-plugin achievement.
const CORE_POST_TYPES = new Set(['post', 'page', 'attachment', 'nav_menu_item', 'wp_block', 'wp_template', 'wp_template_part', 'wp_navigation', 'wp_font_family', 'wp_font_face', 'wp_global_styles', 'product', 'product_variation', 'shop_order', 'shop_coupon']);
const CORE_TAXONOMIES = new Set(['category', 'post_tag', 'nav_menu', 'link_category', 'post_format', 'wp_pattern_category', 'product_cat', 'product_tag', 'product_brand']);

const GENERIC_TARGET_REFS = ['cms/collection', 'cms/data-item'];

function deriveGenericEntities({
  types = null,
  taxonomies = null,
  classifications = [],
  detection = null,
  sampledByRoute = new Map(),
} = {}) {
  const profiledPatterns = detection?.profiledRoutePatterns || [];
  const sampledRoutes = new Set(
    classifications
      .filter((classification) => ['sample', 'metadata'].includes(classification.effectiveAction))
      .map((classification) => classification.routePath),
  );
  const entities = [];

  const consider = (kind, key, entry) => {
    const restBase = entry?.rest_base || entry?.slug || key;
    if (!restBase) return;
    if (entry?.show_in_rest === false) return;
    if (kind === 'post-type' && CORE_POST_TYPES.has(key)) return;
    if (kind === 'taxonomy' && CORE_TAXONOMIES.has(key)) return;

    const namespace = entry?.rest_namespace || 'wp/v2';
    const route = `/${namespace}/${restBase}`;
    if (profiledPatterns.some((pattern) => patternMatchesRoute(pattern, route))) return;
    // Scope containment: only routes the 0005 classifier already accepted may be derived.
    // The generic path must never resurrect an excluded route family.
    if (!sampledRoutes.has(route)) return;

    const sampled = sampledByRoute.get(route) || null;
    entities.push({
      entity: restBase,
      origin: kind === 'taxonomy' ? 'generic-taxonomy' : 'generic-post-type',
      recognized: false,
      channel: 'core-cpt',
      route,
      restBase,
      sourcePostType: kind === 'post-type' ? key : null,
      sourceTaxonomy: kind === 'taxonomy' ? key : null,
      displayName: entry?.name || restBase,
      hierarchical: entry?.hierarchical === true,
      attachedToTypes: Array.isArray(entry?.types) ? [...entry.types] : [],
      recordCount: sampled ? sampled.recordCount : null,
      inUse: sampled ? sampled.inUse : null,
      candidateTargetRefs: [...GENERIC_TARGET_REFS],
      proposedCapability: proposeCapability(kind, key, restBase, entry),
      capabilityConfidence: 'proposed',
      notes: buildGenericNotes(kind, entry),
    });
  };

  for (const [key, entry] of Object.entries(types || {})) consider('post-type', key, entry);
  for (const [key, entry] of Object.entries(taxonomies || {})) consider('taxonomy', key, entry);

  return entities.sort((a, b) => a.route.localeCompare(b.route));
}

// A proposal, never a decision: it is recorded with unverified confidence and reviewed by
// the user at the existing mapping-review checkpoint. Native selection still requires a
// target-KB match (see classifyCoverage), so a wrong guess here cannot cause a bad write.
function proposeCapability(kind, key, restBase, entry) {
  const haystack = [key, restBase, entry?.name, ...(entry?.tags || [])]
    .filter(Boolean)
    .join(' ')
    .toLowerCase();
  const rules = [
    [/(event|calendar|webinar)/, 'content.events'],
    [/(course|lesson|lms|quiz)/, 'content.courses'],
    [/(booking|appointment|reservation)/, 'commerce.bookings'],
    [/(testimonial|review|rating)/, 'content.reviews'],
    [/(portfolio|project|gallery|album)/, 'content.portfolio'],
    // Jobs before listings: "jobs_listing" contains both, and the job reading is the
    // specific one. Rule order is the tie-breaker, so keep specific before generic.
    [/(job|vacancy|career|resume)/, 'content.jobs'],
    [/(listing|directory|property|realestate)/, 'content.listings'],
    [/(recipe|menu|dish)/, 'content.recipes'],
    [/(podcast|episode)/, 'content.podcast'],
    [/(faq|question)/, 'content.faq'],
    [/(team|staff|person|member-profile)/, 'content.people'],
    [/(form|entry|submission)/, 'content.form-submissions'],
    [/(donation|campaign|fundrais)/, 'commerce.donations'],
    [/(membership|subscriber|plan)/, 'commerce.memberships'],
    [/(location|store-locator|branch)/, 'business.locations'],
  ];
  for (const [pattern, capability] of rules) {
    if (pattern.test(haystack)) return capability;
  }
  return kind === 'taxonomy' ? 'content.custom-taxonomy' : 'content.custom-records';
}

function buildGenericNotes(kind, entry) {
  const notes = [];
  if (kind === 'taxonomy' && entry?.hierarchical === true) {
    notes.push('Hierarchical source taxonomy: mapping must record a faithfulness-ledger entry if the chosen Wix target is flat.');
  }
  notes.push('Derived structurally without a plugin profile; unregistered post meta (show_in_rest absent) is not readable over REST and is therefore not included.');
  return notes;
}

// Coverage rows: one per capability, the user-facing answer to "what happens to my plugins".
//
// Row shape. Common fields: capability,
// recognized, basis ('profile' | 'list' | 'proposed' | 'decision'), plugins[], sourceEntities[],
// channels[], recordCounts, profileVersion, blocked[], userImpact, action. Status-specific
// fields:
//   migration-planned    - via ('api' | 'cms'), confidence ('confirmed' | 'proposed'), targetRefs[]
//   manual-mapping        - via ('manual'), confidence ('confirmed'), targetRefs[], manualSteps
//                          (the rp-target-wix entity's manualSteps object, verbatim)
//   no-need-to-migrate   - reason ('platform-does-it' | 'not-needed' | 'reconfigure-in-wix'),
//                          replacedBy, rationale (required); plus decidedBy/decidedOn when
//                          basis is 'decision' (the signed per-capability register)
//   pending              - reason (including 'cannot-tell'), searched[]
//   requires-development - decidedBy, decidedOn, evidence[]

// For manual-mapping: every one of `refs` resolves to a manual-mapping target (never a mix — a
// capability with some manual and some automated targets is a KB authoring error, not
// something this layer should silently resolve one way or the other). Returns the first
// manualSteps object to attach to the row, or null when `refs` is empty or not entirely
// manual-mapping.
function resolveManualMapping(refs, targetKnowledge) {
  const manualStepsByRef = targetKnowledge && targetKnowledge.manualStepsByRef;
  if (!manualStepsByRef || !refs || refs.length === 0) return null;
  const steps = refs.map((ref) => manualStepsByRef.get(ref)).filter(Boolean);
  return steps.length === refs.length ? steps[0] : null;
}

function classifyCoverage({
  detection = null,
  genericEntities = [],
  unprofiledRoutes = [],
  targetKnowledge = null,
  entityStatsByRoute = new Map(),
  // The human-signed register (capabilities-without-native-target.json). The ONLY source of
  // requires-development. Entries carry decidedBy/decidedOn/evidence; a bare Set of capability
  // strings is also accepted.
  humanRuledOutCapabilities = new Set(),
  requiresDevelopmentEntries = [],
  // Working notes for profiled capabilities we have not placed (capabilities-pending-decision.json).
  pendingNotes = [],
  // The no-migration-needed file, both tiers:
  //   hints[]        - installed plugins with no data to move at all. A hit here is strong
  //                    evidence, not the final answer — the agent confirms it during classification and
  //                    records the rationale; the row is marked `basis: list` so an
  //                    unconfirmed hit is auditable.
  //   capabilities[] - human-signed per-capability verdicts on PROFILED plugins, the only way
  //                    a profiled capability reaches no-need-to-migrate. `basis: decision`.
  noMigrationNeeded = null,
} = {}) {
  const rows = [];
  const knownRefs = targetKnowledge?.knownRefs || new Set();
  const capabilityRefs = targetKnowledge?.capabilityRefs || new Map();

  const ruledOut = new Map();
  for (const entry of requiresDevelopmentEntries) {
    if (entry && entry.capability) ruledOut.set(entry.capability, entry);
  }
  for (const capability of humanRuledOutCapabilities) {
    if (!ruledOut.has(capability)) ruledOut.set(capability, null);
  }
  const pendingByCapability = new Map(
    pendingNotes.filter((entry) => entry && entry.capability).map((entry) => [entry.capability, entry]),
  );
  const hintsBySlug = new Map();
  for (const hint of noMigrationNeeded?.hints || []) {
    if (hint && hint.slug) hintsBySlug.set(hint.slug, hint);
  }
  // Only a SIGNED entry grants the verdict. An unsigned one is ignored here rather than
  // trusted, so a stale or hand-edited copy of the register cannot let automation decide a
  // customer has nothing to move; the validator rejects it in the repo, and the row falls
  // through to pending at runtime, which is the safe direction.
  const noNeedByCapability = new Map();
  for (const entry of noMigrationNeeded?.capabilities || []) {
    if (entry && entry.capability && entry.decidedBy && entry.decidedOn) {
      noNeedByCapability.set(entry.capability, entry);
    }
  }

  const byCapability = new Map();
  for (const plugin of detection?.detected || []) {
    for (const capability of plugin.capabilities) {
      if (!byCapability.has(capability)) byCapability.set(capability, []);
      byCapability.get(capability).push(plugin);
    }
  }

  // Recognized capabilities are classified independently. A resolved target is migration-planned
  // even when its source channel is blocked; an unresolved capability remains pending.
  for (const [capability, plugins] of byCapability) {
    const entities = plugins.flatMap((plugin) => {
      const hasAttribution = plugin.entities.some((entity) => entity.capability);
      return hasAttribution
        ? plugin.entities.filter((entity) => entity.capability === capability)
        : plugin.entities;
    });
    const refs = Array.from(new Set(entities.flatMap((entity) => entity.candidateTargetRefs)))
      .filter((ref) => knownRefs.has(ref));
    const nativeRefs = capabilityRefs.get(capability) || [];
    const recordCounts = {};
    for (const entity of entities) {
      const stats = entity.route ? entityStatsByRoute.get(entity.route) : null;
      if (stats && stats.recordCount !== null) recordCounts[entity.entity] = stats.recordCount;
    }

    const channels = Array.from(new Set(entities.map((entity) => entity.channel))).sort();
    const base = {
      capability,
      recognized: true,
      basis: 'profile',
      plugins: plugins.map((plugin) => plugin.plugin).sort(),
      sourceEntities: entities.map((entity) => entity.entity).sort(),
      recordCounts,
      channels,
      channel: channels.length === 1 ? channels[0] : channels.join('+'),
      profileVersion: Array.from(new Set(plugins.map((plugin) => plugin.profileVersion).filter(Boolean))).join('+') || null,
      pitfalls: entities.flatMap((entity) => entity.pitfalls),
      blocked: blockersForEntities(entities),
    };

    let row;
    const verdict = ruledOut.get(capability);
    const nativeRefsManualSteps = resolveManualMapping(nativeRefs, targetKnowledge);
    const refsManualSteps = resolveManualMapping(refs, targetKnowledge);
    if (ruledOut.has(capability)) {
      // Only reachable from the human-signed register.
      row = {
        ...base,
        status: 'requires-development',
        basis: 'decision',
        decidedBy: verdict?.decidedBy || null,
        decidedOn: verdict?.decidedOn || null,
        evidence: [...(verdict?.evidence || [])],
        targetRefs: [],
      };
    } else if (nativeRefs.length > 0 && nativeRefsManualSteps) {
      // For manual-mapping: every target ref this capability resolved to is manual-mapping — there is
      // nothing for our code to call, only a runbook to hand the merchant.
      row = {
        ...base,
        status: 'manual-mapping',
        via: 'manual',
        confidence: 'confirmed',
        targetRefs: [...nativeRefs].sort(),
        manualSteps: nativeRefsManualSteps,
      };
    } else if (nativeRefs.length > 0) {
      // How well the target entity is exercised is our problem, not the customer's: verified
      // and unverified native targets classify identically.
      row = { ...base, status: 'migration-planned', via: 'api', confidence: 'confirmed', targetRefs: [...nativeRefs].sort() };
    } else if (refs.length > 0 && refsManualSteps) {
      row = {
        ...base,
        status: 'manual-mapping',
        via: 'manual',
        confidence: 'confirmed',
        targetRefs: refs.sort(),
        manualSteps: refsManualSteps,
      };
    } else if (refs.length > 0) {
      const via = refs.every((ref) => ref.startsWith('cms/')) ? 'cms' : 'api';
      row = { ...base, status: 'migration-planned', via, confidence: 'confirmed', targetRefs: refs.sort() };
    } else if (noNeedByCapability.has(capability)) {
      // A human decided this profiled capability has nothing to move. Not impossibility
      // — the outcome exists in Wix, or was never data — but still a decision about
      // what the customer does not get, so it is signed and it is persistent: without this
      // exit the row re-lands as pending on every run and the verdict has nowhere to live.
      const decision = noNeedByCapability.get(capability);
      row = {
        ...base,
        status: 'no-need-to-migrate',
        basis: 'decision',
        reason: normalizeNoMigrationReason(decision.reason),
        replacedBy: decision.replacedBy || null,
        rationale: decision.rationale || null,
        decidedBy: decision.decidedBy,
        decidedOn: decision.decidedOn,
        targetRefs: [],
        // Nothing to move means nothing is blocked. An unreadable channel on a capability
        // that is not being migrated is not something to ask the user to fix.
        blocked: [],
      };
    } else {
      // A profiled capability we have not placed. Pending is a statement about OUR knowledge;
      // the working note carries what we searched and what we suspect, with no authority.
      const note = pendingByCapability.get(capability);
      row = {
        ...base,
        status: 'pending',
        reason: note?.reason || 'no Wix target resolved for this capability yet',
        searched: note?.searched ? [note.searched] : [],
        targetRefs: [],
      };
    }
    row.userImpact = describeImpact(row, entities);
    row.action = describeAction(row);
    rows.push(row);
  }

  // Attribute generic entities to an installed-but-unprofiled plugin BEFORE the shape-only
  // grouping below, and only when its slug/textdomain genuinely prefixes the entity's own
  // rest_base/slug. Two unrelated plugins that both register "a custom post type" or "a
  // custom taxonomy" must never end up sharing one row: a shared shape-bucket row attributed
  // wholesale to whichever plugin matched first previously let Disclaimer Popup (a site
  // popup) absorb Jetpack Pay's own order/product entities, MailPoet's post type, Npcink
  // Ad's promotions, and a duplicate of The Events Calendar's organizer/venue entities, while
  // DineKit absorbed an unrelated knowledge-base taxonomy (verified against a live WordPress installation).
  // An entity with no confidently-matched owner stays in the shape bucket, unattributed —
  // visible at the mapping review, credited to no one, which is honest; false attribution is
  // not.
  const MIN_OWNER_TOKEN_LENGTH = 4;
  const ownedEntityKeys = new Set();
  const attributed = new Set();
  for (const installed of detection?.installedButUnprofiled || []) {
    const tokens = pluginTokens(installed).filter((token) => token.length >= MIN_OWNER_TOKEN_LENGTH);
    const ownedEntities = genericEntities.filter((entity) => {
      const normalizedEntity = normalizeToken(entity.entity);
      return tokens.some((token) => normalizedEntity.startsWith(token));
    });
    if (ownedEntities.length === 0) continue;

    for (const entity of ownedEntities) ownedEntityKeys.add(entity.entity);
    const recordCounts = {};
    for (const entity of ownedEntities) {
      if (entity.recordCount !== null) recordCounts[entity.entity] = entity.recordCount;
    }
    const nativeRefs = Array.from(new Set(ownedEntities.map((entity) => entity.proposedCapability)))
      .flatMap((capability) => capabilityRefs.get(capability) || []);
    const via = nativeRefs.length > 0 ? 'api' : 'cms';
    const names = ownedEntities.map((entity) => entity.displayName).join(', ');
    rows.push({
      capability: `derived:${installed.plugin}`,
      recognized: false,
      basis: 'proposed',
      plugins: [installed.plugin],
      sourceEntities: ownedEntities.map((entity) => entity.entity).sort(),
      recordCounts,
      channels: Array.from(new Set(ownedEntities.map((entity) => entity.channel))).sort(),
      channel: 'core-cpt',
      profileVersion: null,
      status: 'migration-planned',
      via,
      confidence: 'proposed',
      targetRefs: via === 'api' ? Array.from(new Set(nativeRefs)).sort() : [...GENERIC_TARGET_REFS],
      pitfalls: [],
      blocked: [],
      hierarchicalEntities: ownedEntities.filter((entity) => entity.hierarchical).map((entity) => entity.entity),
      userImpact: via === 'api'
        ? `${names} appears to match a native Wix entity. We derived this mapping rather than authored it, so it is proposed and needs your confirmation at the mapping review.`
        : `${names} will come across as CMS collections, keeping original record IDs. We derived this mapping rather than authored it, so review it at the mapping review.`,
      action: null,
    });
    attributed.add(installed.plugin);
  }

  // Derived (unrecognized but readable) entities with no confidently-matched plugin owner,
  // grouped by proposed capability so the report stays one row per capability rather than one
  // row per derived post type. The proposal is matched against the domain KB: a confirmed
  // match maps via API, the same as a profiled plugin — but as `proposed`, decided at the
  // mapping review, never by automation alone.
  const genericByCapability = new Map();
  for (const entity of genericEntities) {
    if (ownedEntityKeys.has(entity.entity)) continue;
    if (!genericByCapability.has(entity.proposedCapability)) genericByCapability.set(entity.proposedCapability, []);
    genericByCapability.get(entity.proposedCapability).push(entity);
  }
  for (const [capability, group] of genericByCapability) {
    const recordCounts = {};
    for (const entity of group) {
      if (entity.recordCount !== null) recordCounts[entity.entity] = entity.recordCount;
    }
    const nativeRefs = capabilityRefs.get(capability) || [];
    const via = nativeRefs.length > 0 ? 'api' : 'cms';
    const names = group.map((entity) => entity.displayName).join(', ');
    rows.push({
      capability,
      recognized: false,
      basis: 'proposed',
      plugins: [],
      sourceEntities: group.map((entity) => entity.entity).sort(),
      recordCounts,
      channels: Array.from(new Set(group.map((entity) => entity.channel))).sort(),
      channel: 'core-cpt',
      profileVersion: null,
      status: 'migration-planned',
      via,
      confidence: 'proposed',
      targetRefs: via === 'api' ? [...nativeRefs].sort() : [...GENERIC_TARGET_REFS],
      pitfalls: [],
      blocked: [],
      hierarchicalEntities: group.filter((entity) => entity.hierarchical).map((entity) => entity.entity),
      userImpact: via === 'api'
        ? `${names} appears to match a native Wix entity. We derived this mapping rather than authored it, so it is proposed and needs your confirmation at the mapping review.`
        : `${names} will come across as CMS collections, keeping original record IDs. We derived this mapping rather than authored it, so review it at the mapping review.`,
      action: null,
    });
  }

  for (const unprofiled of unprofiledRoutes) {
    const read = unprofiled.read !== false;
    rows.push(read ? {
      capability: `unknown:${unprofiled.namespace}`,
      recognized: false,
      basis: 'proposed',
      plugins: [],
      sourceEntities: unprofiled.routes,
      recordCounts: {},
      channels: ['plugin-rest'],
      channel: 'plugin-rest',
      profileVersion: null,
      status: 'migration-planned',
      via: 'cms',
      confidence: 'proposed',
      targetRefs: [...GENERIC_TARGET_REFS],
      pitfalls: [],
      blocked: [],
      userImpact: `Records under ${unprofiled.namespace} look durable but we do not recognise the plugin that owns them. They were accepted by shape and will map to CMS collections unless you exclude them.`,
      action: null,
    } : {
      // Collection-shaped routes in an unrecognized namespace, deliberately not read (reading
      // them speculatively pulled in cookie-consent and object-cache config on a real store).
      // They surface as Pending so silence cannot read as "this plugin has nothing".
      capability: `unknown:${unprofiled.namespace}`,
      recognized: false,
      basis: 'proposed',
      plugins: [],
      sourceEntities: unprofiled.routes,
      recordCounts: {},
      channels: ['plugin-rest'],
      channel: 'plugin-rest',
      profileVersion: null,
      status: 'pending',
      reason: 'collection-shaped routes in an unrecognized namespace; not read by default',
      searched: [],
      targetRefs: [],
      pitfalls: [],
      blocked: [],
      userImpact: `${unprofiled.namespace} exposes ${unprofiled.routes.length} collection-style route(s) that look like they hold records, but we do not recognise this plugin and did not read them. If this plugin holds data you need, tell us and we will add support.`,
      action: 'Confirm whether this plugin holds data you need migrated.',
    });
  }

  // An installed-but-unprofiled plugin whose namespace IS being read is not unreadable — it is
  // unrecognized but covered by the generic tier. Attribute it to that row instead of emitting
  // a second, contradictory row that tells the user their data will not migrate when it will.
  // Runs unconditionally (not gated on the ownership attribution above): a plugin can genuinely
  // own both a generic CPT/taxonomy AND a separate unread custom namespace at once (MailPoet:
  // `mailpoet_email` CPT is owned and readable, `mailpoet/v1`'s 9 routes are a distinct,
  // unread namespace) — both facts belong on its row, not just whichever attributed first.
  for (const installed of detection?.installedButUnprofiled || []) {
    const tokens = pluginTokens(installed);
    const namespaceRow = unprofiledRoutes.find((entry) => tokens.some((token) => normalizeToken(entry.namespace.split('/')[0]) === token));
    if (namespaceRow) {
      const row = rows.find((candidate) => candidate.capability === `unknown:${namespaceRow.namespace}`);
      if (row) {
        row.plugins.push(installed.plugin);
        attributed.add(installed.plugin);
      }
    }
  }

  for (const installed of detection?.installedButUnprofiled || []) {
    if (attributed.has(installed.plugin)) continue;
    const slug = String(installed.plugin || '').split('/')[0];
    const hint = hintsBySlug.get(slug);
    if (hint) {
      // The no-migration-needed list: nothing to move. The row carries its rationale and is
      // marked `basis: list`, so the mapping review can see the answer came from the list
      // (the agent confirms it there — a list hit alone is evidence, not the decision).
      rows.push({
        capability: `no-migration-needed:${slug}`,
        recognized: false,
        basis: 'list',
        plugins: [installed.plugin],
        sourceEntities: [],
        recordCounts: {},
        channels: [],
        channel: null,
        profileVersion: null,
        status: 'no-need-to-migrate',
        reason: normalizeNoMigrationReason(hint.reason || hint.disposition),
        replacedBy: hint.replacedBy || null,
        rationale: [hint.does, hint.provenance ? `(${hint.provenance})` : null].filter(Boolean).join(' ')
          || 'Listed on the no-migration-needed list.',
        targetRefs: [],
        pitfalls: [],
        blocked: [],
        userImpact: hint.replacedBy || `${installed.name || slug} needs no data migration: ${hint.does || 'nothing to move'}.`,
        action: null,
      });
      continue;
    }
    // "cannot tell": an unrecognized plugin we can read no intent from. This is a
    // statement about OUR knowledge — the honest exit that stops classification from becoming
    // a silent way to drop data. Decided by a human at the mapping review, the only exit from
    // Pending. Deliberately says "could not identify", not "exposes no data": without a
    // profile we cannot tell whether it has no readable data or data we failed to attribute.
    rows.push({
      capability: `unknown-plugin:${installed.plugin}`,
      recognized: false,
      basis: 'proposed',
      plugins: [installed.plugin],
      sourceEntities: [],
      recordCounts: {},
      channels: [],
      channel: null,
      profileVersion: null,
      status: 'pending',
      reason: 'cannot-tell',
      searched: [],
      targetRefs: [],
      pitfalls: [],
      blocked: [],
      userImpact: `${installed.name || installed.plugin} is installed but we could not identify any migratable data for it. If it holds data you need, it will not migrate as things stand.`,
      action: 'Tell us if this plugin holds data you need; it may need an export file or plugin support added.',
    });
  }

  // Fingerprinted plugins — public evidence only, so typically an unauthenticated run
  // (detectPlugins already deduplicates against the installed list). Each classifies exactly
  // like an installed-but-unrecognized plugin: the no-migration-needed list can
  // clear it, otherwise it is Pending — never silently fine, and never a route in scope.
  for (const print of detection?.fingerprinted || []) {
    const hint = hintsBySlug.get(print.slug) || hintsBySlug.get(print.token);
    const name = print.displayName || print.token;
    if (hint) {
      rows.push({
        capability: `no-migration-needed:${print.slug}`,
        recognized: false,
        basis: 'list',
        plugins: [print.slug],
        sourceEntities: [],
        recordCounts: {},
        channels: [],
        channel: null,
        profileVersion: null,
        status: 'no-need-to-migrate',
        reason: normalizeNoMigrationReason(hint.reason || hint.disposition),
        replacedBy: hint.replacedBy || null,
        rationale: [hint.does, hint.provenance ? `(${hint.provenance})` : null].filter(Boolean).join(' ')
          || 'Listed on the no-migration-needed list.',
        targetRefs: [],
        pitfalls: [],
        blocked: [],
        fingerprintEvidence: print.evidence,
        userImpact: hint.replacedBy || `${name} needs no data migration: ${hint.does || 'nothing to move'}.`,
        action: null,
      });
      continue;
    }
    rows.push({
      capability: `fingerprinted:${print.token}`,
      recognized: false,
      basis: 'proposed',
      plugins: [print.slug],
      sourceEntities: [],
      recordCounts: {},
      channels: [],
      channel: null,
      profileVersion: null,
      status: 'pending',
      reason: 'cannot-tell',
      searched: [],
      targetRefs: [],
      pitfalls: [],
      blocked: [],
      fingerprintEvidence: print.evidence,
      userImpact: `${name} is visible on the site (public fingerprint) but we could not read what it holds${print.aliasMatched ? '' : ' and do not recognise it'}. If it holds data you need, it will not migrate as things stand.`,
      action: 'Tell us if this plugin holds data you need; an administrator credential or plugin support may be required.',
    });
  }

  for (const row of rows) row.plugins = Array.from(new Set(row.plugins)).sort();
  return rows.sort((a, b) => a.capability.localeCompare(b.capability));
}

const NO_MIGRATION_REASONS = new Set(['platform-does-it', 'not-needed', 'reconfigure-in-wix']);

// Accept the legacy `platform-replaced` value so a stale vendored list cannot crash a run;
// the shipped list uses the spec vocabulary.
function normalizeNoMigrationReason(value) {
  if (NO_MIGRATION_REASONS.has(value)) return value;
  if (value === 'platform-replaced') return 'platform-does-it';
  return 'not-needed';
}

function normalizeToken(value) {
  return String(value || '').toLowerCase().replace(/[^a-z0-9]/g, '');
}

// Identity tokens for an installed plugin: its directory slug and its textdomain. Both are
// conventionally derived from the same name, which is what makes namespace correlation work.
function pluginTokens(installed) {
  const tokens = new Set();
  const dir = String(installed.plugin || '').split('/')[0];
  if (dir) tokens.add(normalizeToken(dir));
  if (installed.textdomain) tokens.add(normalizeToken(installed.textdomain));
  return Array.from(tokens).filter(Boolean);
}

function describeImpact(row, entities) {
  // A signed "nothing to move" row is not a loss report: whatever its entities' pitfalls say
  // about unmovable fields, the decision already accounts for them. The verdict is what the
  // customer reads, and the rationale on the row carries the detail.
  if (row.status === 'no-need-to-migrate') {
    return [
      row.replacedBy
        ? `${row.capability} needs no data migration: ${row.replacedBy}.`
        : `${row.capability} needs no data migration.`,
      row.decidedBy ? `Decided by ${row.decidedBy}${row.decidedOn ? ` on ${row.decidedOn}` : ''}.` : null,
    ].filter(Boolean).join(' ');
  }
  const blockers = entities.flatMap((entity) => entity.pitfalls).filter((pitfall) => pitfall.severity === 'blocker');
  if (blockers.length > 0) return blockers[0].summary;
  switch (row.status) {
    case 'migration-planned':
      return row.via === 'api'
        ? `${row.capability} comes across into a native Wix entity.`
        : `${row.capability} comes across into Wix CMS collections, keeping original record IDs. Wix has no matching feature, so the data is preserved but nothing acts on it until a page is built against it.`;
    case 'manual-mapping':
      return `${row.capability} is a complete, decided mapping — Wix can do this, but reaching it takes a few steps you click through yourself, not something our code writes for you.`;
    case 'requires-development':
      return `${row.capability} has no Wix surface today; someone has to build it before this data can move.${row.decidedBy ? ` Decided by ${row.decidedBy}.` : ''}`;
    case 'pending':
      return `${row.capability} is not resolved yet — we do not know how to migrate it. Our open item, pending our review; never a statement that Wix cannot do it.`;
    default:
      return `${row.capability} coverage status: ${row.status}.`;
  }
}

function describeAction(row) {
  if (row.status === 'pending') {
    return 'Tell us if this capability is needed for your migration so we can prioritise resolving it.';
  }
  return null;
}

function coverageSummary(rows) {
  const byStatus = {};
  const byVia = {};
  const byConfidence = {};
  let recognized = 0;
  for (const row of rows) {
    byStatus[row.status] = (byStatus[row.status] || 0) + 1;
    if (row.recognized) recognized += 1;
    if (row.status === 'migration-planned') {
      byVia[row.via] = (byVia[row.via] || 0) + 1;
      byConfidence[row.confidence] = (byConfidence[row.confidence] || 0) + 1;
    }
  }
  return {
    capabilities: rows.length,
    recognized,
    byStatus: Object.fromEntries(Object.entries(byStatus).sort(([a], [b]) => a.localeCompare(b))),
    byVia: Object.fromEntries(Object.entries(byVia).sort(([a], [b]) => a.localeCompare(b))),
    byConfidence: Object.fromEntries(Object.entries(byConfidence).sort(([a], [b]) => a.localeCompare(b))),
    // The batched blocked-but-recoverable ask (J1 step 9): everything here is asked once,
    // individually skippable, and never a mapping decision.
    blocked: rows
      .filter((row) => (row.blocked || []).length > 0)
      .map((row) => ({ capability: row.capability, status: row.status, blocked: row.blocked })),
  };
}

function summarizeDetection(inventory) {
  return {
    pluginListAvailable: Boolean(inventory.pluginListAvailable),
    detected: (inventory.detected || []).map((plugin) => ({
      plugin: plugin.plugin,
      confidence: plugin.confidence,
      capabilities: plugin.capabilities,
      channels: Array.from(new Set((plugin.entities || []).map((entity) => entity.channel))).sort(),
    })),
    unprofiledNamespaces: (inventory.unprofiled || []).map((entry) => entry.namespace),
    installedButUnprofiledCount: (inventory.installedButUnprofiled || []).length,
    fingerprintedCount: (inventory.fingerprinted || []).length,
  };
}

// Collect record property keys from sampled entities so core-embedded and core-meta plugins
// — the ones that add no REST route at all — are detectable at all. Top-level keys catch
// core-embedded injections (e.g. yoast_head_json). Registered postmeta (core-meta) is a
// different shape: WooCommerce/WordPress expose it as entries inside a `meta_data` array
// (`[{key, value}, ...]`), not as a literal top-level property — several major WooCommerce
// extensions (Meta for WooCommerce's `_wc_facebook_*` keys, Discount Rules' `_wdr_discounts`)
// store their data exactly this way, so meta_data keys are collected into the same set a
// core-meta profile's recordProperties/propertyPath is checked against.
//
// An order's own meta_data is one layer; WooCommerce order LINE ITEMS carry their own,
// nested one layer deeper still (VERIFIED 2026-08-11 against the woo-discount-rules plugin
// source: it writes `_wdr_discounts` to the order item via `setOrderItemMeta`, not just to
// the order). Same failure shape as the order-level case, one layer in — so line_items[]
// meta_data is scanned too, or a per-item-only key would stay invisible to detection.
function collectRecordProperties(entities) {
  const properties = new Set();
  const collectMetaDataKeys = (record) => {
    if (!record || typeof record !== 'object' || !Array.isArray(record.meta_data)) return;
    for (const meta of record.meta_data) {
      if (meta && typeof meta.key === 'string') properties.add(meta.key);
    }
  };
  for (const entity of entities || []) {
    for (const record of entity.sampleRecords || []) {
      if (!record || typeof record !== 'object') continue;
      for (const key of Object.keys(record)) properties.add(key);
      collectMetaDataKeys(record);
      if (Array.isArray(record.line_items)) {
        for (const lineItem of record.line_items) collectMetaDataKeys(lineItem);
      }
    }
  }
  return Array.from(properties).sort();
}

module.exports = {
  COVERAGE_STATUSES,
  SIGNAL_CONFIDENCE,
  GENERIC_TARGET_REFS,
  detectPlugins,
  describeProfiledEntity,
  collectUnprofiledRoutes,
  collectCandidateNamespaces,
  deriveGenericEntities,
  proposeCapability,
  classifyCoverage,
  coverageSummary,
  summarizeDetection,
  collectRecordProperties,
  compareVersions,
};

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

What our scanner noticed· Medium risk

  • Possible data-exfiltration endpoints
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Wix
Publisher
Wix (Official)
Source
wix/skills · wix-replatform/resources/rp-source-wordpress · commit d168bc2
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Wix.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download rp-source-wordpress.zip