gregsullivan/_tw

FSE template parts naming issue

Closed this issue · 6 comments

Hey Greg,

First of all, thanks for the starter theme. I'm checking it out and I must say it's really great.

However, I'm trying to switch my gears from classic themes to blocks themes with support of Full Site Editing (FSE). So, FSE themes have different templates for site parts, e.g. header, footer, sidebar, etc. When I create a new template part, let's imagine it's Header template part on localhost I get the following result

<!-- wp:template-part {"slug":"header", "theme":"my-theme/theme", "tagName":"header", "area":"header", "className":"my-theme-header"} /-->

The "theme" parameter here is "my-theme/theme". This template part is included in different templates like index.html, single.html, page.html etc. Everything works great so far.

However, when I bundle the theme with npm run bundle command the theme structure changes. There is no my-theme/theme but my-theme in the bundled theme. So, when I upload the bundle.zip to a new WordPress installation the template part can't be found.

Is there any workaround to fix this issue? Thanks in advance!

Best Regards!
Dan

Hi Dan—Thanks for posting this!

I'll preface my response by saying _tw is meant to be used as a hybrid theme, so you're going in directions I haven't tested. But I'd love to hear how it goes, and I'm glad you're giving it a shot!

My understanding was that the theme key for wp:template-part was optional, so my initial response to this is just to wonder whether it would be safe to remove it. (I had thought it would default to the active theme.)

If it's not optional, you could search-and-replace "my-theme/theme" with "my-theme" during the bundle process, though that might add more complexity than you're looking to add. If you did want to go that route, there's already one search-and-replace performed during the bundle process that should give you a sense of how to proceed:

_tw/node_scripts/zip.js

Lines 32 to 56 in 86d0a2d

// Load `./functions.php` from the zip file.
const entry = zip.getEntry(slug + '/functions.php');
if (entry) {
// Get the contents of `./functions.php`.
const originalContent = zip.readAsText(entry);
// Replace the version string with a date-based version string.
const updatedContent = originalContent.replace(
/(define\( '[A-Z0-9_]*_VERSION', ')(.*)(' \);)/g,
'$1' +
parseInt(Math.floor(Date.now() / 1000), 10).toString(36) +
'$3'
);
// Update the contents of `./functions.php`.
zip.updateFile(entry, Buffer.from(updatedContent));
// Write the changes back to the zip file.
zip.writeZip(zipFilePath);
console.log(
'Date-based versioning string successfully added to `./functions.php`.'
);
}

Please let me know if you have any other questions!

Thanks for the reply!

You're right, removing the "theme":"my-theme/theme" or replacing "my-theme/theme" with "my-theme" solve the issue.

However, when you create templates with FSE and add a template part to a template the "theme" key is added automatically. It means that we need to adjust DB dump in case we need to provide a sample content. I guess the solution would be remove that "theme" key on a template part insertion. But this is a WordPress area, not the _tw ;)

UPD Only replacing "my-theme/theme" with "my-theme" solve the issue.

Awesome, happy to hear it! One of my projects for 2024 is to experiment with a block theme version of _tw, but I haven't broken ground on that project yet. Because the folder structure for block themes is so different, I may dispense with the nested theme folder.

I'm going to close this issue, but please let me know if you have any other questions!

I ran into a similar problem. For example on my custom page template, which is a .php file I did this:

 $template     = get_template();

 $header = do_blocks(
            ' <div id="swup" class="wp-block-group alignfull"><!-- wp:template-part {"slug":"header-copy","theme":"'. $template .'","area":"header","className":"w-full max-w-7xl mx-auto"} /-->  '
        );

Then I just use $header wherever I need it in my template.

That seems like a great solution! I'll keep that one in mind when I start experimenting with a block-based version of _tw.

How are things working otherwise?