YoastSEO.js: Add further Yoast compatibility for remaining WB widgets

[AlexGStapleton]

The following widgets are currently not added to the Yoast Compatability code:

• Call-To-Action
• Contact Form
• Features
• Google Maps
• Headline
• Hero Image
• Icon
• Image Slider
• Layout Slider
• Post Carousel
• Price Table
• Social Media Buttons
• Testimonials
• Taxonomy
• Video Player

For reference, the following widgets are currently accounted for:

• Image
• SiteOrigin Image
• SiteOrigin Image Grid
• SiteOrigin Simple Masonry
• SiteOrigin Accordion
• SiteOrigin Tab
• SiteOrigin Button
• Text
• SiteOrigin Editor

[gregpriday]

Adding custom rendering logic to each widget does get really messy.

We have 2 options here. The first would be to make server requests for the HTML for each unsupported widget as a fallback. This could be really slow though.

The other option would be to dump out all the field values to give Yoast a better chance at picking up text within the widget form.

[braamgenis]

make server requests for the HTML

I had something like this going in the block editor when trying to solve #647 but with a request for the whole layout's HTML. We already fetch a layout's HTML in the classic editor when Copy Content is enabled, so don't think it'd take too much effort to use that here.

[gregpriday]

I had a look at this. So the main issue is that the layout's HTML in the classic editor is encoded in a way that makes it possible to decode back into a full panels_data object. This is what we're already passing to our Yoast compatibility code.

So we have a few possible solutions:

• Pick the most important widgets to add some more custom JS processing code.
• Make additional server requests to get the full processed HTML for each widget. If we add these requests to our Yoast compatibility code, then they'd need to be blocking to ensure we return the proper HTML. This isn't ideal, but we could use caching to speed things up.
• Give the user the option to change the behaviour of the so_panels_builder_content action so that it returns full HTML. This is the easiest solution and lets the user decide on the tradeoff. Do they want better Yoast compatibility, or do they want to be able to go to and from the classic editor. This is a quick 30 minute solution.
• We could come up with a hybrid solution. So have so_panels_builder_content return fully processed HTML, plus store widget data in HTML comments. This could give us the best of both worlds, but it's really finicky.

Any suggestions on which solution would be best?

[braamgenis]

The last solution seems like the best option as it might solve, at least partially, #647 too. In the end it depends on how much time you want to spend on this. If the answer is "not much" then option 3 seems like a good alternative, albeit with a tradeoff.

[gregpriday]

I added a so_panels_builder_content_json action that also returns a content preview, which Yoast compat can then use. This is added to the main builder view here.

This makes all widget compatible in the classic editor. @braamgenis, could you use this to get content passed to Yoast in the block editor for #647?

[Misplon]

Thanks, G. I'm using the Corp default home page as a demo right now. You can use that same layout by activating Corp and then checking Prebuilt Layouts.

The first image below is from the develop branch:

The second image is from our new feature compatibility branch:

Nine words changes to 203, awesome. But for some reason, the compatibility branch doesn't pick up the outbound link which the develop branch does. The outbound link can be found within the first Hero widget's button. The link is https://wordpress.org/themes/siteorigin-corp/. Any ideas?

[Misplon]

Outbound and inbound links are being detected within the Editor widget. However, they don't appear to be detected within the following widgets:

Hero (have added links to the frame content field and the button field)
Headline (have added destination URLs to the main and sub-headline)
Button

They also aren't detected from the Post Carousel widget but I'd imagine that's expected.

[Misplon]

The outbound and inbound link issues appear to be consistent. In the Accordion widget, the key phrase is detected in the content field but outbound and inbound links aren't detected in that same field.

[braamgenis]

@gregpriday I managed to use the action you added to get Yoast's analysis working in the block editor by using the block's save function. Everything still seems to work after some cursory tests, so I think that did the trick!

[Misplon]

Epic! That's great news.

[codemasonnet]

Can anyone confirm that this issue only affects the block editor and not the classic editor for the widgets outlined in the OP? Thanks

[Misplon]

Hi, the Block Editor issue is separately logged #647. In the initial posting of this issue, Alex lists the widgets that are sending to data to Yoast at the moment and those that aren't. That applies to both the Classic Editor. Hope this helps.

[codemasonnet]

Thanks.

So, currently neither editor is working fully with Yoast.

Having had a read through the thread, I think option 3 proposed by Greg would be the best option for most scenarios - Give the user the option to change the behaviour of the so_panels_builder_content action so that it returns full HTML. This is the easiest solution and lets the user decide on the tradeoff. Do they want better Yoast compatibility, or do they want to be able to go to and from the classic editor. This is a quick 30 minute solution.

[Misplon]

Sure.

At different levels. The Classic Editor has a limitation in terms of the widgets that send data to Yoast. The Block Editor has a bug.

Thanks for your feedback. I'm sorry we haven't had the resources to complete this yet. It's definitely very high on our to-do list and will be completed as soon as we're able to.

[codemasonnet]

No problem at all, I'm just trying to understand where things stand. I'm really not meaning to hassle you guys. :-)

[Misplon]

No worries, not hassling at all, we'd really like to see this resolved, the problem has just been quite challenging. Thanks for checking in. Feel free to reach out at any time, either here, on the forums at https://siteorigin.com/thread/ or via email on support@siteorigin.com if you're using SiteOrigin Premium. Cheers for now :)

[jtibbles]

Currently SiteOrigin and Yoast are incompatible due to the "0 words" count. Can I fix this by switching off Guternberg and using classic editor instead?

[Misplon]

Hi, @jtibbles. Thanks for reaching out. The Classic Editor offers limited compatibility. Please, see the list provided by Alex at the very top of this issue. If you have any follow-up questions, kindly, open a support thread on our forum, we'd be happy to lend a hand.

[TheRed-E]

According to the list at the top of this threat, the SiteOrigin Button widget should be seen by YOAST. This is partially true.

Currently the SiteOrigin Button is also not recognized if using the "select content" option, which shows Post: #post number#. Only Direct URL's are recognized as internal/external links by YOAST.

[Misplon]

Thanks for letting us know.