The team is now working on the WordPress Interactivity API. This unblocks the same UX Frontity framework enabled but directly in WordPress Core, fully compatible with the new Site Editor.
In frontity themes are structurally the same than any other package. But treating them at the same level has some problems to start understanding how Frontity work:
Themes are a special type of packages (the most important one?) because no frontity project has sense without a theme
For wordpress developers a theme and plugins (packages) are separated concepts and easier to understand
With the current way of defining a frontity project through frontity.settings.js you have to understand to start working with a theme
Namespaces (a namespace is asked when create-package and in frontity.seetings.js you see things such as state.theme.someThing
Packages
Packages are organized though namespaces
Examples
Possible solution
Create another command called create-theme
This command:
Will automatically assign the theme namespace
We could provide templates for different types of themes (or just re-using exisitng themes code into a new one)
Regarding this, I’ve seen you opened another thread with the same description, I think it’s better if we keep the discussion in the same place, so let’s take about this here. We may need to update this description as well so the purpose of this specific feature is clear.
Regarding the feature itself, just to understand it better, what you suggest is to create a command that would create a package with the theme namespace right?
Right now, in order to create a theme, you have to run npx frontity create-package and select theme when the CLI asks you for the namespace. This feature would skip that step and use the theme namespace directly?
What do you mean with “provide templates for different types of themes”? Do you mean to create starter themes so users don’t have to code the themes from scratch? I think the purpose of the create-package (or create-theme) should be to start from scratch. If you want to start from a starter theme you should just install the starter theme and modify it at your will right? Just as many users are doing with mars-theme?
juanma8
Yes
I think it will improve a lot the creation of themes for Frontity, if we provide several boilerplates when creating a theme. The problem of doing changes to mars-theme is that from there to publish the theme you have to:
create a new package with a custom name
selecting namespace theme
copy all the files you’ve modified in mars-theme into the new theme
change the frontity.settings.js to work with the new theme
check your changes with your custom theme
publish the theme
This is kind of a “hack”. Modifying “mars-theme” for your own project it’s OK if you don’t want to publish your theme, but I think we’re not making it easy for those who want to work in their own themes with the idea of publishing it at some point.
SantosGuillamot9
Okay, then I guess it shouldn’t be difficult to implement this first part as the logic would be the same than using npx frontity create-package --namespace theme, which is already working.
Regarding this, I agree that using boilerplates to be able to create themes faster is a great idea. I think you don’t need all these steps. If you want to start a new theme from a starter (or boilerplate), you would just need to:
Install the starter theme you want to use (mars for example), in a Frontity project.
Rename the starter theme to whatever you want.
Publish your theme with npm publish once you’ve made the changes you consider.
juanma10
The workflow you say is enough, you’re right. But renaming the starter theme to whatever you want is not as simple as that
As I understand, to rename a starter theme (let’s say mars-theme) into a custom name so it can be published with this new name you have to do changes in
Folder name
Rename the folder name from packages/mars-theme to packages/my-custom-theme
package.json
Rename the dependency name and the proper path to the package
Rename the field name. in the object exported in this file.
Also the variable name should also be renamed into one more related to the theme name (although this is just for semantic purposes as it doesn’t affect the beavior as long as the variable is exported)
Related to this last one thought, maybe this file should be defined using the formula…
All these steps feels kind of a “hack” and maybe it would be much more elegant (and easier to understand) if we can do all these changes for the user with a simple command and the ability of creating a custom theme from a boilerplate.
juanma11
In the way I see it, most people will use another theme as base to create a custom theme.
For this, I think there are two ways right now.
Start the project with a default theme (mars-theme) + do the proper changes + rename it to a custom theme (with the steps explained above)
Start the project with a default theme (mars-theme) + do the proper changes + create a new package (theme) w/ a custom name + copying & pasting the src folder from mars-theme to the new one
This second approach still require doing changes to packages/my-custom-theme/src/components/index.js and frontity.settings.js as explained above)
SantosGuillamot12
Yes, I think those are the files you need to change right now. I was just stating it because, if we automate it, I don’t know which way would be easier.