Two execution-time gaps are currently handled incorrectly:
Product reviews can currently fail with:
No verified native Wix product-review primitive was identified for this workflow
Wix Blog import in public-only mode can currently stop at:
Wix Blog post import is marked IMPORT_UNRELIABLE, and original author identity is not available in public-only mode
Both failures are too coarse.
The first treats product reviews as if there is no usable native Wix target surface.
The second treats missing original member identity as a hard stop, even though Wix Blog
requires a memberId on draft-post create and RePlatform already has a native member
create primitive.
Verified live on August 2, 2026 (probe against the wporg-news migration’s
API-provisioned Wix target site, “My Site 8”):
Wix auto-creates a user-member for the site owner (and contributing Wix users) on
API-provisioned sites — no Members-area interaction needed — and Create Draft Post
accepts it from an API-key caller. So “attribute everything to the site owner” requires
zero member provisioning. Resolution contract: find it via GET /members/v1/members
(fieldsets=FULL) matching the owner’s loginEmail; the probe’s observed id equality
(member id == account GUID) is a solo-account observation and undocumented — never
construct the memberId from the account/user GUID. These auto user-members must never
be deduped against source-site members.
Post authorship is re-assignable after publish: PATCH /blog/v3/draft-posts/{id}
with { draftPost: { memberId } } followed by republish updates the published post’s
author (post id == draft id). Republish events are not suppressed by saveType=IMPORT,
so author-reassignment passes must run inside the notification-mute window.
This means:
product reviews are a native Wix target, even if our adapter does not yet expose a
dedicated verified writer
blog posts in third-party app flows must always resolve an author memberId before
POST /blog/v3/draft-posts
When the source entity is specifically a product review:
Mapping must classify it as a product-review subtype, not as a generic comment.
The selected target must remain native Wix, using the Wix Reviews domain rather than a
CMS fallback by default.
If no dedicated writer exists yet, codegen/execution must use the existing direct REST
native path pattern:
record the path as unverified
notify the RePlatform team that a dedicated writer is missing
surface the risk in the mapping and execution review artifacts
The execution path must no longer raise the specific error
No verified native Wix product-review primitive was identified for this workflow
for this case.
When importing blog posts and the source run is public-only:
RePlatform must not require the original source author identity as a blocker for native
Wix Blog import.
Instead, it must deterministically provision or resolve a fallback Wix member and use
that member as the post author.
The member should be created before the first blog post that needs it, then reused for
subsequent posts that resolve to the same fallback author strategy.
The flow must continue to record the fidelity loss:
original author identity is not preserved as a native Wix member identity in
public-only mode.
Create one fallback Wix member per distinct source author when the source has stable
public author data sufficient to derive a deterministic identity key.
If the source author is not resolvable to a distinct stable public identity, create or
reuse one project-level generic fallback author member.
Alternative for the project-level case (verified live 2026-08-02): the site owner’s
auto-created user-member is a valid author and requires no provisioning at all —
resolve it by loginEmail from the member list (never by deriving the id from the
account GUID). Use it when the user prefers “posts authored by me” over a synthetic
“Imported Author” appearing in the member list; record the choice as the
authorAttributionMode.
Rationale:
per-author fallback preserves more authorship structure when public data exists
project-level fallback still allows import to proceed when only anonymous/public post
content is available
Introduce a domain/entity entry for product reviews owned by rp-target-wix.
Recommended shape:
domain: likely reviews if a new domain is added, or another explicit target-owned
location if the current taxonomy requires it
entity: product-review
classification: native-plus-cms or native
native entity: Review
preferred write: direct REST POST to the Wix Reviews surface, initially
verification: "docs" or verification: "unverified" until live-tested
reliability: should not claim reliable/native-verified yet
pitfalls: relation/entity binding, moderation defaults, author/contact linkage, and any
required namespace or verified-purchase semantics
The important contract is that product reviews must be discoverable as a native Wix
target so mapper/codegen stop treating them as a missing primitive.
Do not remove IMPORT_UNRELIABLE from site members globally. The new behavior does not
mean members become generally faithful imports. It only means a constrained synthetic
member path is acceptable for blog authorship enablement.
The following user-facing statements must appear in generated review artifacts when
relevant:
For product reviews:
Wix has a native Reviews entity for product reviews. This migration uses an unverified native write path pending dedicated adapter verification.
For blog authorship in public-only mode:
Blog posts will be authored by fallback Wix members created for import because third-party Wix Blog post creation requires memberId and original login identity is not available in public-only capture.
Machine artifacts should also record:
chosen authorAttributionMode
fallback author key strategy
whether authorship is per-source-author fallback or project-level fallback
Wix Reviews request shape still needs product-specific live verification:
required namespace, if any
whether author is expressed as contact, member, or another actor shape
moderation defaults on create
whether verified-purchase state is writable or derived
Member dedup policy needs care if a later authenticated run provides real users that
overlap with previously-created fallback members. The re-attribution mechanics are now
verified (2026-08-02): the authenticated re-run provisions/resolves the real per-author
members, then for each fallback-attributed post PATCHes the draft memberId and
republishes — the crosswalk must therefore record authorAttributionMode (and the
author key) per post so the upgrade pass knows which posts to re-author. Remaining
policy questions: when to delete the now-orphaned fallback members (delete works —
DELETE /members/v1/members/{id} verified — but their auto-created contacts may
linger), and republish-event exposure (not IMPORT-suppressed; mute window required).
Synthetic fallback members may appear in the site’s member list; that is acceptable
for this migration path but should be disclosed in review artifacts.
Some sources expose author display text per post but no stable author identity; those
should fall back to the project-level generic member unless a deterministic per-author
key can be justified from public data.