-
Notifications
You must be signed in to change notification settings - Fork 3
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
Conversation
A few questions -
|
bae8441
to
317f9a5
Compare
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.
Yeah, we'll want to update the |
PR for |
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.
* 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
Co-authored-by: Kelly Dwan <[email protected]>
…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]>
… `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
…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); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
… `_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
# 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]>
…` 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
…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
…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
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
…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
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.