Exporting Block Themes and Styles

[mtias]

The site editor currently has the ability to export the user's templates and template parts. The implementation, however, was put together just to allow easier flows during development and the initial days of sharing block themes. As things mature, we need to revise all the implications of exporting properly.

• Capabilities should be matched with the expectations of core WP. Currently the endpoint is locked behind edit_theme_options but it should be switched to export at the very least. We might want to consider a new capability download_theme (to complement upload_themes) or export_design, particularly with the next point...
• Include user modifications to theme.json configuration. We have the opportunity to make the customizations applied to global styles also part of the export flow so that it can easily be migrated to another site, let's make sure to include this in the consideration.
• In terms of interface, we should probably relocate all of this into the main Tools > Export section of the admin instead of a custom flow in the editor and ensure it's extensible like other export tools.

[ndiego]

Post the 5.9 release, I feel this issue should be revisited. The ability to export Global Styles will be extremely useful in a FSE world.

[anarieldesign]

I agree 100% with @ndiego. I was preparing our theme shop to switch totally to FSE theme with different demos but without the ability to export and import Global Styles, this is going to be hard. I'll try to find some other way around it :). I thought it would be possible to export it like post, pages, templates but unfortunately is not the case. Thank you all for your hard work.

[scruffian]

Here's a suggestion for how this could look in the dashboard:

Any comments/thoughts/suggestions?

[ndiego]

@scruffian I like this a lot 🙌

[MaggieCabrera]

Here's a suggestion for how this could look in the dashboard:

Any comments/thoughts/suggestions?

This looks like a great start. I see two different users that would benefit from this.
Maybe I would just make a mention that it's not merely a copy or an export of the theme you have installed but the theme + your changes, which is what makes this gold.

[scruffian]

I made a first pass at this here: #39313

I'd love your feedback!

[kjellr]

Here's a suggestion for how this could look in the dashboard:

Showing this in the context of the traditional Export screen makes me think of a couple scenarios:

1. I want to export just my theme. This is what's reflected in your mockup (and PR). While it totally makes sense, I'm not 100% sure an existing user would look for this option over in this area of WP Admin. We already have that template export option in the ellipsis menu of the Site Editor, so somewhere within the Site Editor feels like a natural place to have this live. But maybe I'm overthinking it, and we could just add a link to this screen from that dropdown? I'd love more design feedback on this part.

2. I want to export my entire site's content and my theme. This fits in more with the traditional functionality of this screen. I'd expect to be able to basically export my entire site plus it's theme and its customizations from one place. Just a rough mockup:

Obviously, this gets a little complicated because we don't have a built-in import tool that would handle both theme and content at once. But I think it would make sense to figure this out at some point. Allowing folks to export their theme in tandem with their content would provide a pretty seamless migration tool for folks.

[scruffian]

@kjellr thanks, this is a really good direction. Do you think we also should have the "theme only" option too?

The advantage of offering this in the Dashboard rather than the Site Editor is that it gives us a lot more ability to add additional controls and inputs (like Theme name, description etc) which might feel out of place in the Site Editor. Maybe we don't need it in the Site Editor at all?

[pbking]

I rather think that "What comes out of the site editor" shouldn't need inputs, that is a good opportunity to export (or save) what you have. That feels like the logical progression of the existing export tooling in the FSE.

If a workflow needs to provide metadata or other options or details then I do agree it belongs outside of the workflow of the FSE; the WP Admin seems more valid. However I'm not sure if that should be the purview of Gutenberg. At that point you aren't exporting a theme but creating a new one and there's a lot of opinion available there.

[kjellr]

Do you think we also should have the "theme only" option too?

I think this is probably a better mockup. It allows for this, and also follows the paradigm used by a few of the other radio buttons, where we surface additional options when the main radio button is selected:

(It doesn't include a "Content but not the theme" option... so maybe it needs another radio button for that though).

[jameskoster]

If we present this as an option to export the entire theme, does that set an expectation that uploading the resultant .zip via themes.php will work? (I don't know if this works or not, but assuming it doesn't).

It seems plausible to me that there would be a way to export from:

1. The Global Styles panel
2. The Templates List view

[scruffian]

(I don't know if this works or not, but assuming it doesn't).

It should work...

[scruffian]

It allows for this, and also follows the paradigm used by a few of the other radio buttons, where we surface additional options when the main radio button is selected:

I'm not sure the options here make sense - what if I want to just export my templates and styles but not the rest of the theme?

[kjellr]

what if I want to just export my templates and styles but not the rest of the theme?

My thought is that if you selected just one of the checkboxes, it would do that. But maybe it's weird to associate it with a theme if it's not technically exporting a "theme"?

[annezazu]

Very easily could be missing something but only seeing templates feels odd. I have a sense of wanting template parts too as a checkbox option.

[carolinan]

Unfortunately, the import/export (plugin) does not have a component maintainer.
I am not sure it is a good idea to expose a theme or even partial template export in more than one place, I think we should pick one place or the other, not 3. It would be less confusing for users, less to maintain, and less to document.

(And I like the idea of it being placed together with the existing export/imports, over keeping it in the site editor)

[jameskoster]

It should work...

In order for this to work we'd need to offer an option to include things like style.css and functions.php in the export.

Which makes me wonder if there should be three radios;

• Full theme (theme files, plus templates, plus styles)
• Styles
• Templates (includes template parts)

Edit: Then again, if there's no way to import just templates or just styles, is there any point in allowing folks to export them independently? 🤔

[scruffian]

if there's no way to import just templates or just styles, is there any point in allowing folks to export them independently? 🤔

I think so for theme developers - this could be a useful part of their workflow.

[scruffian]

Thanks for all this feedback. Here's a suggestion for how we might achieve the same thing from the site editor... #39202

[gziolo]

I see that #39202 landed with a follow-up #39471. Is there anything else planned for WordPress 6.0? What's missing to consider this issue done?

[scruffian]

I'd like to get these ones in for 6.0:
#39590
#39775

[megphillips91]

Can we take this concept one step farther, and offer export of .wp-env.json?

I'm exploring the developer experience from the start with wp-env using Docker. My goal is to get a portable "solution" for captains rather than a portable theme and a portable plugin. Let me explain what I mean by "solution". A full-bodied solution is not just a my plugin and my theme. It is a collection of the following:

• settings and options
• starter content
• starter products
• plugins
• theme
• localized settings for language, time, weights & measurements, currency, taxes
• plugin settings for my own plugin regarding sunset sail vs. regular sail, ticketed vs. private, days offered, etc.
• (media can be hosted on openverse or wherever so don't really need it)

1. Has there been any consideration to export .wp-env.json from the dashboard?

2. What about adding an attribute that would enable persistent data from container to container? I was thinking something simple like a truthy attribute save-data: true. Since WP already knows where the db is, maybe we don't need the mapping.

3. If the theme and plugins are hosted on the .org repo, can this get us closer to continuous integration if docker is used in production? If not, it would still make the developer experience much more pleasant because I can set up all the options, etc I need for iterating, testing my solution and share that with colleagues during development.

At the moment, do I still need my own docker .yml file to iterate on a wholistic solution for captains? This is all kind of theoretical and I'm still exploring the whole experience.

[megphillips91]

So, uh oh, I guess there are some serious concerns with the idea that I shared. Here is the feedback I received from slack.

I'd be particularly opposed to a WP Env JSON export, WP Env isn't the official local environment and there are significant consequences. Nothing prevents it being a helper plugin
I can foresee a hostile reception to that idea from a number of sources

I came to my suggestion naïve of the hostile reception it would receive with a pure motivation. I am sorry to have caused any disruption in the pursuit of a better development experience for WP developers. So, maybe disregard my idea ?

[MaggieCabrera]

So, uh oh, I guess there are some serious concerns with the idea that I shared. Here is the feedback I received from slack.

I'd be particularly opposed to a WP Env JSON export, WP Env isn't the official local environment and there are significant consequences. Nothing prevents it being a helper plugin
I can foresee a hostile reception to that idea from a number of sources

I came to my suggestion naïve of the hostile reception it would receive with a pure motivation. I am sorry to have caused any disruption in the pursuit of a better development experience for WP developers. So, maybe disregard my idea ?

I agree with the expressed concerns and think that the suggestion might be out of the scope of what the editor should do, but there's no disruption at all for making the suggestion? Please feel free to keep bringing ideas for discussion, that's how we make progress together!

[megphillips91]

Nothing prevents it being a helper plugin

I appreciated this idea. Do you think we could gather support for developing a plugin that can offer the functionality? In the interest of inclusivity, I think the idea still may have merit.

For devs coming from the JS world, the experience with VVV is really unfamiliar. In the interest of living up to the inclusivity we aim to achieve within the WP Community, I hope we can make the beginner experience great for developers with different 'first languages' - JS vs. PHP.

Do you think there could be any benefit in having multiple 'golden' pathways?

[scruffian]

I think we close this in favour of #39189. Thoughts?