Reader: unexpanded (third party) shortcodes are shown in post content

[designsimply]

Raised by @bluefuton

On the full post view, we should not show unexpanded shortcodes.

For example, in http://wordpress.com/read/post/feed/33151/723955414, we display:

[cfsp key=“getamac.jpg”]”

[tc_aol_on code="519068927"]

Note from @blowery

Anyone who fetches content via the REST API is going to see this problem.

[designsimply]

The time shortcode also has this problem:

[time]10/29/2015 2:10pm CDT[/time]

[blowery]

Doesn't look like the time shortcode works on general wpcom blogs. Is that a special one?

[blowery]

This may be fixed... Shortcode expansion for vips was fixed or avoided a while ago

[blowery]

Closing this for now as I can't find any more instances of it. If we find some, we can reopen.

[bluefuton]

Still seeing this one. For example: http://calypso.localhost:3000/read/post/feed/33932/885827042

[designsimply]

Another case was reported in #1557 for [pullquote]

From the Reader on the web:

From the Reader on iOS:

/hat tip @meremagee for the report and images

[lancewillett]

Bug scrubbing today, this is not solved yet on Longreads blog. Testing with Mac-n-Chrome.

wp-admin editor

Reader post view, URL: https://wordpress.com/read/feeds/22973954/posts/973158663

[bluefuton]

@mzorz reports:

This site has an fb_vid shortcode that shows up in the Reader, and we can observe this happens both on Android and iOS (haven’t tested the web). It can be easily added to the apps by following tag ‘fujifilm’. The particular Post where this happens is this http://www.photographinggod.com/2018/01/09/hands-on-with-the-fujifilm-gfx-medium-format-camera-system/

[eliorivero]

There's a shortcode googlemaps that's not being rendered in the Reader. That shortcode has been around for years in wpcom so I thought it would be correctly rendered and inserted it when I composed the post in Calypso, but it's not and now the post is looking like this in the Reader, both in mobile and web or desktop.

Mobile

Web/desktop

[eliorivero]

Found some shortcodes not stripped in content, both in mobile and in desktop:

Desktop

Found in https://wordpress.com/read/blogs/131129977/posts/129846

[rachelmcr]

@bluefuton what do you think of raising the priority on this one? It's set as low priority but has received a number of reports and is a pretty ugly experience.

[bluefuton]

@rachelmcr good call - I'll remove the low priority label.

Noting that @blowery recently solved a similar problem in notifications with D9324-code, and intends to add some content caching to Reader endpoints in D8829-code, which may be related.

[eliorivero]

One more: the caption shortcode:

[westi]

Related p5PDj3-4lb-p2 - portfolio shortcode

[danjjohnson]

Another one in 1859970-zen for Visual Composer, e.g: https://wordpress.com/read/blogs/159335874/posts/17566

[danjjohnson]

Another one for Visual Composer here: 1896297-zen

[eduardozulian]

Another for a custom plugin when reading one of their posts on a mobile device 15900584-hc

[anaemnesis]

Reported in 3184310-zen

[julsyd]

VC shortcodes appear in Reader: 3294121-zen

[github-actions[bot]]

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

[bluefuton]

Still an issue. In p5PDj3-4Sg-p2, @gibrown suggested reusing the Jetpack email processing for handling these.

[lakellie]

Another report in 4270958-zen for Visual Composer shortcodes

[github-actions[bot]]

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

[github-actions[bot]]

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

[gibrown]

very real

[github-actions[bot]]

Support References

This comment is automatically generated. Please do not edit it.

• [ ] 1859970-zen
• [ ] 1896297-zen
• [ ] 3184310-zen
• [ ] 3294121-zen
• [ ] 4270958-zen

[roo2]

I did a little bit of investigation on this, my understanding is that there was an original issue in 2015 where many built in wordpress shortcodes, such as [pullquote] and [caption] where not being rendered in the reader.

As far as I can tell, that issue is now completely(?) solved, but there remains an issue with shortcodes that are added by plugins such as Visual Composer.

That seems like a more fundamental problem, because the plugin is required to parse the shortcode into HTML content, and that plugin isn't running on wp.com, we are in a tricky situation.

If I understand @gibrown's suggestion here p5PDj3-4Sg-p2#comment-7871 it's that we might be able to repurpose logic similar to how jetpack generates emails. This would parse the blog post in the context of the user's own blog, with all of their plugins available. It would feed the pre-parsed post content somewhere to be consumed by the wordpress.com reader.

It seems like a very tricky change to me (with my very limited knowledge of jetpack and reader's backend). I wouldn't expect this to be fixed any time soon unless it gets urgently prioritized.

[gibrown]

This would parse the blog post in the context of the user's own blog, with all of their plugins available.

You don't need to actually have the plugins available to parse the content. You just need to replicate the logic for the most popular shortcodes/plugins which we are already doing for emails so you could probably use the exact same code and generalize it.

[roo2]

You just need to replicate the logic for the most popular shortcodes/plugins

Oh ok, I understand

We currently have quite a few tasks related to supporting different blocks and shortcodes. It seems to be a grey area how many different shortcodes we want to support in reader. And there is also a tension between providing a consistent reading experience and giving authors control over how their content is presented. It's not clear to me when we should stop.

[gibrown]

I think for emails we looked at the frequency of how often they are used.