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

CSS: Try custom properties using location-aware naming scheme #2

Closed
wants to merge 89 commits into from

Conversation

ryelle
Copy link
Owner

@ryelle ryelle commented May 20, 2021

This PR tries replacing the colors in core WP CSS with custom properties, based on the location of the color, --wp-admin--page--background, --wp-admin--heading--color, etc. More naming discussion is in progress on google docs.

Replacing colors and creating names here is a manual process, deciding what to name a color and how to set it up in the collection of existing names (should it inherit from another value, like the input border inherits from the surface border, for example). The intent is to come up with a minimum set of variables that CSS-authors can use to create custom admin color schemes, including dark schemes and high contrast schemes.


I also added a stylelint config to flag any hex color values, which should make it easier to catch all colors. I don't think the RGBA rule is working. This would not be merged into core.

@laras126
Copy link

laras126 commented Jun 17, 2021

A few questions -

  1. Do we want to provide fallback values? I saw not all custom properties had them in the PR so far, but definitely something we should standardize.
  2. Some values are used in wp-includes as well - e.g. #4f94d4 - are these in scope for color schemes?

@ryelle ryelle force-pushed the try/custom-properties branch from bae8441 to 317f9a5 Compare June 24, 2021 17:48
@ryelle ryelle changed the title Try Custom Properties CSS: Try custom properties using location-aware naming scheme Jun 24, 2021
@ryelle
Copy link
Owner Author

ryelle commented Jun 24, 2021

Do we want to provide fallback values? I saw not all custom properties had them in the PR so far, but definitely something we should standardize.

I wasn't adding them because I think we can be sure the values will be defined, and wouldn't want to fall back to the wrong value if there's a custom color scheme. I don't have a strong opinion on this either way, though.

Some values are used in wp-includes as well - e.g. #4f94d4 - are these in scope for color schemes?

Yeah, we'll want to update the wp-includes CSS too. There's some vendor CSS (like from Gutenberg) that we can leave alone, but pretty much anything in wp-includes/css/*.css should get looked at.

@0aveRyan
Copy link

PR for login.css is #4 🕺

Repeating some colors as the existing matches had names that were specific enough that using them didn't make sense. Also adding some others that were not already existing which will hopefully be able to be consolidated. I included the `colors` file as a dependency for the install css which broke the layout, hence the `body { height: auto; }` addition. Idelaly this page would be rebuilt with some more consistent page structure, but that's beyond scope of this PR.
circlecube and others added 9 commits September 2, 2021 15:03
* replace nav-menu colors with custom properties

* Use existing custom properties

Co-authored-by: Kelly Dwan <[email protected]>
# Conflicts:
#	src/wp-admin/css/list-tables.css
#	src/wp-admin/css/nav-menus.css
#	src/wp-includes/css/wp-pointer.css
Update custom properties to use mostly existing properties
…vert colors changes (#22)

* Bring back legacy color CSS handling

* Add a custom-properties style dependency for our color variable CSS file

* Remove dependencies from `colors`, in favor of explicitly calling `colors` after `wp-admin`
* admin edit custom color properties

* Update src/wp-admin/css/edit.css

* Update src/wp-admin/css/edit.css

Co-authored-by: Dave Ryan <[email protected]>
Co-authored-by: Kelly Dwan <[email protected]>
* wp admin media custom color properties

* media custom properties missed in first pass

Co-authored-by: Dave Ryan <[email protected]>
ryelle pushed a commit that referenced this pull request Sep 22, 2021
… `wpdb::_real_escape()`.

The PHP native `mysqli_real_escape_string()` function expects to be passed a string as the second parameter and this is not a nullable parameter.

Passing `null` to it will result in a `mysqli_real_escape_string(): Passing null to parameter #2 ($string) of type string is deprecated` notice on PHP 8.1.

Previously, an input type check was put in place to prevent fatal errors on PHP 8.0 when an array, object or resource was passed. Changeset [48980].

A `null` value was explicitly excluded from that check, even though a `null` value being passed would only ever result in an empty string anyway.

This commit changes the previous input type check to also bow out early for `null` values and to automatically return an empty string for those.

Refs:
- https://www.php.net/manual/en/mysqli.real-escape-string.php
- https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg

Follow-up to [48980].

Props jrf, hellofromTonya.
See #53635.

git-svn-id: https://develop.svn.wordpress.org/trunk@51799 602fd350-edb4-49c9-b593-d223f7449a82
ryelle pushed a commit that referenced this pull request Sep 22, 2021
…IncludesPlugin::test_get_plugin_files_folder()`.

The `Tests_Admin_IncludesPlugin::_create_plugin()` expects the first parameter to be a text string to be written to a plugin file using `fwrite()`.

Passing null causes a `fwrite(): Passing null to parameter #2 ($data) of type string is deprecated` notice.

Ref: https://www.php.net/manual/en/function.fwrite

Follow-up to [31002]. [41806].

Props jrf, hellofromTonya.
See #53635.

git-svn-id: https://develop.svn.wordpress.org/trunk@51800 602fd350-edb4-49c9-b593-d223f7449a82
0 0 0 1px #4f94d4,
0 0 2px 1px rgba(79, 148, 212, 0.8);
color: var(--wp-admin--link--color--hover);
box-shadow: var(--wp-admin--box-shadow--focus);

Choose a reason for hiding this comment

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

Are you doing just colors or entire box shadows?

Copy link
Owner Author

Choose a reason for hiding this comment

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

Still open to discussion, but in places where there are multiple box shadows, I think it makes sense to declare the whole value. For example, --wp-admin--box-shadow--focus is a pretty common box-shadow on focused items, and there is really no reason to control one of the shadow value but not the other, so for simplicity, it's one custom property.

background-color: #fff;
box-shadow: 0 1px 1px 0 rgba(0, 0, 0, 0.1);
background-color: var(--wp-admin--surface--background);
box-shadow: 0 1px 1px 0 rgb(var(--wp-admin--shadow) / 0.1);

Choose a reason for hiding this comment

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

Does rgb(var(--wp-admin--shadow) / 0.1) work?

Copy link
Owner Author

Choose a reason for hiding this comment

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

Yes, this is the space-separated format which was introduced with CSS Colors level 4 - it ends up resolving to rgb(0 0 0 / 0.1), equivalent to rgba(0, 0, 0, 0.1);. I wouldn't pay too much attention to the format here, how to handle these transparent values is also an open discussion.

Choose a reason for hiding this comment

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

Ah, I haven't kept up with that one. I see it's at 92.9% at caniuse.
It looks crazy. I think you have to consider the format, since this would only work with some values. If the properties need to be interchangeable, the format is important.

ryelle pushed a commit that referenced this pull request Oct 21, 2021
… `_mb_substr()`.

The `_mb_substr()` function expects a string for the `$str` parameter, but does not do input validation. This function contains a `preg_match_all()` which also expects a string type for the given subject (i.e. `$str`). 

Passing `null` to this parameter results in `preg_match_all(): Passing null to parameter #2 ($subject) of type string is deprecated` notice on PHP 8.1.

To maintain the same behaviour as before, a guard clause is added to bail out early when `$str` is passed as `null`. The outcome will, in that case, only ever be an empty string.

Note: this does mean that the `_mb_substr()` function now has a subtle difference in behaviour compared to the PHP native `mb_substr()` function as the latter ''will'' throw the deprecation notice.

The existing tests already cover this issue.

Follow-up to [17621], [36017], [32364].

Props jrf, hellofromTonya.
See #53635.

git-svn-id: https://develop.svn.wordpress.org/trunk@51853 602fd350-edb4-49c9-b593-d223f7449a82
ryelle and others added 2 commits October 21, 2021 12:43
# Conflicts:
#	src/wp-admin/css/common.css
* site health colors custom properties

* merge try/custom-properties and resolve conflicts

* move entire box-shadow declaration into property

* Remove duplicated properties

* Use the "modern tabbed page" property for the box shadow

Co-authored-by: Dave Ryan <[email protected]>
Co-authored-by: Kelly Dwan <[email protected]>
ryelle pushed a commit that referenced this pull request Nov 22, 2021
…` in `get_core_checksums()` and `wp_version_check()`.

The `get_core_checksums()` and `wp_version_check()` functions call the PHP native `http_build_query()` function, the second parameter of which is the ''optional'' `$numeric_prefix` parameter which expects a non-nullable `string`.

A parameter being optional, however, does not automatically make it nullable.

As of PHP 8.1, passing `null` to a non-nullable PHP native function will generate a deprecation notice.

In this case, this function call yielded a `http_build_query(): Passing null to parameter #2 ($numeric_prefix) of type string is deprecated` notice.

Changing the `null` to an empty string fixes this without a backward compatibility break.

References:
* [https://www.php.net/manual/en/function.http-build-query.php PHP Manual: http_build_query()]
* [https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg PHP RFC: Deprecate passing null to non-nullable arguments of internal functions]

Follow-up to [18697], [25540].

Props bjorsch, kraftbj, hellofromTonya, jrf.
See #54229.

git-svn-id: https://develop.svn.wordpress.org/trunk@52019 602fd350-edb4-49c9-b593-d223f7449a82
ryelle pushed a commit that referenced this pull request Nov 22, 2021
…n array to avoid PHP 8+ TypeError fatal error.

Adds an `is_array()` check before the `in_array()`. Why? `in_array()` requires a array for the haystack. Any other data type will cause a fatal error on PHP 8.0 or higher:

{{{
Fatal error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array
}}}

As this is a new filter, this type check properly guards to avoid the fatal error.

Follow-up to [52084].

See #54331.

git-svn-id: https://develop.svn.wordpress.org/trunk@52085 602fd350-edb4-49c9-b593-d223f7449a82
@erikyo erikyo mentioned this pull request Jan 6, 2022
@ryelle ryelle deleted the branch master May 5, 2022 14:16
@ryelle ryelle closed this May 5, 2022
ryelle pushed a commit that referenced this pull request Feb 28, 2023
…heme()` tests.

In the tests for updating a theme via Ajax, `wp_installing( true )` is called to prevent `wp_update_themes()` from running.

This worked as expected in `test_update_theme()`, however, it was missed in `test_uppercase_theme_slug()`, which was accidentally relying on the `wp_installing()` status not being properly restored in the previous test.

Now that the `wp_installing()` status was corrected in [54723], the latter test started throwing an error on PHP 8.2:
{{{
1) Tests_Ajax_wpAjaxUpdateTheme::test_uppercase_theme_slug
http_build_query(): Passing null to parameter #2 ($numeric_prefix) of type string is deprecated

/var/www/src/wp-includes/Requests/Transport/cURL.php:345
/var/www/src/wp-includes/Requests/Transport/cURL.php:135
/var/www/src/wp-includes/class-requests.php:381
/var/www/src/wp-includes/class-wp-http.php:395
/var/www/src/wp-includes/class-wp-http.php:615
/var/www/src/wp-includes/http.php:179
/var/www/src/wp-includes/update.php:719
/var/www/src/wp-admin/includes/ajax-actions.php:4292
/var/www/src/wp-includes/class-wp-hook.php:308
/var/www/src/wp-includes/class-wp-hook.php:332
/var/www/src/wp-includes/plugin.php:517
/var/www/tests/phpunit/includes/testcase-ajax.php:265
/var/www/tests/phpunit/tests/ajax/wpAjaxUpdateTheme.php:157
}}}

Replicating the `wp_installing()` status changes in this test too resolves the error.

Follow-up to [38168], [38710], [54722], [54723].

See #56793.

git-svn-id: https://develop.svn.wordpress.org/trunk@54725 602fd350-edb4-49c9-b593-d223f7449a82
ryelle pushed a commit that referenced this pull request Jun 24, 2024
When saving options from the Settings page, include the `'ping_sites'` option in the allowed "writing" options list only when the `'blog_public'` option is `'1'`.

Fixes a PHP 8.1 and above "null to non-nullable" deprecation notice in `sanitize_option()` ([https://core.trac.wordpress.org/browser/trunk/src/wp-includes/formatting.php?annotate=blame#L4952 which happens when here] as part of [22255]):

{{{
Deprecated: explode(): Passing null to parameter #2 ($string) of type string is deprecated in .../wp-includes/formatting.php
}}}

**Explanation**

[https://developer.wordpress.org/apis/options/#writing Per the documentation], the `ping_sites` option requires the `'blog_public'` option to have a value of `'1'` and must be a `string` data type. `null` is not valid for this option.

The relationship between the 2 options shows itself in the `options-writing.php` code ([https://core.trac.wordpress.org/browser/tags/6.5.4/src/wp-admin/options-writing.php#L233 shown here] and in [4326]), as the `textarea#ping_sites` only renders when `'1' === get_option( 'blog_public' )`.

**What happens if `'blog_public'` is not `'1'`?**

The `'ping_sites'` option will not be a field on the page. Upon saving:

* HTTP POST (`$_POST`) does not include `'ping_sites'`. 
* Before this commit:
   * The [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/options.php#L333 option's value was set to] `null` before being passed to `update_option()`. 
   * `update_option()` invokes `sanitize_option()`.
   * A `null` value for the `'ping_sites'` case was passed to `explode()`, which threw a deprecation notice on PHP 8.1 and above.
* With this commit, the `'ping_sites'` option is no longer included in the allow list and thus will not be passed to `update_options()` > `sanitize_option()` > `explode()`.

Follow-up to [22255], [12825], [4326], [949].

Props kitchin, SergeyBiryukov, swissspidy, devmuhib, rajinsharwar, hellofromTonya.
Fixes #59818.

git-svn-id: https://develop.svn.wordpress.org/trunk@58425 602fd350-edb4-49c9-b593-d223f7449a82
ryelle pushed a commit that referenced this pull request Jun 24, 2024
…t_mime_types().

Fixes a PHP 8.1 and above "null to non-nullable" deprecation notice in `get_available_post_mime_types()`:

{{{
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in ./wp-includes/post.php on line 3395
}}}

[https://developer.wordpress.org/reference/functions/get_available_post_mime_types/#return This function is documented] to:
* Return `An array of MIME types.`
* as an array of `string`s, i.e. `string[]`.

A `null` or empty element within the returned array is not a valid MIME type. If a `null` exists in the returned array, it is the root cause of PHP throwing the deprecation notice.

This commit removes the `null` and empty elements from the returned array of MIME types. It also adds a unit test.

Follow-up to [56623], [56452].

Props nosilver4u, jrf, ironprogrammer, antpb, antonvlasenko, rajinsharwar, hellofromTonya. 
Fixes #59195.

git-svn-id: https://develop.svn.wordpress.org/trunk@58437 602fd350-edb4-49c9-b593-d223f7449a82
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants