Added a 'Save Theme' option to save the theme.json and template changes to local theme folder and clear user changes.

Addresses: #45 and enables a development workflow.

To Test:

• Start with a theme activated. (I have done most testing with Archeo but ANY theme [parent or child, Blockbase or not] should work fine.)
• Make sure you begin with NO user changes to the theme (such as color, font or template changes)
• Make changes to the theme using the FSE (or the Customizer). A good test for this is to change the color values of the theme colors.
• Make changes to a template part (for instance add a simple paragraph block)
• Make a change to a template (another simple change you can easily see)
• Create a brand-new template and template part.
• Use the Plugin to 'Overwrite'.
• Load the site (view). Note that it still looks the same (global style changes and template changes are still in tact)
• Attempt to "Reset to Defaults" the Global Styles using the FSE (nothing changes)

This change also clears user settings when a theme is 'saved' addressing #50

Hi,

When I go to Appearance > Create Blockbase Theme, fill in the fields and click the Create Blockbase Theme button, it downloads a .zip file succesfully, but the file is 0 bytes. When I try to unzip it, I get a .zip.cpgz file, which I'm unable to open.

I have the following installed:

WordPress 5.82 Blockbase 1.4.3 Gutenberg 11.9.0 (no other plugins)

Thanks, Troy

Thinking about updating the plugin to include non universal themes, the problem with choosing fonts for the theme comes to mind. Here's an idea:

On the form we can include the option to add a specific font, then generate a functions.php file that enqueues that. We would have to add that same font to the theme.json file we are generating too.

How many fonts can a user choose for a theme? How do we handle different weights/styles? Do we include the font files or do we use google fonts links?

This work borrows very heavily from @MaggieCabrera 's work in #32.

This works exporting any parent theme as a standalone theme.

To test attempt to export ALL THREE kinds of themes:

• GRANDCHILD : Activate a Blockbase CHILD theme (such as Geologist). After making changes export the theme. It should be a BLOCKBASE child theme with all of the theme.json values from the activated theme as well as any changes you have made. The child theme's /assets/theme.css resource should be included. Templates and template parts from the active theme should also be included.
• CHILD : Activate Blockbase. After making changes export the theme (selecting 'Child them of the current active theme' from the Create Block Theme page). The exported theme.json should ONLY include changes made by the user. The /assets/theme.css file should be empty and only changes made to templates and template-parts should be included. Repeat the process with a non-Blockbase Block theme (such as TwentyTwentyTwo).
• STANDALONE : Activate Blockbase. After making changes export the theme (selecting 'Standalone theme' from the Create Block Theme page). The exported theme.json should include ALL of the settings from Blockbase as well as any changes you made. The /assets/theme.css file should include the contents of Blockbase's /assets/ponyfill.css file. That /assets/theme.css file should be automatically loaded (in both the view and editor). Likewise any fonts selected (as defined in the theme.json) should be loaded (accomplished by the bare-bones functions.php file included in the generated theme. Repeat the process with a non-Blockbase Block theme (such as TwentyTwentyTwo)

Note: This does NOT YET export any of the theme's PATTERNS. As such any of the templates that leverage those patterns will not work.

When the base theme is BLOCKBASE:

only export theme.json settings modified by the user do not export any block templates/parts except those modified by the user

NOTE: When exporting with a CHILD theme as the base then UNMODIFIED templates/parts that originated in Blockbase are still exported. This is a bug.

This new option saves the users global styles changes into a variation instead of a child theme or a new clone of the theme. I opted in for the easiest way to do this, saving the file locally with a generic file name and downloading the zip file, but it's up for discussion if we want to do it this way:

• Should we ask the user for a variation name?
• Should the exported ZIP file only include the variation or the whole theme included like in this case?
• Is the wording on the new option clear for what the feature does?

Closes #89

What?

This PR adds 2 sections to the plugin that enables the user to:

• Embed Google Font assets and font face definitions to the active theme.
• Embed local Font assets and font face definitions to the active theme.

Why?

The objective is to add a simple way to embed font assets in a block theme that after that you can export with the other plugin options.

How?

These new section work this way:

Embed Google fonts:

1. Gets a list of the available Google fonts from Google fonts API. If the API is not working it uses the stored JSON file as a fallback resource.
2. When the user selects a font, all available variants are loaded to generate the preview.
3. After the user selects the desired variants, and clicks the "Add fonts to the theme" button, the font files are written to the theme assets and the font face definitions are added to the theme's theme.json file.

Embed local font files:

The font file selected by the user is added to the theme assets/fonts folder and the font face definitions are added to the theme's theme.json file.

Screenshots

Adding Google Font:

Screencast from 22-09-22 16:57:49.webm

Adding local font asset:

Screencast from 29-09-22 15:20:03.webm

Sorry if this question is naive!

What do you think about adding a fifth option to the plugin — create a new boilerplate theme from scratch, maybe based on block-canvas or something like it?

When I meet folks that are new to block theming, the first thing they always ask is for a reference point — a starter, boilerplate block theme. Also the name of this plugin implies it could create a "new" theme, to me, maybe disconnected from the currently active one. (This is the perspective of someone who has used "create-react-app" before coming to WordPress, and using that utility results in a blank application, granted there's more tooling and overhead involved there because of webpack...)

This might make more sense as a CLI or maybe even in Gutenberg itself, but wanted to ask in any case.

This PR continues the work in #39 and refactors that work in a number of ways:

The plugin is refactored to use the structure from here. (I may not have done that correctly, but I hope it's a good start...)

Logic has been broken into smaller functions where possible.

• EXPORTING a PARENT theme: Activate a parent theme (Blockbase and TTT are two examples I've experimented with). Make changes using FSE to templates and global styles. Select the "Export" option. Note that the zip file contains everything in the original theme but theme.json, templates and parts have user changes integrated.
• CREATING CHILD: Activate a parent theme (Blockbase/TTT) and make changes. Select the "Create child..." option. Note that the zip file contains ONLY the theme.json file with the changes you made as well as templates/parts folders containing modifications you made
• CLONING a PARENT: (This used to be called the "Standalone" option). Activate a parent theme. Make changes. Select the "Clone" option. Note that the zip contains everything available from an EXPORT option but with new metadata in style.css NOTE: The resulting theme will NOT have namespaced values changed. This is a limitation noted in the instructions.
• EXPORTING a CHILD theme: Activate a child theme (Geologist is an example I experimented with). make changes and select the "Export" option. You will see the theme exported with the changes to theme.json and templates integrated.
• CREATING A SIBLING theme: This one is still a work-in-progress. GOAL: Activate a child theme and make changes. Choose the "Create Sibling..." option. Note that the zip contains everything that the currently activated theme provided as well as the user changes, but with a different style.css metadata creating a new child theme with the same parent as the currently activated theme, with all of the customizations from the currently activated theme as well as from the user. NOTE: The resulting theme will NOT have namespaced values changed. This is a limitation noted in the instructions.

This PR refactors the plugin so that it can be used with any block theme, not just Blockbase. These are the cases that it covers:

• If the active theme is a classic theme: it will show an error.
• If the active theme is a block theme child of another theme: the generated theme will be a child theme of the parent of the active theme, copying the template files and settings of the active theme plus the user changes on templates and Global Styles. I've tested this scenario using Geologist.
• If the active theme is a standalone block theme: the form will show two options for the new theme. I've tested this one with Remote and Blockbase.
  • We can generate a child theme of the active theme. The new theme will only contain the user changes in templates and Global Styles, the rest is inherited from the parent.
  • We can generate a standalone based on the active theme. The new theme will be a copy of the active theme plus the customizations made by the user.

This change will export CSS for the new theme.

When building a BLOCKBASE CHILD theme no CSS should be exported. When building a BLOCKBASE GRANDCHILD (for instance using Geologist as the source theme) then the SOURCE THEME's CSS should be exported.

Additionally this will export any CSS in the styles.css file into the child's /assets/theme.css class.

Evaluated with Blockbase and Geologist.

NOTE: This code will also export STANDALONE themes (from Blockbase) which would include blockbase's ponyfill.css. However the plugin doesn't yet export standalone themes so this portion isn't testable yet.

When you click Remove Font Family (or Remove for individual), the fonts are not removed from the /assets/ directory. While they are no longer listed on the Manage Theme Fonts screen, this is not expected behavior. Imagine a user adding/removing 100 fonts, and having those files accumulate in the /assets/ directory.

Original Tweet suggestion from @ciorici: https://twitter.com/ciorici/status/1603366366609920000?s=20&t=QTFjskYeDw6_26_QmjsGDA

The ability to customize template parts is already available as a feature of Site Editing. However, for theme builders it would expedite workflows to have the ability to overwrite template parts directly within the Site Editor.

Alongside the “Clear customizations” it would be possible to add another option for “Overwrite with new customizations”. This would be a destructive action and immediately overwrite the entire template part in the theme.

It would be great if this plugin could remove absolute image URLs from images in block markup, either on export or via a separate button somewhere.

Currently, any images that are inserted into a template need to have their URLs manually changed to be relative to the theme directory in order for them to be successfully used outside of the build context (i.e. the local environment or dev environment where the site is being built).

For example, changing an image URL like this:

<!-- wp:cover {"url":"https://localsite.com/wp-content/uploads/2022/12/imagefile.png"...

To this:

<!-- wp:cover {"url":"<?php echo esc_url( get_stylesheet_directory_uri() ) . '/assets/images/imagefile.png'; ?>"...

The above solution would require the template file to be converted from HTML to PHP. It would be good to hear if there's a better way!

I currently face the following behaviour with version 1.3.8 of the plugin:

1. Create a new WordPress installation (with Local, see specs below)
2. Install the Create Block Them plugin
3. Appearance > Create Block Theme > Create child of Twenty Twenty-Three

This results in the below screen. The same happens with the Clone Twenty Twenty-Three option.

WordPress specs:

• WordPress: v6.1.1
• PHP: v8.1.9
• MySQL: v8.0.16
• Local: v6.5.2

What could be the reason for this error?

1. Write the name the user enters in the form to the style variation file as the title attribute

Currently, when creating a global styles variation using the option in the plugin, the title attribute for the new style variation file is not set. This could be taken from the name field and written to the style variation JSON.

2. Consider only writing the saved JSON in the database to the style variation file

Additionally, the entire theme.json is read, and then the updated styles are added to the JSON object. Then that entire object is written to the style variation file. However, it is possible to just write the JSON object stored in the database for that new style variation.