Make WordPress Core

Opened 17 years ago

Closed 10 years ago

Last modified 10 years ago

#2875 closed defect (bug) (fixed)

https enclosures fail on post.

Reported by: nigelkane's profile nigelkane Owned by:
Milestone: 3.7 Priority: normal
Severity: major Version: 2.0.2
Component: Feeds Keywords: has-patch needs-testing
Focuses: Cc:


I was noticeing a problem in that when you post on a standard HTML site, enclosures get added into postmeta on publishing a post. When running off an HTTPS site, this no longer happens.

The reason is the regex only looks for HTTP. Line 1032 of wp-includes/functions.php

  preg_match_all("{\b http : [$any] +? (?= [$punc] * [^$any] | $)}x", $content, $post_links_temp2);

Add the following under this line and it works.

  preg_match_all("{\b https : [$any] +? (?= [$punc] * [^$any] | $)}x", $content, $post_links_temp2);
  foreach($post_links_temp2[0] as $link) {
    $post_links_temp[0][] = $link;

There may be a nicer way to regex that up, but I couldn't add it.

I have raised it as high/major because it is a bit of a hole that I cannot override the functionality of, and I use the RSS feed for podcasting - which WordPress does not support from an HTTPS site.

Attachments (1)

2875.diff (1.2 KB) - added by Nazgul 16 years ago.

Download all attachments as: .zip

Change History (15)

#1 @markjaquith
17 years ago

preg_match_all("{\b https? : [$any] +? (?= [$punc] * [^$any] | $)}x", $content, $post_links_temp2);

In regex, the question mark makes the previous item optional... so https? matches http or https

#2 @nigelkane
17 years ago

Thanks Mark... Regex is one of the last surviving dark arts :)

Having tested this fix a little more its not the only reason why podcasting won't work.

the do_enclose() function does not actually seem to get called when running from an HTTPS site. and even when you hack the enclosure custom tag in the post (with the correct values as well), itunes moans that there was a problem - quite possibly it does not like HTTPS because nothing gets populated in any of the fields.

The feed is identical in XML though.

Thought I had it for a moment there. But at least when you force the do_enclose() call it does populate the headers now :)

#3 @nigelkane
17 years ago

wp_html_headers() does not support ssl either.

at the current line 1073 the 2 lines setting the port should be re-writting:

        $scheme = "";
        if ( $parts['scheme'] == "https" )
                $scheme = "ssl://";
        if ( !isset( $parts['port'] ) ) {
                if($scheme) {
                        $parts['port'] = 443;
                } else {
                        $parts['port'] = 80;

You should not adjust the $host parameter as this is used in the HTML header commands and will break.

You then should add the scheme into the fsockopen command:

        $fp = @fsockopen($scheme.$host, $parts['port'], $err_num, $err_msg, 3);

Still working on why this particular section is not being called.

#4 @Nazgul
17 years ago

  • Keywords needs-patch added
  • Milestone set to 2.1

#5 @matt
17 years ago

  • Milestone changed from 2.1 to 2.2

16 years ago

#6 @Nazgul
16 years ago

  • Keywords has-patch needs-testing added; needs-patch removed
  • Milestone changed from 2.2 to 2.3

Added a patch based on the given code snippets.

I don't have a https site to test this on.

#7 @ryan
16 years ago

  • Milestone changed from 2.3 to 2.4 (next)

#8 @Nazgul
15 years ago

  • Priority changed from high to normal

#9 @jacobsantos
15 years ago

See #4779, which implements this, but isn't used in this area.

#10 @jacobsantos
15 years ago

  • Milestone 2.9 deleted
  • Resolution set to duplicate
  • Status changed from new to closed

When #4779 is fully tested and implemented throughout WordPress it will obsolete this ticket. Closing now as duplicate.

#11 @dllh
11 years ago

  • Cc daryl@… added
  • Resolution duplicate deleted
  • Status changed from closed to reopened

I've just encountered this issue again. The underlying network issues were fixed long long ago in #4479, but it's still the case that do_enclose() won't recognize and do enclosures for files with the https protocol. The little regex tweak proposed in comment 1 should do the trick. Although I suppose it's not optimal for somebody to be serving media via ssl, it's certainly possible (consider the case of somebody using WordPress for an extranet behind ssl.) Any chance of fixing this?

#12 @SergeyBiryukov
11 years ago

  • Component changed from General to Feeds
  • Milestone set to Awaiting Review

#13 @mdawaffe
10 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 24810:

Allow HTTPS URL enclosures.

Props markjaquith with a patch that predates all WordCamps.

Fixes #2875.

#14 @helen
10 years ago

  • Milestone changed from Awaiting Review to 3.7
Note: See TracTickets for help on using tickets.