When uploading and inserting an image trough the WYSIWYG plugin a relative path should be used for the image source (src)

#2076847: FilterHtmlImageSecure incorrectly flags images coming from site URLs with ports in them as insecure got committed in the mean time — yay :)

Changes:

• Use getHttpHost(), just like in #2076847: FilterHtmlImageSecure incorrectly flags images coming from site URLs with ports in them as insecure.
• Made the code a bit more like other Drupal core code.
• Updated the docs in the one other place in Drupal core where the exact same logic is already being used.

Updated issue summary.

Would it make sense to have a function for this since its the same logic as in filter module?

#5: That might make sense, yes. What about file_transform_url_relative()? Hopefully you can think of something better.

I don't think this would be in file module would it. That name sounds confusing for that. It would be in filter module, no?

#7: But wouldn't it be a lot stranger to put file handling functionality in filter.module? Despite filter.module being the only one in need of this functionality in core, I can imagine contrib modules wanting to use this too. And it's clearly within the responsibilities of the file system, in my opinion.

Yeah I don't feel strongly about it, but it looks to me like its filtering the URL for better display, may also apply to non-file module handled files (eg. theme). Anyway, its fine either way, there is no really clear place for it to go IMHO.

So instead of duplicating the same URL manipulation in another location in Drupal core, this issue now proposes a minor API addition. Test coverage added.

Looks good to me :)

I can't reproduce this locally, so adding debug output to figure out why testbot is failing.

Adding even more debug output.

Sigh… I accidentally created an interdiff instead of a patch. Let's try again.

Okay so the reason testbot is failing is that getHttpHost() returns 'drupaltestbot1838:'. That is in fact… a value that contradicts the contract of the function. WTF.

    /**
     * Returns the HTTP host being requested.
     *
     * The port name will be appended to the host if it's non-standard.
     *
     * @return string
     *
     * @api
     */
    public function getHttpHost()
    {
        $scheme = $this->getScheme();
        $port   = $this->getPort();

        if (('http' == $scheme && $port == 80) || ('https' == $scheme && $port == 443)) {
            return $this->getHost();
        }

        return $this->getHost().':'.$port;
    }

How is this possible? The protocol must be 'http' and the port must be 80.

Adding two more debug() statements, to output the scheme and port.

Sigh, for some reason that patch was in fact the #18 patch. The interdiff was correct though. This was the intended patch…

So apparently on testbot, Request::getPort() === NULL… hence the test failures!

Hence the only thing I can do is work around that problem. Which is easy enough, but comes with a bit more code than the original.

Still looks good, testbot specialties aside :)

Committed and pushed to 8.x, but let's get an upstream issue filed about getPort() because that is wacktastical.

Alright, upstream issue filed: https://github.com/symfony/symfony/issues/9604

Note this had some consequences for retrieving entities via REST too: #2630076: Inline images: how to calculate the absolute file URL.