Bug: wp_check_filetype_and_ext returns type and ext as false for font files

[madhudollu]

the function wp_check_filetype_and_ext returns both type and ext as false for font files (.ttf, .woff, .woff2 etc..)

This is because the $real_mime for the font files is application/octet-stream and the following condition has no check for font mimes. (font/ttf, font/woff)

// file: src/wp-includes/functions.php
// line: 3184

if ( in_array( $real_mime, $nonspecific_types, true ) ) {
  if ( ! in_array( substr( $type, 0, strcspn( $type, '/' ) ), array( 'application', 'video', 'audio' ), true ) ) {
    $type = false;
    $ext  = false;
  }
}

[hellofromTonya]

Hello @madhudollu,

Welcome back to WordPress Core's Trac :)

#40175 is tracking upload validation and mime handling. Let's continue the discussion there.

After the changes in Core-59277, Compose files are manually passed to the Docker commands. If a docker-compose.override.yml file is present, it won't be utilized. This attempts to detect that and include the file in the list that is passed.

Trac ticket:

@xknown env variable for which part? Do you mean for the additional value of volumes in the old-php-mysql-84.override.yml file?

I just did some testing, and it seems that Docker fails when an empty value for a volume is supplied. The new override file is needed _in addition_ to the other two supplied in the default docker-compose.yml file, not instead of. So I'm not sure how to get it working with an environment variable with the limited variable substitution available.

@xknown env variable for which part? Do you mean for the additional value of volumes in the old-php-mysql-84.override.yml file?

I just did some testing, and it seems that Docker fails when an empty value for a volume is supplied. The new override file is needed _in addition_ to the other two supplied in the default docker-compose.yml file, not instead of. So I'm not sure how to get it working with an environment variable with the limited variable substitution available.

No, I was just wondering if it'd make sense to add something like the snippet below to utils.js

if ( typeof process.env.DOCKER_COMPOSE_CONFIG_OVERRIDE !== 'undefined' ) {
  composeFiles = composeFiles + process.env.DOCKER_COMPOSE_CONFIG_OVERRIDE
}

No, I was just wondering if it'd make sense to add something like the snippet below to utils.js

if ( typeof process.env.DOCKER_COMPOSE_CONFIG_OVERRIDE !== 'undefined' ) {
  composeFiles = composeFiles + process.env.DOCKER_COMPOSE_CONFIG_OVERRIDE
}

Ah, I see! I think if we find out that people are supplying custom override files we could consider that. But I don't know that is likely to be the case.

We also ​currently recommend using that file name in the README file for working with MySQL < 8.0 on Apple silicon chips. An env variable would also require an additional step (create the file, update the variable). So I think I prefer trying this approach first.

No, I was just wondering if it'd make sense to add something like the snippet below to utils.js

if ( typeof process.env.DOCKER_COMPOSE_CONFIG_OVERRIDE !== 'undefined' ) {
  composeFiles = composeFiles + process.env.DOCKER_COMPOSE_CONFIG_OVERRIDE
}

Ah, I see! I think if we find out that people are supplying custom override files we could consider that. But I don't know that is likely to be the case.

We also ​currently recommend using that file name in the README file for working with MySQL < 8.0 on Apple silicon chips. An env variable would also require an additional step (create the file, update the variable). So I think I prefer trying this approach first.

Merged in https://core.trac.wordpress.org/changeset/59283.