A string of text starting with "http://" turned into a paragraph

[winterstreet]

In either editor, if there's a line of text that starts with ​http:// wordpress will create a new paragraph.

This description box isn't working to show what I mean see this support post.

​http://wordpress.org/support/topic/a-string-of-text-starting-with-http-turned-into-a-paragraph

[esmi]

Confirmed using Twenty Twelve & no active plugins in both Text & Visual editors. The bug appears to be triggered by any text that immediately follows ​http:// where ​http:// is at the start of a new line.

[SergeyBiryukov]

Introduced in [12023].

WP_Embed::autoembed() has a regex to catch any unlinked URLs that are on their own line:
​http://core.trac.wordpress.org/browser/tags/3.5.1/wp-includes/class-wp-embed.php#L237

WP_Embed::autoembed_callback() then adds an empty line after the URL.

[SergeyBiryukov]

#24615 was marked as a duplicate.

[garhdez]

I think that this is not a bug.

Any string (containing allowed chars) can be a correct URL. For example, "​http://a" could be the URL of real server in an intranet, so I think this regex is well written, because matches any string before ​http:// or ​https:// that is not a whitespace.

[Viper007Bond]

It is a bug. :)

The intention of the embed code is to find a URL on its own line. Once found, it tries to embed it and if it is unable to, then it hyperlinks the URL. However the number of line breaks during this whole process should remain the same.

WP_Embed::autoembed_callback() returns new lines before and after the string it returns because those new lines are matched as a part of the search process.

So really the more proper solution is likely to fix the regex to find URLs on their own line but not include the line breaks in the match so that the function that returns the result won't need to include them, potentially including extra line breaks in the process.

[wonderboymusic]

Let's take a look at this while we are in fellowship around oEmbed

[UmeshSingla]

In order to fix this I've added a strpos check for <iframe on returned URL, So if a URL contains an embed iframe, new lines will be added to it, otherwise a normal hyperlink is returned.

It also fixes the url not being converted to a hyperlink.

This part of code seems to be creating the issue, I've removed it as I didn't found any use for it.

$oldval = $this->linkifunknown;
$this->linkifunknown = false;

[UmeshSingla]

Fixes new line being inserted for a url, URL being not converted to Hyperlink

[SergeyBiryukov]

I think $this->linkifunknown should be left as is, it's used in WP_Embed::maybe_make_link()​ (as noted in comment:1:ticket:20315).

[UmeshSingla]

Replying to SergeyBiryukov:

I think $this->linkifunknown should be left as is, it's used in WP_Embed::maybe_make_link()​ (as noted in comment:1:ticket:20315).

For autoembed_callback it is dead code, $this->linkifunknown is set to false before calling shortocode function. As a result if there is a link in content it is never being converted to a link unless it is a youtube, vimeo or other known service link, it is left as it is, which is wrong, as per Once found, it tries to embed it and if it is unable to, then it hyperlinks the URL

After the above patch, things works as they are intended to, i.e. If its a Youtube or some other service link, it is embedded otherwise it is made a hyperlink which is what required here.

[UmeshSingla]

@SergeyBiryukov, your feedback please.

[DrewAPicture]

23776.patch​ still applies. What's left here?

[UmeshSingla]

Replying to DrewAPicture:

23776.patch​ still applies. What's left here?

I find the patch absolutely right, but as per Sergey, "I think $this->linkifunknown should be left as is, it's used in WP_Embed::maybe_make_link()​ (as noted in comment:1:ticket:20315)."

[DrewAPicture]

@SergeyBiryukov: Can you please review what's left here?

[markjaquith]

What is the reasoning behind the iframe check? Couldn't other things be returned than iframes? Not really confident in this, and it's an old issue, so punting for now.

[chipx86]

This is an old issue, but one that I spent a good chunk of the day trying to deal with.

I first noticed this issue when trying to display sample output from a command in a little tutorial I was writing. In one section of the output, there would be a URL displayed on each line. Wordpress was rendering this with a blank line in-between. Inside the <pre> block, this just manifested as a blank line in-between. Outside a <pre>, this manifested as a <p> for each line.

Expected output was:

$ my command
First line.

http://example.com/1/
http://example.com/2/
Last line.

Resulting output with 4.0.1:

$ my command
First line.

http://example.com/1/

http://example.com/2/

Last line.

The current attached patch converts the URLs to links and removes a leading blank line that should have remained. It results in the following (pretend that the brackets are links):

$ my command
First line.
[http://example.com/1/]
[http://example.com/2/]
Last line.

My new patch (attaching in the next update) doesn't add any heuristics like checking for iframes, or removal of linkifunknown, but rather simply captures the whitespace matched in the regex and preserves it in the output. The resulting output matches my expected output in the first example above, and was tested both with and without pre-formatted text.

[chipx86]

Preserves whitespace around URLs in the auto-embed code.

[sgrant]

Here's two tests, one simple with the empty string, and another using the example from @chipx86 . (Thanks!) The second test fails before autoembed-preserve-whitespace.diff is applied, and passes afterwards.

[SergeyBiryukov]

In 31066:

Don't force newlines around URLs in WP_Embed::autoembed().

props chipx86, sgrant.
fixes #23776.