Closed jerome-pilotin closed 11 months ago
@jerome-pilotin Hey Jerome, what OS are you running? And could you give us a sample file name that's affected?
We've not had any other reports of this, and my testing can't reproduce here!
We're running our preproduction environment on RockyLinux 8 through Lando (a slightly customized version of the default WordPress recipe, ie. a docker container with Apache >2.4, latest PHP 7.4). The only specific thing I can think of is that we're running with custom permissions (775/664 instead of 755/644).
The files that are created with the wrong name are in the right place (our-theme/acf-json
) but with a dash in place of the underscore. The content is correct and can be safely copy-pasted in the original file.
As an example, group_64d64536719c8.json
would become group-64d64536719c8.json
. The key inside refers to the correct group, with the underscore. In WP Admin, when editing my field group, in the metabox in the JSON info tooltip, the correct name with an underscore is used, but the content of the wrong one is used instead.
When accessing that field group at a location that can use it, the content of the correct file is used.
Please note that we're using a plugin called PiloPress that was developed before my time, and uses ACF and ACFE very heavily. I've been using it for 8 months without encountering this issue, which started yesterday after the ACF update. As I've said, reverting to the old 6.1.7 PHP file fixes it (although it is not a viable strategy).
I'd be happy to provide you with more info. whatever you ask. Thank you!
If you run var_dump(sanitize_file_name('group_64d64536719c8.json'));
on the server, does that also change it? Just trying to confirm if that's the issue.
It's also possible something could be filtering on that function (using the WordPress filter sanitize_file_name
) too in WordPress changing _
to -
Good catch, it is indeed responsible for the change:
string(24) "group-64d64536719c8.json"
Looking at sanitize_file_name()
, I did a quick check to see if anything in our stack was using sanitize_file_name_chars
but found nothing.
Looking further, I see that our add-on extension is indeed adding a filter to sanitize_file_name
:
public function sanitize_file_name( $input ) {
$path = pathinfo( $input );
$extension = ( isset( $path['extension'] ) && !empty( $path['extension'] ) ) ? $path['extension'] : '';
$file = ( !empty( $extension ) ) ? preg_replace( '/.' . $extension . '$/', '', $input ) : $input;
return sanitize_title( str_replace( '_', '-', $file ) ) . ( ( !empty( $extension ) ) ? '.' . $extension : '' );
}
We'll fix our extensions. Thank you for your prompt and helpful response!
There appears to be a regression that slipped in with 6.2.0 causing JSONs to be saved with dashes instead of underscores, I suspect somewhere in
save_file()
although after line 400 since the newly-addedacf/json/save_file_name
filter reports the correct name.Reverting to the 6.1.7 file fixes the issue and the JSON are correctly saved.