WIP: Add hierarchical block validation system with 6-level classification#70853
Closed
lezama wants to merge 3 commits intoWordPress:trunkfrom
Closed
WIP: Add hierarchical block validation system with 6-level classification#70853lezama wants to merge 3 commits intoWordPress:trunkfrom
lezama wants to merge 3 commits intoWordPress:trunkfrom
Conversation
Implements a more nuanced block validation system as proposed in WordPress#21703, replacing the binary valid/invalid approach with a 6-level hierarchy that provides better context for validation outcomes and data preservation. ## Changes Made ### Core Validation System - **Enhanced validateBlock()**: Now returns `[isValid, validationIssues, validationType]` tuple instead of just `[isValid, validationIssues]` - **Classification Logic**: Added `classifyValidationResult()` to determine validation type based on content analysis and migration status - **Validation Types**: 6 hierarchical levels from most valid (0) to least valid (5) ### Validation Type Hierarchy - **Level 0 - VALID_BLOCK**: Identical content, deterministic serialization - **Level 1 - MIGRATED_BLOCK**: Successfully migrated via block deprecations - **Level 2 - PRESERVED_SOURCE**: HTML matches despite attribute differences - **Level 3 - RECONSTRUCTED_SOURCE**: Rebuildable from consistent attributes - **Level 4 - RAW_TRANSFORMED_SOURCE**: Transformable to raw/freeform content - **Level 5 - INVALID_BLOCK**: Requires user intervention ### Parser Integration - **applyBlockValidation()**: Updated to handle and propagate validation types - **Migration Detection**: Added `__unstableWasMigrated` flag for deprecation tracking - **Backward Compatibility**: Existing `isValidBlockContent()` continues working ### Public API - **Constants**: New `VALIDATION_RESULT_TYPE` enum with comprehensive documentation - **Utilities**: Added `getValidationTypeLevel()` and `compareValidationTypes()` helpers - **Exports**: All new functionality available via main blocks package API ## Benefits - **Better UX**: More context for users about validation outcomes - **Data Preservation**: Hierarchical approach reduces unnecessary data loss - **Extensibility**: Foundation for smarter validation handling and recovery - **Tooling**: Enables better developer tools and block validation insights ## Backward Compatibility All existing validation APIs continue to work unchanged. The new validation type is an additional return value that existing code can safely ignore. Addresses WordPress#21703 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Implements test cases based on the examples provided in GitHub issue WordPress#21703: - Level 0 (VALID_BLOCK): Identical block source and output - Level 1 (MIGRATED_BLOCK): Blocks migrated via deprecations - Level 2 (PRESERVED_SOURCE): Comment attribute differences with matching HTML - Level 3 (RECONSTRUCTED_SOURCE): Missing CSS classes but rebuildable from attributes - Level 4 (RAW_TRANSFORMED_SOURCE): Malformed HTML transformable to raw content - Level 5 (INVALID_BLOCK): Complex malformed content requiring user intervention Tests cover all validation type constants, level comparison utilities, and hierarchical classification logic using realistic block scenarios. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Fixed classification logic in classifyValidationResult() to properly handle all 6 validation levels - Improved canReconstructFromAttributes() with better heuristics for detecting rebuildable blocks - Enhanced canTransformToRawContent() to more accurately identify malformed but recoverable HTML - Fixed PRESERVED_SOURCE test to actually test equivalent but non-identical HTML (different class order/spacing) - Fixed module import from fast-deep-equal/es6 to fast-deep-equal to resolve module resolution issues - Applied proper code formatting to fix all linting/prettier issues The hierarchical validation system now properly classifies blocks into: - Level 0 (VALID_BLOCK): Exact string match between original and generated content - Level 1 (MIGRATED_BLOCK): Valid blocks that were migrated via deprecations - Level 2 (PRESERVED_SOURCE): HTML is equivalent but not identical (formatting, attribute order, etc.) - Level 3 (RECONSTRUCTED_SOURCE): Invalid blocks that can be rebuilt from attributes - Level 4 (RAW_TRANSFORMED_SOURCE): Invalid blocks with malformed but recoverable HTML - Level 5 (INVALID_BLOCK): Blocks that cannot be safely restored 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implements a hierarchical block validation system as proposed in #21703, replacing the binary valid/invalid approach with a 6-level hierarchy that provides better context for validation outcomes and data preservation.
This PR introduces a more nuanced validation system that classifies block validation results into 6 hierarchical levels, from most valid (Level 0) to least valid (Level 5). Each level represents a different degree of confidence in the block's integrity and the potential for data loss.
Validation Type Hierarchy
Changes Made
Core Validation System
validateBlock(): Now returns[isValid, validationIssues, validationType]tupleclassifyValidationResult()function__unstableWasMigratedflag for tracking deprecationsParser Integration
applyBlockValidation(): Handles and propagates new validation typesPublic API
VALIDATION_RESULT_TYPEenum with comprehensive documentationgetValidationTypeLevel()andcompareValidationTypes()helpersBenefits
Testing
Test plan
Backward Compatibility
All existing validation APIs continue to work unchanged. The new validation type is returned as an additional third element in the
validateBlock()result tuple, which existing code can safely ignore.Addresses #21703
🤖 Generated with Claude Code