wp-php-toolkit/reprint-importer

Retry interrupted SQL source responses in the current importer run (#…

Migrations (especially scoped ones with --only :wp-content:) don't
have a great option for symlinks that point outside the pulled scope.
Bare --follow-symlinks pulls the content but mirrors it at its raw
source paths, scattered across the docroot. --no-follow-symlinks just
drops it, leaving dangling links.

This PR adds a destination form:
--follow-symlinks=:fs-root:/.symlinks-bundle. Escaping targets get
followed and consolidated into one private in-tree directory, nested by
source path, and their symlinks are repointed there. A scoped wp-content
pull ends up self-contained: no dangling links, no junk in the docroot.

Placement: remap rules first, then the bundle location if set, then
the default fs-root mirror. Anything inside a remapped wp-content lands
in the served tree, so the bundle only receives genuinely-external
content. Multiple links to one target share a single copy. Relative and
absolute targets are handled the same. Bare --follow-symlinks is
equivalent to --follow-symlinks=:fs-root: (the unchanged default), and
the value uses the --remap target grammar — it must stay within
--fs-root.

Resume guard: the bundle directory is fingerprinted on the first run
and checked on every run after. Changing (or dropping) it errors instead
of silently splitting placement; --abort resets it. Setting a bundle
directory also persists follow_symlinks=true, so a flag-less delta
can't index with follow off and delete previously-followed content.

Behavior changes (both previously produced missing content and
dangling links):

1. Under a narrow --only, followed targets outside the --only scope
   are now pulled. They used to be skipped as "already covered" because
   they sat under a preflight root, even though the scoped pull never
   actually downloaded them.
2. Symlinks in the middle of a followed path (e.g. /srv/wordpress → /wordpress) are now repointed at the locally-mirrored content, like
   every other symlink. They used to be skipped whenever their absolute
   target pointed outside --fs-root, even when the content itself had
   been downloaded.

Testing

The new SymlinkBundleTest (unit) + import-52-symlink-bundle (e2e,
broad + narrow --only) cover lots of cases here.

For manual testing though, the setup would be rather intense. You'll
need something like a symlinked plugin that points outside wp-content.
Then run --only :wp-content: --follow-symlinks=:fs-root:/.symlinks-bundle and ensure the plugin's
source ended up in the new bundle location.

Better prior-op understanding for `files-sync --filter=skipped-earlie…

• Fix the runtime missing certain files
• Fix local runtime file serving logic

These changes make it possible to run a pull-ed site using the local
sqlite runtime, e.g.:

php importer/import.php pull https://mymigrationwpcloudsite.wpcomstaging.com/ \
  --secret=SECRET_GOES_HERE\
  --state-dir=./exports/state --fs-root=./exports/files \
  --new-site-url=http://localhost:8881

Retargets wp-php-toolkit/reprint-exporter#1 into the monorepo package path.

Also adds README files to the split Composer package directories explaining that the wp-php-toolkit package repositories are read-only mirrors and that changes should be proposed against adamziel/reprint.

Co-Authored-By: Luca Tumedei [email protected]
Co-Authored-By: Claude Opus 4.7 (1M context) [email protected]

Prepare reprint v0.8.0 release

Bump php-toolkit packages to 0.7.9

Summary

Picks up wp-php-toolkit
v0.7.3,
which fixed the published-package autoload regressions caught by
WordPress/php-toolkit#264. The most relevant fixes for reprint:

• [email protected] now correctly declares its dependency on
  wp-php-toolkit/html
• [email protected] no longer eagerly declares WP_Error through
  autoload.files
• Various optional integrations bundled in vendored Symfony / webuni
  packages are excluded from the classmap

Changes

• packages/reprint-exporter/composer.json: ^0.7.2 -> ^0.7.3 for
  data-liberation and html
• packages/reprint-importer/composer.json: same
• composer.lock refreshed; all transitive toolkit packages resolve to
  v0.7.3

Test plan

• composer update wp-php-toolkit/data-liberation wp-php-toolkit/html
  resolves cleanly to v0.7.3 across all transitive packages
• composer compat (PHP 7.4 compatibility) passes
• ExportLibraryLoadTest and BuildPdoDsnTest pass locally
• PHPUnit matrix green on CI

Picks up the v0.7.2 fixes — PSR-4 vs WP class-*.php naming, the
WP-coexistence regression where html5-named-character-references.php
loaded WP_Token_Map at composer bootstrap (caused fatals in any
consumer that also loads WordPress, e.g. wpcomsh tests), and the
package-bootstrap fatals from v0.7.0/v0.7.1.

Picks up the v0.7.2 fixes — PSR-4 vs WP class-*.php naming, the
WP-coexistence regression where html5-named-character-references.php
loaded WP_Token_Map at composer bootstrap (caused fatals in any
consumer that also loads WordPress, e.g. wpcomsh tests), and the
package-bootstrap fatals from v0.7.0/v0.7.1.