[wp-trac] [WordPress Trac] #54910: 5.9 Bug - Blank Home Page

[WordPress Trac]

#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