You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has been on my mind for months so I'm creating an issue for discussion.
With Full Site Editing (FSE for short), the role of themes in WordPress changes, there is no denying that there will be a shift.
A theme's role will be to provide a set of default template-parts, templates, styles and maybe scripts.
Up until now, themes were responsible for a lot more than that, which is why using a theme in WordPress was mandatory. You just couldn't build a website without a theme.
With FSE however, the status quo changes.
A theme can have as little as an index.html template, or as much as a "legacy" theme with hundreds of files.
The problems:
A theme is no longer mandatory
If a theme does not add any extra styles and simply uses the default core block styles, then the user creates the templates they need. At that point the theme is not used at all, it's simply there to make WordPress work. So... why even use a theme?
Developing an FSE theme is not as easy as it should be
When building an FSE theme, the author needs to create templates for index, singe posts, single pages, archives, home etc.
In most cases these will be pretty standard and most likely copy-pasted across most themes. So... why not provide a set of fallback templates? If an FSE theme needs to override the home template, then they shouldn't have to create all template files. If they have fancy styles or scripts for blocks but use a pretty standard structure for templates, why should they be forced to add templates?
A possible solution
We already provide a fallback stylesheet for block styles. If themes need to override it, they dequeue it and add their own.
We could provide a default/fallback set of templates & template-parts too. This would allow theme-authors to focus on what they want to do instead of start from scratch every time they want to do something.
What this means, in turn, is that WordPress could function without a "theme".
When a user installs WordPress, they'd have a functioning website, using the default core templates with core block styles. If they want to install a theme/templates-and-styles-collection they are free to do so, but it is not a prerequisite in order to run a WP site. If they want to custom-edit a template they can do so.
WordPress Core can offer an unopionated starting point both for users and theme-authors.
Technical Considerations
Themes have been in use in WordPress for more than a decade so there is code all over the place for them.
The good news is that most of that code revolves around legacy themes, and the parts that have to be addressed in FSE have already been addressed (not entirely, but most of them have).
Using a default set of templates in WP-Core could be done easily be creating a new "blank-slate" starting point. It can be inside the wp-content/themes folder so any FSE theme can easily become a child-theme of that, or we can go further and assume that all FSE themes are a child-theme of that blank-slate set of templates.
That blank-slate would contain the basics: A set of standardized templates, no styles and no scripts. The default block-styles would be used and any scripts that would get auto-enqueued by the blocks used.
Another solution would be to not include the standard/fallback templates inside wp-content/themes, but instead embed them in core and hide the theme from the dashboard. For the sake of backward-compatibility though and clarity I think that option should be avoided.
The text was updated successfully, but these errors were encountered:
A set of default templates would still amount to what is essentially a theme — they make decisions on structure, order, layout, etc. This proposal would bring us back to the very old Classic theme times pre Kubrick when theme was implicit :)
In the end, WordPress would want to iterate on any default template it provides through the years without disrupting people's websites. To do that elegantly, it'll bring us all the way back to discovering themes again. Right now themes allow core to have different site designs year over year without disrupting users of the platform.
We are already providing in the plugin a set of default templates, but they are only meant to be used for testing as we go, not to be shipped with WordPress. Ultimately, there's no "set of standardized templates" that would work, it's just going to be different themes. Core might offer some patterns for certain parts of a template (a blog list, navigation, etc).
This has been on my mind for months so I'm creating an issue for discussion.
With Full Site Editing (FSE for short), the role of themes in WordPress changes, there is no denying that there will be a shift.
A theme's role will be to provide a set of default template-parts, templates, styles and maybe scripts.
Up until now, themes were responsible for a lot more than that, which is why using a theme in WordPress was mandatory. You just couldn't build a website without a theme.
With FSE however, the status quo changes.
A theme can have as little as an
index.html
template, or as much as a "legacy" theme with hundreds of files.The problems:
A theme is no longer mandatory
If a theme does not add any extra styles and simply uses the default core block styles, then the user creates the templates they need. At that point the theme is not used at all, it's simply there to make WordPress work. So... why even use a theme?
Developing an FSE theme is not as easy as it should be
When building an FSE theme, the author needs to create templates for index, singe posts, single pages, archives, home etc.
In most cases these will be pretty standard and most likely copy-pasted across most themes. So... why not provide a set of fallback templates? If an FSE theme needs to override the
home
template, then they shouldn't have to create all template files. If they have fancy styles or scripts for blocks but use a pretty standard structure for templates, why should they be forced to add templates?A possible solution
We already provide a fallback stylesheet for block styles. If themes need to override it, they dequeue it and add their own.
We could provide a default/fallback set of templates & template-parts too. This would allow theme-authors to focus on what they want to do instead of start from scratch every time they want to do something.
What this means, in turn, is that WordPress could function without a "theme".
When a user installs WordPress, they'd have a functioning website, using the default core templates with core block styles. If they want to install a theme/templates-and-styles-collection they are free to do so, but it is not a prerequisite in order to run a WP site. If they want to custom-edit a template they can do so.
WordPress Core can offer an unopionated starting point both for users and theme-authors.
Technical Considerations
Themes have been in use in WordPress for more than a decade so there is code all over the place for them.
The good news is that most of that code revolves around legacy themes, and the parts that have to be addressed in FSE have already been addressed (not entirely, but most of them have).
Using a default set of templates in WP-Core could be done easily be creating a new "blank-slate" starting point. It can be inside the
wp-content/themes
folder so any FSE theme can easily become a child-theme of that, or we can go further and assume that all FSE themes are a child-theme of that blank-slate set of templates.That blank-slate would contain the basics: A set of standardized templates, no styles and no scripts. The default block-styles would be used and any scripts that would get auto-enqueued by the blocks used.
Another solution would be to not include the standard/fallback templates inside
wp-content/themes
, but instead embed them in core and hide the theme from the dashboard. For the sake of backward-compatibility though and clarity I think that option should be avoided.The text was updated successfully, but these errors were encountered: