CiviCRM Shortcode issue with YoastSEO

Just an FYI, both sites are just using the following basic shortcode: [civicrm component="contribution" id="2"]

Sounds like Yoast is triggering the_content filter before the main body of your page has rendered. You should find the techniques on #107 (closed) to be helpful in solving the issue.

@kcristiano Sounds like there might need to be a re-think on the competing needs of people whose installs trigger the_content filter "pre" and/or "post" the "real" call to the_content().

Just seems odd that this is only on a postback and not the initial loading of the page and shortcode. From looking over the other issue and links from it, I would expect the issue to be even on the initial load of the page without any form interaction.

@rbaugh Yes, that is odd and would need a deeper look. Care to share your Yoast configuration if it isn't too complicated to describe?

@haystack I'd prefer a rethink of shortcodes vs blocks :)

Either way - yes we are now getting multiple the_content() loops on a page and now with Blocks for widgets it's only going to get worse.

@kcristiano Yup, I reckon that's probably true. All the more reason to push forward with different kind of integration - whether via Blocks or a form builder that isn't Caldera.

I started working on a Feed Add-on for GravityForms to post a contact to Civi and also allow for pre-population to have as a profile editor as well. Didn't get into the contributions portion yet as the project didn't require that.

GravityForms repeater field was a challenge to work in, but I think it is moving forward slowly.

I was able to use the action removal that Yoast supplies to disable the function on this one page and the postback is working now.

https://developer.yoast.com/customization/yoast-seo/disabling-yoast-seo/

Interesting solution - thanks @rbaugh

I think I'll add some kind of option to CiviCRM Admin Utilities that removes the remove_filter when selected. That way people can choose the old or new behaviour.

I tried looking through the code for YoastSEO and there is only one the_content in the plugin code. I was trying to figure out what was triggering the function that this was in, but broke away from it so I could get back to other client work. The action hook that is in the reference link, doesn't have any direct the_content, but when I placed the code in for specific pages, I noticed that the default CiviCRM page was failing on initial page load. But the shortcode on a page loads the form, it is just on postback that the problem comes up.

Not sure if this helps in any way or not.

Thanks - any clues are helpful. It needn't necessarily be a direct apply_filters('the_content') - it could also be a call to e.g. wp_trim_excerpt().

There wasn't any calls to wp_trim_excerpt() in the plugin code.

I'll have a look when I get a moment.

added regression label

@haystack @kcristiano I added the regression tag - but am unsure if this actually is a regression - do you know?

@eileen I don't think so - I have a few Yoast sites and I'll test - I think a yoast change is what happened here. Not sure it's on us to fix when plugins change. I'll let you know once I look at it.

@kcristiano I reverted Yoast back three versions and they all failed the same way. I think it has something to do with the way that 5.39 changed the rendering to fix other issues you all mentioned in terms of themes and multiple form outputs.

Now having Yoast installed was causing my issue, but prior to 5.39, or in between, this wasn't an issue even on the latest Yoast version. I think we had the client on 5.36 when we upgraded to 5.39. But from the recent talks, I think the 5.39 change is what may have caused the conflict between the two.

I went back to 16.6.1 which they released just before 5.39 was released.

Thanks @rbaugh

I just spun up a new CiviCRM master and yes - AIOSEO and Yoast both cause shortcodes to get in a redirect lop.

It's a regression.

I'll look at a revert for now and then we can see about a more proper fix.

@kcristiano It was odd that the shortcode would initially load the form, it was the post back that would cause the issue. But for the core frontend page for Civi, it wouldn't even load in the form on first page load while Yoast was activated on the page.

Once I used their filter to stop them from rendering to the head on the shortcode pages and frontend Civi page, things worked again as usual.

Hope this helps out some.

@rbaugh Can you test this page: https://wpcvrc.tadpole.cc/donate/

WP 5.7.2 CiviCRM 5.40.0 and Yoast.

I am getting success and failure in odd ways on different sites 5.39+

@kcristiano I am getting the same issue. Form loads and post back for the review, I get the shortcode as output.

@rbaugh Thanks.

I just reverted 240 on that site, can you test again?

@kcristiano

That seemed to work this time. I can get the confirmation form now.

I was actually able to complete the full form.

https://github.com/civicrm/civicrm-wordpress/pull/254

Can you comment there as well. Be great if you can test on other sites you have.

@kcristiano

Sure, I can comment this out on the staging site for our client and then try it out on the demo installs I have in the initial comment of this issue. Looks like that is all in the commit you have.

That revert is definitely what works for us. I hadn't made the link to Yoast SEO yet, but we do run that almost everywhere....

If the problems the original change was meant to solve are related to repeated output in the loop, would it make sense to, instead of removing the filter on 'the_content' on first run, check that the current post is actually the civicrm basepage?

e.g. hacky pseudoish-code:

if ( is_singular() && in_the_loop() && is_main_query() &&
        isset($_GLOBALS['post']) && $_GLOBALS['post']->name == $config->wpBasePage ) {
  return $this->basepage_markup;
}
else {
  return $content; // CiviCRM base page is not required.
}

mentioned in issue #107 (closed)

changed milestone to %5.40.1

@agilewarefj That does make sense. is_main_query() should be the key.

The issue is that widgets can call the_content() and now with Block Widgets we'll see even more issues.

@andrei put this together https://develop.tadpole.cc/plugins/prevent-civicrm-content-in-widgets some time ago when we had query widgets that caused CiviCRM content to display in sidebars. I just added to a public repo today.

I think we should review both approaches and get one in core.

Thanks!

closed

CiviCRM Shortcode issue with YoastSEO

Child items ...

Activity