Domain is not changed for added fonts

[srueegger]

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

The command “wp search-replace” does not work as expected. With WordPress 6.5 the Gutenberg Full-Site-Editor got the possibility to add fonts (as direct upload or as direct download from Google Fonts).

If you now change the URL of a WordPress installation with “wp search-replace”, the URL of your own fonts is not adjusted - which means that the font files cannot be loaded.

Describe how other contributors can replicate this bug

• install a WordPress Site on Domain A
• Install any font from Google Fonts via the full-site editor in the standard design (twentytwentyfour) or upload any font.
• Use this installed Font as Default
• Copy the Site to Domain B
• use "wp search-replace" to chnage the URL
• open the Site on Domain B
• In the browser source code you will then see that the domain of the fonts still refers to domain A

Describe what you would expect as the correct outcome

The domain of the fonts should also be changed via “wp search-replace”.

Let us know what environment you are running this on

OS:	Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:19:05 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T8112 arm64
Shell:	/bin/zsh
PHP binary:	/Applications/MAMP/bin/php/php8.1.13/bin/php
PHP version:	8.1.13
php.ini used:	/Applications/MAMP/bin/php/php8.1.13/conf/php.ini
MySQL binary:	/Applications/MAMP/Library/bin//mysql
MySQL version:	mysql  Ver 14.14 Distrib 5.7.39, for osx11.0 (x86_64) using  EditLine wrapper
SQL modes:	
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/Users/srueegger/Sites/compresso.ch
WP-CLI packages dir:	
WP-CLI cache dir:	/Users/srueegger/.wp-cli/cache
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	2.10.0

[swissspidy]

What's the exact command that you are using? Have you tried the --precise flag?

[swissspidy]

FWIW I cannot reproduce this.

I just did wp search-replace wordpress-cevelop wordpress-develop wp_post* on my local wordpress-develop.local site and the font URLs were replaced as expected in the source code.

[danielbachhuber]

My guess is that the URLs are JSON encoded (related #186)

[srueegger]

So the error is definitely reproducible for me. I have installed a standard Wordpress under the domain “domaina.dvl.to”. And uploaded the following fonts in the fullsite editor.

Then i set this font as the default for headings and texts.

Fonts:
testfonts.zip

This works fine:

Then I simply copied the DocumentRoot and database and let the domain “domainb.dvl.to” point to it.

Then I use “wp search-replace” to change the domains, the process is also executed:

When opening the domain, you can see that the fonts I have uploaded do not work. It is interesting to note that the fonts that are predefined in the WordPress theme “twentytwentyfour” seem to work perfectly.

Browser Console:

Source Code with wrong Domain:

[ernilambar]

I can reproduce this issue and it is indeed related to encoded value. When fonts are uploaded, entry is created in posts table and post_content looks like this:

{"src":"http:\/\/foo.local\/wp-content\/uploads\/fonts\/SZc83FzrJKuqFbwMKk6EtUf57DtOmCc.woff2","fontWeight":"400","fontStyle":"normal","fontFamily":"\"Alex Brush\"","preview":"https:\/\/s.w.org\/images\/fonts\/17.7\/previews\/alex-brush\/alex-brush-400-normal.svg"}

When I try to generate sql after replacing the domain, eg:

wp search-replace 'http://foo.local' 'http://bar.local' --export=sample.sql

Then value shown above is not updated to new domain.

[pwtyler]

@schlessera and I looked at this a bit at WCUS Contributor day this week, I spent some time on a potential search-replace implementation, switched gears to see if I could take on something more general/thorough addressing #186, even taking that over to the db command instead— but struggled with the scope of that.

Stepping back, though, I'm back to considering this as a gap in search-replace behavior we should close— I'd expect search-replace to thoroughly address all instances of a string I ask it to replace, not have to switch to a second command to get to nested JSON.

We might introduce this with an opt-in flag (i.e. something like --recurse-json) for now if we want to preserve current behavior, but should consider whether to flip that on by default in the future.

I've got a partial attempt I shelved a couple months ago we picked up again this week (89d66d6) and a breaking test (e1f50e3) I'll try to iterate on in a draft PR sooner rather than later.