fix(preview): keep the block preview working past a few hundred images - #345
Merged
Merged
Conversation
Fails before the fix: the settings after `images` are dropped past max_input_vars, and a rejected preview request crashes the block.
A field per value ran past max_input_vars on a gallery of a few hundred images, and PHP dropped every setting after `images`. Hosts that cap the field count rejected the request outright, and the error page they served broke the editor's next read of the preview frame's window, crashing the block. That read only ever wrote an `undefined` key, so it goes.
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
1 participant
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.
The block editor posted every attribute value as its own form field, and a Media source gallery sends three to five fields per image. At a few hundred images this passes PHP's
max_input_vars(1000 by default). PHP then drops everything afterimages, so the preview renders with default settings. A host that caps the field count, usually through a WAF, rejects the request outright and serves its own error page. That page has noDocument-Isolation-Policy, so on the first setting change the editor's read offrameWindow.vp_preview_post_datathrew aSecurityErrorand crashed the block with "This block has encountered an error".The attributes now go as one JSON field, which
print_template()unpacks into the fields it used to get, so the preview POST carries 7 fields at any gallery size. The crashing read is gone. It wrotedata.valueunderdata.name, and neither exists on that payload, so it only ever set anundefinedkey.Not reproduced here: the reporter's host rejects the request, and wp-env only truncates it. The rejection was modelled by answering the preview POST with a 403, which gives the exact console error from the report. Whether one large JSON field also passes that host's WAF is unproven.
Below the limit nothing changes. For 140 images,
vp_preview_post_dataand the.vp-portfolioattributes match before and after, apart from the nonce, the post id and the timestamp. Saved layouts and the Elementor preview still post flat fields, andprint_template()reads those as before.gallery-preview-many-images.spec.jsfails on the first commit (3 items expected, 6 rendered, and the block crashes) and passes with the fix. Full e2e run: 210 passed.Reported in https://wordpress.org/support/topic/visual-portfolio-block-preview-breaks-with-211-media-items/