file_get_contents not enabled on some hosters

[m4ucoder]

My hoster disables file_get_contents() into php configuration. ("allow_url_open" directive setted to false).

This problem is current (see https://stackoverflow.com/search?q=allow_url_open+file_get_contents or )

I suggest to have replace file_get_contents() by a "custom" function or a static method. The code will check if file_get_contents is enabled, and if not, use another way to load contents.

In my case, I have replaced all file_get_contents from MPDF classes with a custom function, and I use "curl" instead of "file_get_contents()".

Hope this helps

[finwe]

There are parts of the code which can use curl to get remote content. Please elaborate which parts of the code are using plain file_get_contents to fetch remote content.

[prollandoc]

To follow-up on #1399 discussion, here are the parts that are currently troubling us:

Here, a plain file_get_contents is made to gather the content, and as allow_url_fopen is activated, fopen succeeds when reaching a file remotely. But file_get_contents fails with a 400, probably due to the lack of context as mentioned here https://stackoverflow.com/questions/43750021/php-file-get-contents-returns-with-a-400-error (not my SO question) https://github.com/mpdf/mpdf/blob/development/src/Image/ImageProcessor.php#L226

As we have quite a large codebase, I'm not sure disabling allow_url_fopen would be an immediate option on our side.

But for some reason, sometimes, this line is reached too (provoking the same error). I can only assume that $this->mpdf->basepathIsLocal is resolved as true even if we're fetching remote content 🤔 https://github.com/mpdf/mpdf/blob/development/src/Image/ImageProcessor.php#L219

As I said, our PDFs always end up being created with all the images as there's curl as a fallback below, but in the mean time, we're encountering a lot of warnings.

That's why I ended up opening this PR, to provide a custom content loader, that would work either locally or remotely, just by providing file_get_contents with the accurate context (like user-agent) so that our CDN doesn't respond with a 400.

Hope that's clear, if not don't hesitate to tell me :)

[prollandoc]

Hi again @finwe, to follow-up on this, I just patched the two lines from above in our version of mpdf with the suggestion from StackOverflow, and it works like a charm.

Maybe a simpler configuration like fileGetContentsContext or something like that could solve those kinds of issues (but not @m4ucoder's one)

[sergiokessler]

I'm occasionally getting:

Warning: file_get_contents(): SSL: Success in /var/www/html/vendor/mpdf/mpdf/src/Image/ImageProcessor.php on line 230

Warning: file_get_contents(): Failed to enable crypto in /var/www/html/vendor/mpdf/mpdf/src/Image/ImageProcessor.php on line 230

[sergiokessler]

maybe add a setHttpContext() method ?

$options = array(
    "ssl"=>array(
        "verify_peer"=> false,
        "verify_peer_name"=> false,
    ),
);
$http_context = stream_context_create($options);
$pdf->setHttpContext($http_context);