[wp-trac] [WordPress Trac] #32112: wp_get_attachment_url returns https when it should not

[WordPress Trac]

#32112: wp_get_attachment_url returns https when it should not
--------------------------+---------------------------
 Reporter:  zabatonni     |       Owner:  boonebgorges
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  4.2.1
Component:  Media         |     Version:  4.2
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+---------------------------
Changes (by boonebgorges):

 * keywords:  close =>
 * owner:   => boonebgorges
 * status:  new => assigned
 * milestone:  Awaiting Review => 4.2.1


Comment:

 You can restore `wp_get_attachment_url()` to its pre-4.2 behavior like
 this:

 {{{
 function wp32112_force_attachment_urls_to_non_https( $url ) {
     return set_url_scheme( $url, 'http' );
 }
 add_filter( 'wp_get_attachment_url',
 'wp32112_force_attachment_urls_to_non_https' );
 }}}

 A more targeted fix is to replace `src` URLs in post content only (which
 is the place where the https is problematic):

 {{{
 function wp32112_force_attachment_urls_to_non_https_in_post_content(
 $content ) {
     if ( ! is_ssl() ) {
         $uploads = wp_upload_dir();
         $base = $uploads['basedir'];
         $base_ssl = set_url_scheme( $base, 'https' );

         $content = str_replace( 'src="' . $base_ssl, 'src="' . $base,
 $content );
     }
     return $content;
 }
 add_filter( 'the_content',
 'wp32112_force_attachment_urls_to_non_https_in_post_content' );
 }}}

 The fixes in `wp_get_attachment_url()` are appropriate for the vast
 majority of cases, and should stay. But the issues of HTTP-only caching
 and self-signed certificates are important enough that we should do
 something about it. Since the problem is with post content that is
 generated in HTTPS wp-admin but then displayed on a front end that is non-
 HTTPS, I think a proper fix is to modify the Add Media process so that the
 'src' attribute of `<img>` tags inserted into the editor always respects
 the scheme of `wp_upload_dir()`. The downside of this is that it'll result
 in mixed-content warnings on SSL-optional front-ends, but this was also
 the case before 4.2, and can be fixed with a filter (roughly the opposite
 of the 'the_content' filter I posted above). I'll work on a patch.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32112#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform