FSE: Form Blocks Added To Footer Template Part Show As Shortcodes on 404 pages

[katiebethbrown]

Quick summary

Jetpack Form Blocks added to the footer template part aren't displaying correctly on 404 pages. Instead the shortcode displays:

The form does show in the Site Editor when reviewing the 404 Template:

Steps to reproduce

1. Use the Site Editor to create a custom footer that includes a Jetpack Contact Form
2. Check the 404 Template to ensure the footer w/ the form shows in the editor.
3. Visit a page on the live site that will 404.

What you expected to happen

For the form to show in the footer, like it does on the other pages of the site.

What actually happened

The form doesn't show. Instead we just see the unconverted shortcode.

Context

Found when working on a Team51 partner site. Replicated on a Premium plan test site.

You can see it happening on a simple site here:
https://kbb-premium.blog/404test

And on an atomic site here:
https://kbbatomicbusiness.wpcomstaging.com/404test

Simple, Atomic or both?

Simple, Atomic

Theme-specific issue?

I can replicate in Blockbase (in use on our partner site) and in other FSE-capable themes (tested Alonso).

Browser, operating system and other notes

No response

Reproducibility

Consistent

Severity

Most (> 50%)

Available workarounds?

No but the platform is still usable

Workaround details

No response

[simison]

Interesting!

So templates don't render shortcodes, that's known.

I had impression (based on #15227 (comment)) that this shouldn't be an issue with contact form anymore. cc @jeherve

Indeed I see that contact form isn't outputting shortcodes:

How did the shortcode end up in the template?

[katiebethbrown]

How did the shortcode end up in the template?

@simison - Not sure if this question is for me or not, but in case it is - in the site we originally noticed the issue on, the form block is added to the Footer template part directly. We didn't add it using the shortcode, so it must be falling back to that (or trying to) somewhere.

[jeherve]

This fallback is happening here:

jetpack/projects/plugins/jetpack/modules/contact-form/grunion-contact-form.php

Lines 2123 to 2125 in 8e0dff0

	if ( ! $id ) { // something terrible has happened
	return '[contact-form]';
	}

It's been set up that way since the contact form was first developed, years ago, but makes less sense now, when used in template parts. Unfortunately, forms are still tied to a post behind the scenes, and when used outside of a post context, you're bound to run into issues like this.

Here is a related issue with more discussion around the reason why we look for that post ID:
#102

I'll move this to the Jetpack repo, where the form block is developed.

[simison]

Thanks for explaining @jeherve 👍

Why does contact form require page/post ID, and could it work without it?

Just thinking if the fix is to ensure it gets the ID, or remove the reliance on that ID altogether.

Edit: right so the gotcha is "... on 404 pages" which of course won't have any kind of ID. Would that also be the case with archive and search pages?

[jeherve]

Why does contact form require page/post ID, and could it work without it?

There are some details about this here:
#102 (comment)

You can also dig a bit in projects/plugins/jetpack/modules/contact-form/grunion-contact-form.php to see how we use contact-form-id as a way to ensure the form that's being submitted makes sense.

Edit: right so the gotcha is "... on 404 pages" which of course won't have any kind of ID. Would that also be the case with archive and search pages?

Yep, if we do not have an ID, we have a problem. :|

[cuemarie]

Ran into this issue here as well: 34459908-hc

Form block, along with all their content, was built directly onto the home template, which means the form didn't have a page ID, and therefore rendered as [contact-form] on the live site. I can see this happening more frequently with users who (perhaps mistakenly) build their content onto templates instead of onto pages, as they learn the ropes with FSE.

This user is taking a different approach and removing the form from the home template for the time being.

[edequalsawesome]

Same issue in 4762945-zen

[KokkieH]

Another case in https://wordpress.com/forums/topic/contact-form-76/?view=all, using the form on the Home template.

[TPilgs]

Another case here using the contact form on the index template: 35747249-hc

[danielbachhuber]

@jeherve I think this issue might actually be fixed with #24727, too.

Using the following test environment:

• Fresh WordPress install in my local environment.
• Jetpack at 950ce39.
• Twenty Twenty-Two active.

When I add a Contact Form Block to the 404 Template and the Footer Template Part, they both appear as expected on a 404 page:

Well, partially as expected: #24857

[jeherve]

Ah yes, it looks better now. We're only left with a PHP notice on form submission:

PHP Notice:  Trying to get property 'ID' of non-object in /wp-content/plugins/jetpack-dev/modules/contact-form/grunion-contact-form.php on line 3507

[danielbachhuber]

We're only left with a PHP notice on form submission:

@jeherve Nice catch! Fixed with #24870