https enclosures fail on post.

[nigelkane]

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.

[markjaquith]

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

[nigelkane]

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 :)

[nigelkane]

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.

[Nazgul]

Added a patch based on the given code snippets.

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

[jacobsantos]

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

[jacobsantos]

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

[dllh]

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?

[mdawaffe]

In 24810:

Allow HTTPS URL enclosures.

Props markjaquith with a patch that predates all WordCamps.

Fixes #2875.