Fusion Builder shortcodes not rendering in Jetpack Reader and WordPress.com Reader

[alinclamba]

Quick summary

Fusion Builder shortcodes are displayed as raw code instead of being rendered correctly in both the Jetpack mobile app's Reader and the WordPress.com Reader in the browser. This issue impacts users relying on Fusion Builder for creating posts.

Steps to reproduce

1. Create a post or page using shortcode from Fusion Builder or use this post: https://www.secularfranciscansusa.org/2024/09/20/the-pilgrim-continues-his-way-discussion-planned/
2. Open it in the Reader on WordPress.com at https://wordpress.com/read/blogs/132670386/posts/37299 or in the Jetpack app on iOS or Android
3. See that instead of the content being displayed, the post shows unrendered Fusion Builder shortcodes. Here's a comparison of the post displayed on the site directly versus in the WordPress Reader:

What you expected to happen

The post content should be rendered correctly, processing the shortcodes into the visual elements they represent (e.g., layouts, containers, etc.).

What actually happened

The shortcodes appear as raw text, showing attributes like [fusion_builder_container type="flex" ...], which makes the content unreadable and disrupts the user experience.

Impact

Some (< 50%)

Available workarounds?

Yes, easy to implement

If the above answer is "Yes...", outline the workaround.

I think the only option is to avoid using the shortcodes

Platform (Simple and/or Atomic)

No response

Logs or notes

No response

[Robertght]

📌 REPRODUCTION RESULTS

• Tested on Reader, app and browser.
• Tested it on self-hosted/Jetpack connected website

📌 FINDINGS/SCREENSHOTS/VIDEO

• In the and the app the post displayed ok, but only in the app notification and the email notification preview things didn't look good:

While I can't replicate the issue above, I think there's something happening.

📌 ACTIONS

• Triaged

@davemart-in @Automattic/reader I couldn't find more context about Reader's compatibility with other builders. Is this something the team could look further into? Also, let me know if you need our help running more tests.

[davemart-in]

I moved this to our bug board. We do plan to do a project to tighten up block coverage in the reader, but this sounds like something completely different. I'd want to get a better feel for how many customers are affected by this prior to working on it.

[dcalhoun]

Capturing information regarding a semi-related user-reported issue, where the WPGlobus plugin's formatted strings are not parsed for Reader API endpoint returns. (ref: p1728480018854939/1728034222.654049-slack-C0180B5PRJ4)

One must visit a specific site’s posts feed in Reader to see the issue, the issue is not experienced when viewing a site’s posts in the top-level Subscribed feed.

1. Subscribe to a site leveraging the WPGlobus plugin for multilingual posts.
2. Navigate to Reader in the iOS or Android mobile app.
3. Navigate to Subscribed.
4. Note the problematic site’s post render as expected.
5. Navigate to the problematic site’s detail page within Reader.
6. Note the unexpected characters are present in the post titles.

The web Reader does not experience this is because it uses a different API endpoint from the native apps.

Web: https://public-api.wordpress.com/rest/v1.2/read/feed/{site_id}/posts Native: https://public-api.wordpress.com/rest/v1.2/read/sites/{site_id}/posts

Ideally, we should align with the native apps with the web product so the same API endpoint is used, I’m not sure why they diverged. However, we should likely still address this issue in the rest/v1.2/read/sites/{site_id}/posts API endpoint.

[kean]

I re-tested it, and the issue reported by David still persists:

Full URL: https://public-api.wordpress.com/rest/v1.2/read/sites/216931531/posts/?before=2024-11-04T12%3A20%3A51Z&meta=site%2Cfeed&number=7&order=DESC&locale=en