External images are not filtered out

[kdeldycke]

When image-process encounters non-local images, it try to open them and fail with this message:

$ pelican --verbose ./content
(...)
-> Writing /Users/kde/blog/output/2017/01/meta-package-manager-230/index.html
CRITICAL: [Errno 2] No such file or directory: '/Users/kde/blog/content/comics/universal_install_script.png'

Here I expect the plugin to detect the image resource as external, print a warning and skip the transformation altogether. Is that reasonable?

I'm using the latest version from the master branch.

---

Here is the detailed case, starting with this Markdown:

![XKCD #1654](https://imgs.xkcd.com/comics/universal_install_script.png){: .image-process-article-photo}

which properly renders to:

<img alt="XKCD #1654" class="image-process-article-photo" src="https://imgs.xkcd.com/comics/universal_install_script.png"/>

My pelicanconf.py look like this:

SITEURL = "http://localhost:8000"

PLUGINS = [
    (...)
    "pelican_image_process",
]

IMAGE_PROCESS = {
    "article-photo": {
        "type": "responsive-image",
        "sizes": """
            (min-width: 1200px) 800px,
            (min-width: 992px) 650px,
            (min-width: 768px) 718px,
            100vw
        """,
        "srcset": [
            # All keeps 4:3 aspect ratios.
            ("600w", ["scale_in 600 450 True"]),
            ("800w", ["scale_in 800 600 True"]),
            ("1600w", ["scale_in 1600 1200 True"]),
        ],
        # Default Plumage's central content column is 540px wide, so default to
        # 600w variant.
        "default": "600w",
    },
}
(...)

[kdeldycke]

For the record, I managed to bypass this issue with a hack in my theme, in which I inspect the URL from the src attribute: kdeldycke/plumage@d99098d#diff-73faed5a2803d28b38722b6addaebddb6e3517605ce03deaf65cd312a8f79049R53-R56

It does the job for now. Maybe we can apply that fix into image-process directly. The thing is, I looked at the code to try to add that fix but I felt like the plugin is in needs of a little refactor... 😔

[MinchinWeb]

@kdeldycke Was this solved by PR #51, included in the v2.1.3 release?

[patrickfournier]

Fixed by #51