Theme created using plugin doesn't render template parts

[madhusudhand]

In few themes it is observed that the template parts are having a theme attribute set. This causes the template part to no render in the site frontend and editor.

<!-- wp:template-part {"slug":"secondary-header","theme":"jaida"} /-->

Error in the editor:

Template part doesn't render in the frontend:

Tested by creating a blank theme and exported. It doesn't create any such attribute.
Need to understand the theme creation process from the designers to check if this is still an issue.

[eirichmond]

@madhusudhand this is also the case when changing global styles:

1. Create a blank theme
2. Make changes to templates
3. Change global styles
   4. Save Changes

in /create-block-theme/admin/create-theme/theme-templates.php

There is a line in a function filter_theme_template that replaces the theme attribute with an empty string which then doesn't respect the theme attribute, there is also a note to remove it, so I commented it out, tested it and the template render as expected.

	/*
	 * Filter a template out (return false) based on the export_type expected and the templates origin.
	 * Templates not filtered out are modified based on the slug information provided and cleaned up
	 * to have the expected exported value.
	 */
	static function filter_theme_template( $template, $export_type, $path ) {
		if ( 'theme' === $template->source && 'user' === $export_type ) {
			return false;
		}
		if (
			'theme' === $template->source &&
			'current' === $export_type &&
			! file_exists( $path . $template->slug . '.html' )
		) {
			return false;
		}

		// NOTE: Dashes are encoded as \u002d in the content that we get (noteably in things like css variables used in templates)
		// This replaces that with dashes again. We should consider decoding the entire string but that is proving difficult.
		$template->content = str_replace( '\u002d', '-', $template->content );

		// NOTE: Templates that reference template parts are exported with the 'theme' attribute.
		// This is undesirable and should be removed.
		**// $template->content = str_replace( ',"theme":"' . get_stylesheet() . '"', '', $template->content );**

		return $template;
	}

Personally, I would like to see this removed so the templates respect the theme as its being designed.

[pbking]

:/

My comment was actually the 'theme' attribute being undesirable and should be removed. :P

I wasn't very clear about that eh?

I'm not sure why having the theme attribute NOT set would cause the parts to no longer render. That isn't the case for my observations... Only when it IS present (and doesn't match the folder structure the theme is in) do I see any problems with the templates being rendered.

[matiasbenedetto]

My comment was actually the 'theme' attribute being undesirable and should be removed. :P

Hi! I think we should not remove the theme slug. It's the only way to make it work in some cases as the ones described here, at least some time ago when I tried that.I think we need to be sure we are always the right theme slug.

WordPress/gutenberg#44243 (comment)

[eirichmond]

@pbking @madhusudhand

My comment was actually the 'theme' attribute being undesirable and should be removed.

Yeah, I realised that after the fact, I think you're right it should be removed if the theme is being exported but not when it's being saved with 'Save Changes', that's why I've added conditional logic on my proposed commit 👍
see my pull request

[pbking]

I struggle to see the difference as to why it would be appropriate in one situation but not another. Ultimately the theme imported from being exported is the same as the theme being saved. If it's right to remove the attribute in exported theme what makes it wrong for the "currently loaded" theme?

@matiasbenedetto the cases you mention above only seem to matter for PATTERNS not TEMPLATES, which (from what I have observed) work as expected if there is no "theme" attribute (though might NOT work as expected if the "theme" attribute is present and doesn't match the folder structure the theme is in).

[eirichmond]

@pbking now I'm confused. I managed to replicate @matiasbenedetto's issue because the difference was when I had created a new template, let's say a "Front Page," and built out the template parts (e.g., 'header', 'footer') by adding some other stuff, etc., in the theme and saved it. The front-page.html was generating the markup that references the current theme:

<!-- wp:template-part {"slug":"header","theme":"thecurrenttheme"} /-->
<!-- wp:template-part {"slug":"footer","theme":"thecurrenttheme"} /-->

After making further edits to the template parts, upon saving and removing the "theme" reference as it currently does in the plugin, it was then breaking when rendering as the header and footer.

Now that I've revisited it, I can't seem to replicate the issue any longer. I'm not sure what the steps were to break it, but it's not breaking now. It might be related to editing Global styles in the backend and then making further edits in the 'theme.json' file, resulting in a mismatch. Or it could be something else entirely, but it was breaking for me. 🤷‍♂️ I'll try to keep an eye on this to see if I can identify an emerging pattern.

[Ren2049]

Happened to me today too in 6.3 RC 1, header and footer template parts were just left out. It also got rid of the sliders and replaced those with custom setting with the classic input fields.

[ashrudral]

I am facing the same issue in 6.2.2. Header, footer and lot of template parts are missing in the child theme. Do you found a workaround?

[kingchris]

I'm experiencing a similar issue: The theme name attribute is being omitted from the template-part code during export, which causes the template-parts to break ("Template part has been deleted or is unavailable"). When I manually add the theme name attribute back to the newly exported theme, the template-parts show up. The manual fix wouldn't be a big deal on one site, but when updating the theme on several sites, it gets pretty tedious. Hopefully this gets solved.

[pbking]

WordPress/gutenberg#53194

When this is properly addressed then it will no longer be a problem. The 'theme' attribute is removed on purpose as it's very much an 'environment specific' value. If your theme is installed in a folder, for instance (/wp-content/themes/pub/THEME) then the theme attribute has to include the folder or it also won't work. So the best thing to do is for it to work without the theme attribute at all.

It has been partially addressed but there are still scenarios that need more work. Currently only fixed if using the Gutenberg plugin.

[t-hamano]

Now that WordPress/gutenberg#54595 has been merged, can we close this issue?

[mikachan]

Now that WordPress/gutenberg#54595 has been merged, can we close this issue?

Yes, now that this GB PR is in Core, I think we can close this 👍