Download the PHP package automattic/blocks-engine-php-transformer without Composer

On this page you can find all versions of the php package automattic/blocks-engine-php-transformer. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of automattic/blocks-engine-php-transformer

Informations about the package blocks-engine-php-transformer

PHP Transformer

Read-only package mirror: the standalone repository Automattic/blocks-engine-php-transformer is an automated subtree split of the Automattic/blocks-engine monorepo's php-transformer/ directory. Development, issues, and pull requests happen in Blocks Engine.

PHP Transformer is a PHP primitive for converting source content and generated website artifacts into WordPress-native block outputs.

This package is intentionally origin-clean: it exposes transformer primitives and result contracts without publishing compatibility wrappers or product adapters for downstream plugins.

This package's canonical identity is automattic/blocks-engine-php-transformer, exposed through the Automattic\BlocksEngine\PhpTransformer\ namespace.

For local WordPress consumers, the same directory can also be installed as a plugin. The plugin bootstrap is intentionally thin: it loads the canonical library and exposes helper functions that return the same result envelopes as the class APIs.

Boundary

PHP Transformer owns reusable transformation primitives:

PHP Transformer does not own product workflows such as importer admin screens, uploaded ZIP intake, theme activation, Studio-specific orchestration, WordPress.com deployment behavior, or self-improving loop control. Product-specific compatibility wrappers belong in downstream packages, not in the canonical package API.

Namespace Map

Public API Surface

Consumers should treat these classes and interface as the public entrypoints for the current package:

The remaining classes in src/HtmlToBlocks, src/FormatBridge, and src/ArtifactCompiler are implementation details. Concrete bundled adapters, registries, normalizers, and factories may change as the bridge expands.

Staged Artifact Compilation

ArtifactCompiler also supports resumable, source-agnostic artifact preparation when shared resources are reused across page batches. prepareShared($artifact) returns a serializable immutable shared plan. preparePage($artifact, $sharedPlan, $pageId) returns one independently validated page plan bound to the shared digest, while preparePages($artifact, $sharedPlan) creates every equivalent page plan after one whole-artifact partition for efficient fan-out. compilePage($artifact, $sharedPlan, $pageId) adds a digest-bound compiled document receipt that can be persisted by a worker; compilePreparedPages($sharedPlan, $pagePlans) produces the same independent receipts while retaining bounded immutable analysis across one worker batch. compose($sharedPlan, $pagePlans) verifies every digest, canonicalizes page and file order, and reuses compiled receipts when every supplied page has one; uncompiled plans retain the existing result-envelope behavior.

File ownership is generic artifact metadata: metadata.compilation is either array('scope' => 'shared') or array('scope' => 'page', 'id' => '...'). In its absence, normalized HTML files are page-owned by path and other files are shared. The plan arrays contain their limits, diagnostics, normalized input summaries, payloads, and generic blocks-engine/php-transformer/source-operation/v1 identity, so callers can serialize them between preparation and composition. Source hashes are path-canonical and composition retains the whole-artifact input-key provenance. compile() remains the compatible whole-artifact entrypoint; completed staged receipts skip per-document transformation during final canonical aggregation.

Canonical Examples

WordPress Plugin Usage

Install or symlink the php-transformer/ directory into wp-content/plugins/blocks-engine-php-transformer/, run composer install --no-dev inside the plugin directory when Markdown conversion is needed, and activate Blocks Engine PHP Transformer.

The plugin does not register product workflows. It only makes the canonical transformer available to WordPress plugins that want to depend on it before Composer distribution is settled.

Available plugin helpers:

Diagnostics And Unsupported Paths

Public transformation entrypoints return TransformerResult wherever a conversion can partially succeed or needs structured diagnostics. Result diagnostics include a stable code, human-readable message, and source class.

Transformation Options

Public entrypoints accept a generic options array. source and scope are copied into provenance metadata so wrappers can identify the caller-owned source without making the transformer package depend on that wrapper. The same values can be nested under provenance.

HtmlTransformer, FormatBridge::convertResult() with an html source, and ArtifactCompiler::compileFragment() with html accept validation_evidence as full (the default) or compact; explicit null and every other value are rejected. Full preserves the established report envelope. Compact retains validator status and complete findings, but semantic-parity report projections explicitly omit the landmark and navigation-menu inventories with an evidence.detail/evidence.omitted declaration; its duplicated conversion_report.semantic_parity projection matches. Non-HTML FormatBridge conversions do not produce these HTML validation reports. ArtifactCompiler::compile() has no generic options argument and staged artifact APIs do not expose per-document validation reports, so compact evidence does not apply to full artifact compilation.

context.strict and context.allow_fallbacks are normalized into the result context. Top-level strict and allow_fallbacks are also accepted for simple callers. HtmlTransformer keeps default fallback behavior unchanged; callers that pass allow_fallbacks => false receive success_with_warnings, or failed when strict is also true and unsupported HTML is encountered.

FormatBridge::convertResult() forwards the original options array to adapters and exposes the normalized context/provenance metadata on the returned TransformerResult.

The result envelope includes generic metrics for wrapper reporting: input_bytes, block_count, fallback_count, diagnostic_count, transform_duration_ms, and output_bytes.

source_reports.html.source_provenance exposes bounded source context for converted blocks: selector, safe source attributes, sanitized source fragment, ancestor context, nearby heading text, safe data-* attributes, and generic structure hints such as card-like or grid-like wrappers. source_reports.html.structure_signals records those card/grid/static layout hints separately so callers can inspect them without relying on block attributes.

source_reports.conversion_report exposes a compact generic projection for wrappers that previously reconstructed report slices from lower-level result fields. It includes fallback diagnostics, sanitized fallback context, event attribute projections, source/selector summaries, asset references, navigation candidates, presentation and structure signals, and metrics. Routes, navigation, menus, and theme writes are self-contained in wordpress-site-plan/v2; callers still own media imports, navigation entity creation, visual repair policy, and acceptance gates.

Core Block Inventories

HTML conversion coverage and source_reports.conversion_report distinguish three inventories: runtime_registered_blocks contains the live WP_Block_Type_Registry core names, bundled_snapshot_blocks contains every block in the packaged metadata snapshots, and supported_blocks contains only transformer emitters with a contract verification. runtime_registered_blocks is null when no registry is loaded and [] when a live registry is present but has no core blocks; runtime_available_blocks remains the effective target inventory and uses bundled snapshot knowledge only when no registry is loaded. Live-only names remain unclassified_runtime_blocks and never become supported output.

Visual parity tooling should use the product-neutral report/config contracts in docs/contracts/visual-parity-report.md. The report covers source and target render metadata, viewports, optional screenshot paths, DOM candidate matches, computed-style deltas, optional visual diff metrics, severity, selector evidence, and recommendations. Button, menu, card, and form fields are modeled as generic UI facts rather than product-specific entities.

WordPress materializers that consume the self-contained wordpress-site-plan/v2 contract should use WordPressSitePlan\WordPressSitePlanView::fromResult(). It preserves the exact canonical plan plus Gutenberg gaps, companion-plugin payload, font materialization metadata, and plan diagnostics while omitting the duplicated compiled-site, root asset, document, and block projections.

HtmlTransformer preserves syntax-highlight spans inside <pre><code> when they use safe inline tags and bounded attributes, while plain code remains escaped as text. Figure-wrapped testimonials and quote shapes are normalized to core quote or pullquote blocks with attribution from cite, footer, or figcaption content.

Use FormatBridge::convertResult() for format conversions and unsupported source or target format diagnostics:

FormatBridge::normalize(), FormatBridge::toBlocks(), and FormatBridge::convert() remain available for compatibility wrappers that must preserve older string or array return types. New consumers should prefer convertResult() and read documents, blocks, serialized_blocks, and diagnostics from the result envelope.

Artifact Compiler Fallbacks

The artifact compiler accepts loose generated-site bundles and normalizes them into an explicit result envelope. Safe HTML entries are compiled through HtmlTransformer into native serialized block markup, Markdown falls back to core/html when a Markdown adapter is not loaded, and MDX support is partial: source documents are preserved while imports and JSX component references are exposed as inspectable metadata and warnings.

Unsupported or unsafe artifact inputs are reported through diagnostics instead of hidden best-effort behavior. Empty, absolute, or root-escaping paths are rejected; oversized files are ignored according to the source report limits; and a bundle with neither an HTML entry nor source documents fails with missing_entry_html.

WordPress Site Plans

WordPressSitePlan projects a self-contained blocks-engine/wordpress-site-plan/v2 materialization contract from a compiler result. Its normalized document metadata and generic reporting summaries let a consumer project reports from a resolved plan plus its own receipt, without reading the compiler envelope or source files. See WordPress Site Plan v2 for the metadata shape, ordering, supported attributes, and resolver boundary.

Parity Checks

Run the package contract, parity fixtures, and clean package-install proof with composer test. The checked-in fixtures assert current transformer behavior, and the install proof verifies that Composer can install automattic/blocks-engine-php-transformer from the php-transformer/ package root without symlinking back to the working tree.

Run the real WordPress materialization integration against a standard WordPress test-suite runtime with REQUIRE_WP_TESTS=1 WP_TESTS_DIR=/path/to/wordpress-develop/tests/phpunit composer test:wordpress-integration. Without REQUIRE_WP_TESTS=1, the command reports an explicit local skip when that runtime is unavailable. CI provisions WordPress 7.0.4, MySQL 8.0.36, and runs the required form of this command in .github/workflows/php-transformer.yml.

Release Consumption

The package lives in a subtree of the Blocks Engine repository. Composer cannot discover a package whose composer.json is below the repository root from a plain monorepo VCS tag, so releases are published through an automated subtree split: .github/workflows/php-transformer-split.yml pushes package-only history to Automattic/blocks-engine-php-transformer, translating each php-transformer-vX.Y.Z monorepo tag to vX.Y.Z on the mirror. Packagist indexes the mirror.

This package intentionally omits replace and provide declarations for the older downstream package names. Those packages expose their own WordPress plugin bootstraps, functions, hooks, CLI commands, abilities, and product-shaped reports, so the canonical transformer package should not satisfy their Composer requirements directly.

Preferred downstream constraint from Packagist:

If the first release is only available as a Blocks Engine monorepo archive, downstream consumers can avoid local path repositories with this repository entry, replacing <release-tag> with the pushed release tag:

Before the first tag is available, review branches may use a Composer VCS or path repository with an inline alias. Merge-ready downstream PRs should replace those review-only constraints with one of the no-local-path release shapes above.

Release Readiness Checklist

Reviewer-safe checks before approving the first package release PR:

Operator-only release checklist after the release-readiness PR merges:

Homeboy owns the local release preflight for this package through php-transformer/homeboy.json. Run Homeboy with php-transformer/ as the component path so release automation detects the monorepo path and uses php-transformer-v* tags, without adding wrapper-package names to this package metadata.

Recommended post-merge dry-run:

When running from outside the package directory, pass the package path explicitly:

Recommended first release command after the dry-run passes and the merge commit is ready to tag:

Use --skip-publish because Composer/Packagist consumption should follow the repository tag, and use --no-github-release when GitHub Releases are not part of the first package publication path. Do not run release commands from downstream wrapper branches or while path repositories, unpublished branch constraints, or local-only evidence are still required by merge candidates.

All versions of blocks-engine-php-transformer with dependencies

PHP Build Version
Package Version
Requires league/commonmark Version ^2.5
league/html-to-markdown Version ^5.1
php Version >=8.2
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package automattic/blocks-engine-php-transformer contains the following files

Loading the files please wait ...