Use input_substr to retrieve text#3
Merged
nylen merged 1 commit intonylen:masterfrom Nov 30, 2017
aduth:fix/text-input-substr
Merged
Use input_substr to retrieve text#3nylen merged 1 commit intonylen:masterfrom aduth:fix/text-input-substr
nylen merged 1 commit intonylen:masterfrom
aduth:fix/text-input-substr
Conversation
Author
|
Related: WordPress/gutenberg#3545 |
Owner
|
I agree with the code change itself (and this PR will fix #2), however:
With this change, there are no longer any tests for the Then, to fix the build, we'll need to update the PHP 5.2 versions of the test grammars. I can help with any/all of this and release a new version when we're done, just let me know how you'd like to proceed. |
Owner
|
Rebasing after #5 may also help fix the build here. |
Author
|
I rebased and restored the original |
Owner
|
LGTM, thanks! |
Closed
aduth
added a commit
to WordPress/gutenberg
that referenced
this pull request
Nov 30, 2017
A parsed block has no awareness of where inner blocks exist in its innerHTML, so it cannot safely reserialize. There are a few options: - Since we merely skip wpautop for known blocks, we could avoid reserialization and return the block's original HTML verbatim if we had access to its outerHTML. See nylen/phpegjs#3 - Move wpautop behavior for freeform content to the editor client. This may align well with desires to transparently upgrade legacy paragraph content to paragraph blocks. This would also allow the server to avoid any preprocessing before showing a post on the front-end, assuming that the saved content has had wpautop applied already. Acknowledging that this effectively reverts large parts of #2806
aduth
added a commit
to WordPress/gutenberg
that referenced
this pull request
Dec 14, 2017
A parsed block has no awareness of where inner blocks exist in its innerHTML, so it cannot safely reserialize. There are a few options: - Since we merely skip wpautop for known blocks, we could avoid reserialization and return the block's original HTML verbatim if we had access to its outerHTML. See nylen/phpegjs#3 - Move wpautop behavior for freeform content to the editor client. This may align well with desires to transparently upgrade legacy paragraph content to paragraph blocks. This would also allow the server to avoid any preprocessing before showing a post on the front-end, assuming that the saved content has had wpautop applied already. Acknowledging that this effectively reverts large parts of #2806
aduth
added a commit
to WordPress/gutenberg
that referenced
this pull request
Jan 5, 2018
A parsed block has no awareness of where inner blocks exist in its innerHTML, so it cannot safely reserialize. There are a few options: - Since we merely skip wpautop for known blocks, we could avoid reserialization and return the block's original HTML verbatim if we had access to its outerHTML. See nylen/phpegjs#3 - Move wpautop behavior for freeform content to the editor client. This may align well with desires to transparently upgrade legacy paragraph content to paragraph blocks. This would also allow the server to avoid any preprocessing before showing a post on the front-end, assuming that the saved content has had wpautop applied already. Acknowledging that this effectively reverts large parts of #2806
aduth
added a commit
to WordPress/gutenberg
that referenced
this pull request
Jan 9, 2018
A parsed block has no awareness of where inner blocks exist in its innerHTML, so it cannot safely reserialize. There are a few options: - Since we merely skip wpautop for known blocks, we could avoid reserialization and return the block's original HTML verbatim if we had access to its outerHTML. See nylen/phpegjs#3 - Move wpautop behavior for freeform content to the editor client. This may align well with desires to transparently upgrade legacy paragraph content to paragraph blocks. This would also allow the server to avoid any preprocessing before showing a post on the front-end, assuming that the saved content has had wpautop applied already. Acknowledging that this effectively reverts large parts of #2806
aduth
added a commit
to WordPress/gutenberg
that referenced
this pull request
Jan 10, 2018
A parsed block has no awareness of where inner blocks exist in its innerHTML, so it cannot safely reserialize. There are a few options: - Since we merely skip wpautop for known blocks, we could avoid reserialization and return the block's original HTML verbatim if we had access to its outerHTML. See nylen/phpegjs#3 - Move wpautop behavior for freeform content to the editor client. This may align well with desires to transparently upgrade legacy paragraph content to paragraph blocks. This would also allow the server to avoid any preprocessing before showing a post on the front-end, assuming that the saved content has had wpautop applied already. Acknowledging that this effectively reverts large parts of #2806
aduth
added a commit
to WordPress/gutenberg
that referenced
this pull request
Jan 20, 2018
A parsed block has no awareness of where inner blocks exist in its innerHTML, so it cannot safely reserialize. There are a few options: - Since we merely skip wpautop for known blocks, we could avoid reserialization and return the block's original HTML verbatim if we had access to its outerHTML. See nylen/phpegjs#3 - Move wpautop behavior for freeform content to the editor client. This may align well with desires to transparently upgrade legacy paragraph content to paragraph blocks. This would also allow the server to avoid any preprocessing before showing a post on the front-end, assuming that the saved content has had wpautop applied already. Acknowledging that this effectively reverts large parts of #2806
aduth
added a commit
to WordPress/gutenberg
that referenced
this pull request
Jan 27, 2018
A parsed block has no awareness of where inner blocks exist in its innerHTML, so it cannot safely reserialize. There are a few options: - Since we merely skip wpautop for known blocks, we could avoid reserialization and return the block's original HTML verbatim if we had access to its outerHTML. See nylen/phpegjs#3 - Move wpautop behavior for freeform content to the editor client. This may align well with desires to transparently upgrade legacy paragraph content to paragraph blocks. This would also allow the server to avoid any preprocessing before showing a post on the front-end, assuming that the saved content has had wpautop applied already. Acknowledging that this effectively reverts large parts of #2806
aduth
added a commit
to WordPress/gutenberg
that referenced
this pull request
Jan 30, 2018
A parsed block has no awareness of where inner blocks exist in its innerHTML, so it cannot safely reserialize. There are a few options: - Since we merely skip wpautop for known blocks, we could avoid reserialization and return the block's original HTML verbatim if we had access to its outerHTML. See nylen/phpegjs#3 - Move wpautop behavior for freeform content to the editor client. This may align well with desires to transparently upgrade legacy paragraph content to paragraph blocks. This would also allow the server to avoid any preprocessing before showing a post on the front-end, assuming that the saved content has had wpautop applied already. Acknowledging that this effectively reverts large parts of #2806
aduth
added a commit
to WordPress/gutenberg
that referenced
this pull request
Jan 30, 2018
* Framework: Drop server-side block serialization, wpautop A parsed block has no awareness of where inner blocks exist in its innerHTML, so it cannot safely reserialize. There are a few options: - Since we merely skip wpautop for known blocks, we could avoid reserialization and return the block's original HTML verbatim if we had access to its outerHTML. See nylen/phpegjs#3 - Move wpautop behavior for freeform content to the editor client. This may align well with desires to transparently upgrade legacy paragraph content to paragraph blocks. This would also allow the server to avoid any preprocessing before showing a post on the front-end, assuming that the saved content has had wpautop applied already. Acknowledging that this effectively reverts large parts of #2806 * Parser: Apply autop to fallback block content
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.
Related: Nordth@88960c4
The current implementation of
$this->text()does not work correctly, since it attempts to applysubstron an array.The proposed changes here use
$this->input_strinstead to iterate the$this->inputarray. Further, it applies the fix from Nordth@88960c4 which otherwise does not correctly identify the termination of a token.Fixtures have been updated to use the current Gutenberg post grammar as of WordPress/gutenberg#2743 (Edit: Correction: it includes a new
outerHTMLproperty which will be proposed soon, leveraging$this->text()). Fixtures forwp-gutenberg-post-with-errorshave been removed since the new grammar is capable of identifying non-block content.