Automatically enqueue style.css when creating a blank theme

[annezazu]

Pulling in feedback from the FSE Outreach program's Build A Block Theme exploration:

There is an empty style sheet added when a blank theme is created with CBT plugin. But adding CSS to it doesn’t work until a functions.php is added to enqueue it. I think that style.css should automatically be enqueued or that a functions.php with the enqueue should be included. I am trying to use only the editor, but think that if the stylesheet is there, it should be usable.

[carolinan]

How can we explain to users that the Stylesheet is used because it is required to provide WordPress with information about the theme, like the theme name and version, not to add CSS?
Add a comment to the file?

[annezazu]

Ohh I see. Thanks for clarifying -- limits of my lack of knowledge with themes. I think a comment is a great idea and approach.

[carolinan]

In a way I agree that "if it is there it should work", but in this case it can't be removed even if it is otherwise empty.

I also think that if the person knows that the theme needs a functions.php and knows the css file needs to be enqueud, its not too difficult for them to add it.

So is it more beneficial to:

• enqueu it "in case anyone wants to use it"
  Or,
• not include a file that is not used by default (functions.php), and not enqueu a file that is not used by default (style.css)

[kathrynwp]

This came up again with a user in the forum:
https://wordpress.org/support/topic/create-a-child-theme-for-twenty-twenty-three/

So is it more beneficial to:

- enqueu it "in case anyone wants to use it"
Or,

• not include a file that is not used by default (functions.php), and not enqueu a file that is not used by default (style.css)

I agree very much with @carolinan that it would be much less confusing for users to go with either of these two options.

[askdesign]

I would prefer to use a style.css file than the Additional CSS area in the FSE block editor. The Additional CSS UI and accessibility is dreadful. I find it much simpler to use a style.css file, but to have to enqueue it yourself? Led me down a rabbit hole that I'm finally climbing out of.

[tomfinitely]

Just ran into this issue and it definitely needs some love.

[cre8tivediva]

I agree. Style.css file for me as well. Definitely should be enqueued already, even if it's not used. It will be there for those who want to.

[theaminuli]

Hi @pbking and @mikachan,

I’d like to request to be assigned to this issue. I agree that automatically enqueuing style.css (or including a functions.php that does it) would significantly improve the user experience when creating blank themes. I’m happy to work on a solution that ensures the stylesheet is usable out-of-the-box while keeping best practices in mind.

Thank you!

[t-hamano]

In my opinion, we shouldn't automatically enqueue style.css. The "what" hook to use and "where" to enqueue it will vary from person to person.

// Some developers might want to load the stylesheet only on the frontend
// by calling `wp_enqueue_style` in the callback function of the
// `wp_enqueue_scripts` action hook.
function my_theme_enqueue_frontend_style() {
	wp_enqueue_style(
		'my-theme-style',
		get_template_directory_uri() . '/style.css',
		array(),
		wp_get_theme()->get( 'Version' )
	);
}
add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_frontend_style' );

// Other developers might want to load styles only in the editor by calling
// `add_editor_style` in the callback function of the `after_setup_theme`
// action hook.
function my_theme_enqueue_editor_style() {
	add_editor_style( 'style.css' );
}
add_action( 'after_setup_theme', 'my_theme_enqueue_editor_style' );

// Still other developers might use the `enqueue_block_assets` action hook
// to change block styles.
function my_theme_enqueue_block_assets() {
	wp_enqueue_style(
		'my-theme-style',
		get_template_directory_uri() . '/style.css',
		array(),
		wp_get_theme()->get( 'Version' )
	);
}
add_action( 'enqueue_block_assets', 'my_theme_enqueue_block_assets' );

My suggested approach is to generate a style.css with appropriate guidance in comments, giving theme developers the awareness and choice, rather than implicitly forcing them to enqueue in a certain way. For example:

/*
Theme Name: My Blank Theme
Theme URI:
Author: John Doe
Author URI:
Description: This is my blank theme.
Requires at least: 6.8
Tested up to: 6.8
Requires PHP: 5.7
Version:
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Text Domain: my-blank-theme
Tags:
*/

/*
This file itself is essential for the theme, so do not delete it.

To load the styles you have written here in the frontend or editor, you need to write the appropriate action hook. See the following resources:

- `wp_enqueue_scripts` hook: https://developer.wordpress.org/reference/hooks/wp_enqueue_scripts/
- `add_editor_style` function: https://developer.wordpress.org/reference/functions/add_editor_style/
- `enqueue_block_assets` hook: https://developer.wordpress.org/reference/hooks/enqueue_block_assets/
*/

[bph]

Do come to a.decision, we should consider the audience for this plugin. It's primarily the builders who want to build their theme in the editor and not touch code.

That's how 'decisions, not options' comes in.

I have never built a classic theme so I wouldn't know that I need to modify the functions.php to include the style.css.

It was always there and I made small fixes in the style.css.

Automatically enqueueing the style.css would only work if it's actually enqueued.

I like the comments but one of the.optioms should actually be implemented. And when the builder is ready to change it, they will learn how by reading.the comments.