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

Global Styles: keep core and theme preset variables and classes even if they are overwritten #27082

Conversation

jorgefilipecosta
Copy link
Member

Depends on: #27077

This PR makes sure core and global styles preset variables and classes are kept even if they are overwritten.

Users may change or delete the presets, and the UI (e.g: color palette) should reflect that. But if the theme is using the preset variable in other place we should not break the theme and should still have the variable present. This PR makes sure the variables and classes are always present.

How has this been tested?

I added the 2021 blocks theme.
I deleted the preset background color.
I verified the background color was still applied,

@jorgefilipecosta jorgefilipecosta added the Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json label Nov 18, 2020
@github-actions
Copy link

github-actions bot commented Nov 18, 2020

Size Change: +173 B (0%)

Total Size: 1.2 MB

Filename Size Change
build/edit-site/index.js 23.5 kB +173 B (0%)
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.14 kB 0 B
build/annotations/index.js 3.8 kB 0 B
build/api-fetch/index.js 3.42 kB 0 B
build/autop/index.js 2.83 kB 0 B
build/blob/index.js 665 B 0 B
build/block-directory/index.js 8.72 kB 0 B
build/block-directory/style-rtl.css 943 B 0 B
build/block-directory/style.css 942 B 0 B
build/block-editor/index.js 133 kB 0 B
build/block-editor/style-rtl.css 11.3 kB 0 B
build/block-editor/style.css 11.3 kB 0 B
build/block-library/editor-rtl.css 8.96 kB 0 B
build/block-library/editor.css 8.96 kB 0 B
build/block-library/index.js 148 kB 0 B
build/block-library/style-rtl.css 8.23 kB 0 B
build/block-library/style.css 8.23 kB 0 B
build/block-library/theme-rtl.css 792 B 0 B
build/block-library/theme.css 793 B 0 B
build/block-serialization-default-parser/index.js 1.87 kB 0 B
build/block-serialization-spec-parser/index.js 3.06 kB 0 B
build/blocks/index.js 48.1 kB 0 B
build/components/index.js 172 kB 0 B
build/components/style-rtl.css 15.3 kB 0 B
build/components/style.css 15.3 kB 0 B
build/compose/index.js 9.93 kB 0 B
build/core-data/index.js 14.8 kB 0 B
build/data-controls/index.js 827 B 0 B
build/data/index.js 9.59 kB 0 B
build/date/index.js 11.2 kB 0 B
build/deprecated/index.js 769 B 0 B
build/dom-ready/index.js 571 B 0 B
build/dom/index.js 4.92 kB 0 B
build/edit-navigation/index.js 11.2 kB 0 B
build/edit-navigation/style-rtl.css 881 B 0 B
build/edit-navigation/style.css 885 B 0 B
build/edit-post/index.js 306 kB 0 B
build/edit-post/style-rtl.css 6.45 kB 0 B
build/edit-post/style.css 6.44 kB 0 B
build/edit-site/style-rtl.css 3.86 kB 0 B
build/edit-site/style.css 3.86 kB 0 B
build/edit-widgets/index.js 26.4 kB 0 B
build/edit-widgets/style-rtl.css 3.13 kB 0 B
build/edit-widgets/style.css 3.13 kB 0 B
build/editor/editor-styles-rtl.css 476 B 0 B
build/editor/editor-styles.css 478 B 0 B
build/editor/index.js 43.3 kB 0 B
build/editor/style-rtl.css 3.85 kB 0 B
build/editor/style.css 3.85 kB 0 B
build/element/index.js 4.62 kB 0 B
build/escape-html/index.js 735 B 0 B
build/format-library/index.js 6.86 kB 0 B
build/format-library/style-rtl.css 547 B 0 B
build/format-library/style.css 548 B 0 B
build/hooks/index.js 2.16 kB 0 B
build/html-entities/index.js 623 B 0 B
build/i18n/index.js 3.57 kB 0 B
build/is-shallow-equal/index.js 698 B 0 B
build/keyboard-shortcuts/index.js 2.85 kB 0 B
build/keycodes/index.js 1.94 kB 0 B
build/list-reusable-blocks/index.js 3.1 kB 0 B
build/list-reusable-blocks/style-rtl.css 476 B 0 B
build/list-reusable-blocks/style.css 476 B 0 B
build/media-utils/index.js 5.31 kB 0 B
build/notices/index.js 1.82 kB 0 B
build/nux/index.js 3.42 kB 0 B
build/nux/style-rtl.css 671 B 0 B
build/nux/style.css 668 B 0 B
build/plugins/index.js 2.56 kB 0 B
build/primitives/index.js 1.43 kB 0 B
build/priority-queue/index.js 790 B 0 B
build/redux-routine/index.js 2.84 kB 0 B
build/reusable-blocks/index.js 3.07 kB 0 B
build/rich-text/index.js 13.4 kB 0 B
build/server-side-render/index.js 2.77 kB 0 B
build/shortcode/index.js 1.69 kB 0 B
build/token-list/index.js 1.27 kB 0 B
build/url/index.js 4.05 kB 0 B
build/viewport/index.js 1.86 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.22 kB 0 B

compressed-size-action

Base automatically changed from add/lodash-set-equivalent-to-php-utils to master November 20, 2020 19:01
Squashed commits:
[0ef9982] Global Styles: Keep core and theme preset classes and variables even if they are overwritten.
@jorgefilipecosta jorgefilipecosta force-pushed the update/keep-core-and-theme-preset-variables-and-classes-even-if-they-are-overwritten branch from a763bd4 to a2040a3 Compare November 20, 2020 19:23
@oandregal
Copy link
Member

👋 I've been looking at the current state of how user-provided colors work and this PR. What if we made this work this way:

  • Users can add/update/remove their own new colors.
  • Users can modify (but not remove) the color value of core/theme colors.

What do you think? I'm not convinced allowing users to remove theme colors is a good thing. It sets false expectations that we can't really control (that color is not used) and comes with some conceptual&implementation complexity I don't think we need at the moment.

@@ -177,7 +177,7 @@ class WP_Theme_JSON {
*/
const PRESETS_METADATA = array(
array(
'path' => array( 'settings', 'color', 'palette' ),
Copy link
Member

@oandregal oandregal Nov 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we already discussed this? I may be dreaming, though 😅 so I'm going to list why I don't think this is a good idea:

  • it forces all the code that processes the presets to hold a partial reference to its path (settings), which they shouldn't need to.
  • we can't automate updating the docs from this info without also holding a reference to settings
  • a reader of the code can't know where these are sourced from without looking at how they're processed

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @nosolosw,
I applied this change here because as part of this PR I needed to retrieve and set presets from deactivatedSettings instead of from settings.


						gutenberg_experimental_set(
							$this->contexts[ $context ]['deactivatedSettings'],
							$preset['path'],

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the caveat that I'm not sure this should work this way, as I mentioned below, I also wanted to share that perhaps is a way to balance both needs?

@jorgefilipecosta
Copy link
Member Author

Hi @nosolosw thank you for the review. Your suggestions were implemented at #27250.

@oandregal oandregal deleted the update/keep-core-and-theme-preset-variables-and-classes-even-if-they-are-overwritten branch November 25, 2020 11:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants