Ticket #2875 (closed defect: duplicate)

Opened 2 years ago

Last modified 4 months ago

https enclosures fail on post.

Reported by: nigelkane Assigned to: anonymous
Priority: normal Milestone:
Component: General Version: 2.0.2
Severity: major Keywords: has-patch needs-testing
Cc:

Description

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

2875.diff (1.2 kB) - added by Nazgul on 03/31/07 08:36:34.

Change History

06/29/06 14:19:06 changed by 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

06/29/06 18:35:45 changed by 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 :)

06/30/06 07:20:14 changed by 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.

10/06/06 02:14:36 changed by Nazgul

  • keywords set to needs-patch.
  • milestone set to 2.1.

11/29/06 23:50:45 changed by matt

  • milestone changed from 2.1 to 2.2.

03/31/07 08:36:34 changed by Nazgul

  • attachment 2875.diff added.

03/31/07 08:38:41 changed by Nazgul

  • keywords changed from needs-patch to has-patch needs-testing.
  • 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.

09/12/07 17:46:13 changed by ryan

  • milestone changed from 2.3 to 2.4 (next).

01/31/08 23:08:09 changed by Nazgul

  • priority changed from high to normal.

08/09/08 01:02:44 changed by jacobsantos

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

08/09/08 01:04:24 changed by jacobsantos

  • status changed from new to closed.
  • resolution set to duplicate.
  • milestone deleted.

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