Feature/block filters

[cmmarslender]

Description of the Change

On distribution, converts block comments to a DOMDocument-friendly format, then parses the html and iterates, firing a filter on each block that is then encountered. After all filters are run, it is converted back to normal gutenberg comments and then saved.

Alternate Designs

Could possibly try to just parse the gutenberg "markup" without DOMDocument, but probably safer to use a library that is designed for this, since its relatively easy to convert the gutenberg comments into something that looks like html that DOMDocument will parse

Benefits

Allows filtering block attributes before the post is distributed.

Possible Drawbacks

Verification Process

Tested the output of the conversion functions and am using this filter on a current project to ensure media + taxonomy IDs are translated as part of pushing content to another site

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests passed.

TODO:

• Unsure off hand if DOMDocument is included with php or a module. Should check for this and adjust code accordingly
• mb_convert_encoding requires mbstring module. Should ensure this is available before using the function

Applicable Issues

#430

[adamsilverstein]

very interesting! I was going to suggest considering core's block parser however you rightly pointed out that it doesn't support a way to reverse the parse process once you modify the attributes. Apparently that is handled entirely in JavaScript.

https://github.com/WordPress/gutenberg/blob/master/packages/block-serialization-default-parser/parser.php

[cmmarslender]

Yep.. I initially looked at using the core parser to parse them and then reassembling that data myself, but as far as I could tell, there wasn't any way to figure out where within the markup we should put back innerBlocks, etc. Annnnd thats how I ended up with the current approach :)

[jeffpaul]

@cmmarslender @adamsilverstein I wanted to check in to see if either of you had plans to put further work into this draft PR? Either way, happy new year and I hope you both have a safe, happy, and prosperous 2020... cheers!

[adamsilverstein]

👋 Hey @jeffpaul - thanks for the ping. I doubt I will have time to revisit this in the near future - probably best tackled by someone working more closely on Distributor.

[gthayer]

I've taken over the project this CR originally came from and ran into a bug where there was an incorrect space being added to the Block, preventing it from being read correctly on the Distributed site. Submitted a patch here: 62c2ae5

[gthayer]

@jeffpaul - I've added the check for DOMDocument, though I'm not sure what to do about about CIs failing here. Distributions are working for me locally.

[gthayer]

I'm seeing other PRs will the same issue, so maybe its a problem with the test itself?

[jeffpaul]

@gthayer aside from the tests, are there any further enhancements/fixes you have pending on this PR or is it otherwise ready for review?

[gthayer]

No further updates planned. Gary Thayer

…

On Mar 6, 2020, at 4:22 PM, Jeffrey Paul ***@***.***> wrote:  @gthayer aside from the tests, are there any further enhancements/fixes you have pending on this PR or is it otherwise ready for review? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jeffpaul]

@gthayer wonderful, thanks!

@dinhtungdu are the failing tests here the same that you're helping to triage or something else that should give us concern in reviewing/merging this PR?

[dinhtungdu]

@jeffpaul Yes, the failing one is author test, which is not wpsnapshots butadmin. I fixed it in other PR, if you think a separate PR to fix it is better, I can submit one.

[jeffpaul]

@dinhtungdu nope, we're fine how it is then.

[jeffpaul]

There's still a good amount we need to discuss on this and it relates to work we want to tackle in 2.1.0, so I'm going to move this to the 2.1.0 release in hopes someone's able to pick this up and own it during that release cycle.

[jeffpaul]

Unassigning reviewers here while we focus on the v2 refactoring and can then reassess how best to handle the root issue here.

[github-actions]

@cmmarslender thanks for the PR! Could you please rebase your PR on top of the latest changes in the base branch?