Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making properties, attributes and behaviors of blocks more configurable #31310

Open
mkkeck opened this issue Apr 29, 2021 · 0 comments
Open

Making properties, attributes and behaviors of blocks more configurable #31310

mkkeck opened this issue Apr 29, 2021 · 0 comments
Labels
[Type] Feedback Issues that relate purely to feedback on a feature that isn't necessarily actionable

Comments

@mkkeck
Copy link

mkkeck commented Apr 29, 2021

A simple way to configure blocks is missing

As a theme developer for WordPress I am sometimes really frustated, specially on new releases of Gutenberg. For example with the WordPress 5.7.1 there was a new release of Gutenberg, wich adds a color panel for social links.
Prior, I've removed all not wanted variations, styles and services for the social links block in my theme. I have styled the social icons with colors, sizes etc the way I needed in my theme styles. Perfect, only things I and my 'customer' needed. But with the update of WordPress 5.7.1 there is a color panel for social links available, which can leed with wrong settings in an accessibility problem of social icons (white icons on white background). Now, why I have to "hack" arround the block "social links" but the new release sabotages my work?
What the hell, where is it documented, how can I disable and of course why is there no simple opt-in or opt-out?

Another example: My theme uses a global button style, specially the border radius. I and my customers don't need a possibilty to accidental overwrite the theme styles. It's better, all buttons have the same look.
But there is no way to disable the settings panel for border radius!

Solutions

First of all, new fetaures which could sabotage the work of theme developers, direct or by wrong user settings in block editor, should have an opt-in or opt-out. This should be documented with a message on the update screen.

Personally I think, it would be really better only to put features into blocks every user really needs. All other stuff should be opt-in. This can leed in a simpler, smaller and stable code base and increase perfomance. Many frameworks and libraries I've seen last years follow this. A handfull of core functionality, for more include modules and/or opt-in.

Less is (often) more

@carolinan carolinan added the [Type] Feedback Issues that relate purely to feedback on a feature that isn't necessarily actionable label May 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Feedback Issues that relate purely to feedback on a feature that isn't necessarily actionable
Projects
None yet
Development

No branches or pull requests

2 participants