-
Notifications
You must be signed in to change notification settings - Fork 842
CDN: gracefully handle a non-string #44874
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
Conversation
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Boost plugin: No scheduled milestone found for this plugin. If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
Code Coverage SummaryCoverage changed in 1 file.
|
Co-authored-by: Weston Ruter <[email protected]>
projects/plugins/boost/changelog/update-jetpack-no-null-content-cdn-HOG-301
Outdated
Show resolved
Hide resolved
tbradsha
left a comment
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.
For malformed content, I think we should return an empty string, as that's the proper signature of functions that use the filter. Otherwise we're just passing along the wrong data type to the next function that hooks into the filter.
|
@tbradsha like this, for example? /**
* Filters foo.
*
* @param string|mixed $foo Foo.
* @return string Foo.
*/
function filter_foo( $foo, int $post_id ): string {
if ( ! is_string( $foo ) ) {
// Because plugins do bad things.
$foo = '';
}
// Filtering logic goes here.
return $foo;
}
add_filter( 'foo', 'filter_foo', 10, 2 ); |
Yep, precisely. Since the
|
|
I was torn between passing through malformed vs returning an empty string instead. Hearing y'all, I'll update the code and tests to return |
tbradsha
left a comment
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.
Looks good to me!
Fixes HOG-301
The WP_HTML_Tag_Processor will construct with any value passed to it, but
get_updated_htmlis type-restricted to only returning a string. This will lead to a runtime fatal.While this is something Core can (should?) address, we can save a lot of work by just returning early a value that we won't be able to do anything with.
The Core issue is proposed and patched via https://core.trac.wordpress.org/ticket/63854
Proposed changes:
filter_the_content, early return the passed value.Other information:
Jetpack product discussion
.
Does this pull request change what data or activity we track or use?
No.
Testing instructions:
Image_CDN::filter_the_content(null);before and after this patch.null.