[wp-trac] [WordPress Trac] #54910: 5.9 Bug - Blank Home Page
WordPress Trac
noreply at wordpress.org
Thu Jan 27 11:19:20 UTC 2022
#54910: 5.9 Bug - Blank Home Page
--------------------------+------------------------------
Reporter: cantuaria | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Themes | Version: 5.9
Severity: major | Resolution:
Keywords: | Focuses:
--------------------------+------------------------------
Comment (by Ov3rfly):
Replying to [comment:8 poena]:
> because the purpose of these type of themes is to be easier to create
It is not easier for existing users with existing sites, they were there
first.
> would be against the end goal.
The end goal is to provide continuously working websites when updates are
installed, see also [https://wordpress.org/about/ Our mission]:
''... The basic WordPress software is simple and predictable so you can
easily get started. ...''
Requirement of changes in legacy themes and plugins are ''not''
predictable.
> A functions.php file is not required for block themes,
A functions.php file is also not required for legacy themes.
> as these files are of a non standard format
There is no standard format for own files, there are no required folders
in legacy themes.
The WordPress community has decided to use the existing WordPress
installation base with millions and millions of legacy themes and plugins
to roll out all the new theme features into.
There would have been the possibility to fork/create a completely new
project ''BlockPress'' or similar and cutting all technical debt and
backwards compatibility, some also have suggested this when Gutenberg was
started, but the community has decided otherwise.
There also would have been the possibility to introduce a new `wp-content
/block-themes/` location for themes with breaking new features, but the
community has decided otherwise.
Now everybody in the complete WordPress userbase has to live with this
technical debt, both existing users and new creators.
If a new theme for whatever reasons can not use functions.php to call
add_theme_support(), it would be simple as a core fallback to implement a
new field in `style.css` header or `theme.json` which the core then
interprets as `add_theme_support( 'full-site-editing' )`. Then the exiting
API with
[https://developer.wordpress.org/reference/functions/get_theme_support/
get_theme_support()] can be used everywhere (similar to #54917) to
identify a full site editing theme.
An example how to add new fields in header can be seen in a recent change
[https://make.wordpress.org/core/2021/06/29/introducing-update-uri-plugin-
header-in-wordpress-5-8/ in WordPress 5.8], so the relevant code is
already there and well tested.
Requirement of adding an opt-out in legacy themes is not an option.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/54910#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list