Add Gutenberg content parser to use in block processors

[fluiddot]

Related to https://github.com/wordpress-mobile/gutenberg-mobile/issues/6696.

To test:

[!NOTE] This functionality will be tested on separate PRs where some block processors are using it.

• Observe that all CI jobs succeed.

Regression Notes

1. Potential unintended areas of impact N/A

2. What I did to test those areas of impact (or what existing automated tests I relied on) N/A

3. What automated tests I added (or what prevented me from doing so) N/A

PR submission checklist:

• [x] I have completed the Regression Notes.
• [ ] I have considered adding unit tests for my changes.
• [ ] I have considered adding accessibility improvements for my changes.
• [x] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Testing checklist:

• [ ] WordPress.com sites and self-hosted Jetpack sites.
• [ ] Portrait and landscape orientations.
• [ ] Light and dark modes.
• [ ] Fonts: Larger, smaller and bold text.
• [ ] High contrast.
• [ ] VoiceOver.
• [ ] Languages with large words or with letters/accents not frequently used in English.
• [ ] Right-to-left languages. (Even if translation isn’t complete, formatting should still respect the right-to-left layout)
• [ ] iPhone and iPad.
• [ ] Multi-tasking: Split view and Slide over. (iPad)

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.

	App Name	WordPress Alpha
	Configuration	Release-Alpha
	Build Number	pr22886-3a0894c
	Version	24.9
	Bundle ID	org.wordpress.alpha
	Commit	3a0894c3c8af74f4c9356b7893451e353e03058e
	App Center Build	WPiOS - One-Offs #9898

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Alpha
	Configuration	Release-Alpha
	Build Number	pr22886-3a0894c
	Version	24.9
	Bundle ID	com.jetpack.alpha
	Commit	3a0894c3c8af74f4c9356b7893451e353e03058e
	App Center Build	jetpack-installable-builds #8947

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[irfano]

I'm moving this to the next milestone since this is not a blocker, and the code freeze will be completed today.

[twstokes]

👋 @fluiddot - No rush on this, but I wanted to ask:

Did you evaluate what it'd take to put the processor(s) in the Mobile Gutenberg package versus the iOS app codebase? Is there something that makes the content parsers unique to the WordPress app, versus the Gutenberg project? Thanks!

[fluiddot]

Did you evaluate what it'd take to put the processor(s) in the Mobile Gutenberg package versus the iOS app codebase?

Nope, I haven't explored what would be needed for moving these files to the Gutenberg Mobile package. There are several parts of the editor implemented in the client like this one that I agree seem to have a better fit in the Gutenberg Mobile. Ideally, the Gutenberg Mobile package should provide all the functionality to use the editor in any app, but the reality is that Gutenberg Mobile is quite coupled to the WP/JP app code.

Is there something that makes the content parsers unique to the WordPress app, versus the Gutenberg project?

Part of the logic is related to Gutenberg, as the structure of blocks is defined by the editor. However, there's a bit of overlap in the processing because the need of the processors is due to updating media attributes that are defined by the client. As an example, an Image block needs to be updated with the server media ID, and the media structure is defined in the WP/JP apps.

In the future, it would be great if we identify which parts should be provided by Gutenberg Mobile and which ones should be delegated to the client. However, currently, this separation is a bit blurry.

[twstokes]

Makes sense @fluiddot, and certainly something we could defer to the future. 👍

[momo-ozawa]

👋 Hey @fluiddot, I'm bumping this PR to 24.8 since it's code freeze day. If this PR needs to target 24.7, please target the release branch once it's been cut. Thanks!

[kean]

Did you evaluate what it'd take to put the processor(s) in the Mobile Gutenberg package versus the iOS app codebase?

There is a good reason for consolidating this code in Gutenberg. The app and the editor produce different results when handling uploads.

Here's an example of PostCoordinator using its logic:

<!-- wp:image {\"id\":1431,\"sizeSlug\":\"large\"} -->
  <figure class=\"wp-block-image size-large\">
    <img src=\"https://alextest41234.files.wordpress.com/2024/04/img_0005-2-1.jpg?w=1024\"  class=\"wp-image-1431\"/>
  </figure>
<!-- /wp:image -->

And here's Gutenberg:

<!-- wp:image {\"id\":1431,\"sizeSlug\":\"large\"} -->
  <figure class=\"wp-block-image size-large\">
    <img src=\"https://alextest41234.files.wordpress.com/2024/04/img_0005-2-1.jpg?w=1024\" alt=\"\"
class=\"wp-image-1431\"/>
  </figure>
<!-- /wp:image -->

Notice an alt tag. It leads to situation where the app thinks there are changes to the post when the are none. Discussion here: p1714049179672299/1714047410.810349-slack-C06GRKUGDNX.

re: performance

To address the performance issues, I recommend moving this code to the background. I can make this change in the scope of the current project since I'm working in this area.

[fluiddot]

There is a good reason for consolidating this code in Gutenberg. The app and the editor produce different results when handling uploads.

Here's an example of PostCoordinator using its logic:

<!-- wp:image {\"id\":1431,\"sizeSlug\":\"large\"} -->
  <figure class=\"wp-block-image size-large\">
    <img src=\"https://alextest41234.files.wordpress.com/2024/04/img_0005-2-1.jpg?w=1024\"  class=\"wp-image-1431\"/>
  </figure>
<!-- /wp:image -->

And here's Gutenberg:

<!-- wp:image {\"id\":1431,\"sizeSlug\":\"large\"} -->
  <figure class=\"wp-block-image size-large\">
    <img src=\"https://alextest41234.files.wordpress.com/2024/04/img_0005-2-1.jpg?w=1024\" alt=\"\"
class=\"wp-image-1431\"/>
  </figure>
<!-- /wp:image -->

Notice an alt tag. It leads to situation where the app thinks there are changes to the post when the are none. Discussion here: p1714049179672299/1714047410.810349-slack-C06GRKUGDNX.

I agree that consolidating the block processors within the Gutenberg Mobile project could be beneficial. However, I don't believe it will directly address the core issue. The main challenge stems from the fact that the logic for generating the block's markup resides on the JavaScript side (Gutenberg). Currently, the block processors are detached from Gutenberg, requiring them to stay updated with the logic of each block. Given that this is a manual process, discrepancies, as you highlighted @kean, can arise. While finding a method to synchronize the block processors with Gutenberg's logic would be ideal, I anticipate it would introduce considerable complexity.

To address the performance issues, I recommend moving this code to the background. I can make this change in the scope of the current project since I'm working in this area.

Please correct me if I'm mistaken, but even if we move the code to the background, the post-saving process will still be time-consuming due to the required processing. Is that correct?

[kean]

Please correct me if I'm mistaken, but even if we move the code to the background, the post-saving process will still be time-consuming due to the required processing. Is that correct?

"30 media items: 5.250 seconds" – oh, I didn't know we we talking seconds 😨 I assumed it was just micro main thread hangs.

[kean]

While finding a method to synchronize the block processors with Gutenberg's logic would be ideal, I anticipate it would introduce considerable complexity.

There is one more variable: the server. I noticed that it modifies the content before saving. For example, it might end up removing redundant spaces between tag attributes. So, it's really hard to get a canonical representation of a post.

generating the block's markup resides on the JavaScript side (Gutenberg)

An app can call JavaScript directly with little overhead.

[fluiddot]

There is one more variable: the server. I noticed that it modifies the content before saving. For example, it might end up removing redundant spaces between tag attributes. So, it's really hard to get a canonical representation of a post.

Good point. That's definitely another factor to take into account. Usually, when changes are made to a block (either in the frontend or the backend) they are updated in the same Gutenberg version. In most cases, those changes are also made in the mobile native version (i.e. Gutenberg Mobile). However, the web version doesn't have the same concept of block processors that are run outside the context of the editor, like the case of the app. Hence, in case we consolidate them in the Gutenberg repo, it will take time for Gutenberg contributors to be aware of the need to update them.

An app can call JavaScript directly with little overhead.

True. We could consider a potential workaround where the block processor resides on the JavaScript side and imports the necessary code from Gutenberg to process the block. It's worth noting that, as far as I know, such an approach doesn't currently exist, so it would require building it from scratch.

[kean]

@fluiddot, I extracted the processors and moved the work to the background thread https://github.com/wordpress-mobile/WordPress-iOS/pull/23093. This code will only run for a small fraction of the users eligible to test the "Offline Mode" changes.

[dvdchr]

Hi @fluiddot 👋 , I'm bumping this PR's milestone to 24.9 since I'm starting code freeze. Feel free to re-target this to the release branch if this is a blocker or intended for 24.8.

[salimbraksa]

Hey @fluiddot, I'm bumping the milestone for this PR to 25.0 as I'm starting the code freeze. If this PR needs to go into 24.9, please go ahead and re-target it to the release branch.