Skip to content

Content renders all on one line when calling file_get_contents before use #3674

Closed
#3677
Closed
Content renders all on one line when calling file_get_contents before use#3674
#3677
Milestone
3.1.4

Description

@bsweeney
bsweeney
opened on Oct 21, 2025

I'm not sure if this is of any interest, but I just came across this problem, and since 3.1.1 it can be triggered with just:

<div style="max-width: 100px;">
	test
	<br>
	test2
	<br>
	test3
</div>

All 3 "tests" float on top of each other

The proposed "work around" in #3416 (comment) doesn't have any effect

It seems this is somehow related to calling file_get_contents on "anything" before producing the PDF
I'm not sure why it's relevant but on 3.1.3 this code works:

$html = <<<PDF
<div style="max-width: 100px;">
	test
	<br>
	test2
	<br>
	test3
</div>
PDF;

$dompdf = new Dompdf\Dompdf();
$dompdf->loadHtml($html);
$dompdf->render();
$pdf = $dompdf->output();

header("Content-type: application/pdf");
echo $pdf;

But this doesn't

file_get_contents('https://one.one.one.one');
$html = <<<PDF
<div style="max-width: 100px;">
	test
	<br>
	test2
	<br>
	test3
</div>
PDF;

$dompdf = new Dompdf\Dompdf();
$dompdf->loadHtml($html);
$dompdf->render();
$pdf = $dompdf->output();

header("Content-type: application/pdf");
echo $pdf;

I chose one.one.one.one as the "target" because they probably won't mind :o , but any target seems to trigger the problem

The machine is running:
PHP Version 8.4.12
Debian 12

3.1.3_works.pdf

3.1.3_fails.pdf

Originally posted by @noir04 in #3416

Activity

  1. bsweeney commented on Oct 21, 2025

    @bsweeney
    bsweeney
    on Oct 21, 2025
    MemberAuthor

    @noir can you try enabling additional debug messaging to see if anything useful is logged while rendering?

  2. noir04 commented on Oct 21, 2025

    @noir04
    noir04
    on Oct 21, 2025

    @bsweeney - First, sorry that I tainted the other issue, I thought they were related.

    With debugging enabled and using file_get_contents()

    Unable to load css file file:///app/vendor/dompdf/dompdf/lib/res/html.css
<b>Dompdf Warnings</b><br><pre>Unable to load css file file:///app/vendor/dompdf/dompdf/lib/res/html.css
selectFont: selecting - /app/vendor/dompdf/dompdf/lib/fonts/Times-Roman - ,
openFont: /app/vendor/dompdf/dompdf/lib/fonts/Times-Roman - Times-Roman
metrics: Times-Roman.afm, cache: Times-Roman.afm.json
openFont: build php file from /app/vendor/dompdf/dompdf/lib/fonts/Times-Roman.afm

    When not using file_get_contents() there aren't any errors/warnings

    I created a quick Docker that shows the problem, if that can help in any way :)

    docker.zip

  3. bsweeney commented on Oct 21, 2025

    @bsweeney
    bsweeney
    on Oct 21, 2025
    MemberAuthor

    First, sorry that I tainted the other issue, I thought they were related.

    No worries!

    Unable to load css file file:///app/vendor/dompdf/dompdf/lib/res/html.css

    That would be problematic. This CSS defines the base styling and is pretty much a requirement. Does it give the same warning when not using file_get_contents?

  4. noir04 commented on Oct 21, 2025

    @noir04
    noir04
    on Oct 21, 2025

    I get no errors/warnings when NOT using file_get_contents() and the PDF renders as it should

    The problem isn't in 3.1.0 but it starts in 3.1.1

    I found out that if I call http_clear_last_response_headers(); just before calling $dompdf->render();, then the problem goes away

    I think it's related to this change: 794ec85#diff-951296e7f45f3adb0f3e0975964c423ed4dcd74743499d1a3159ede66024d4cdR1072

  5. jannes-io commented on Oct 21, 2025

    @jannes-io
    jannes-io
    on Oct 21, 2025

    Same issue when using file_get_contents @noir04 's workaround does work for us. No issue on 3.1.0, issue starts in 3.1.1.

    <?php

use Dompdf\Dompdf;

require_once dirname(__DIR__) . '/vendor/autoload.php';

file_get_contents("https://google.com");

$dompdf = new Dompdf();
$dompdf->loadHtml('<html>
    <body>
        <div style="position:fixed"></div>
    </body>
</html>');
$dompdf->render();

echo 'no error';

    EDIT: adding our error:

    Fatal error: Uncaught Error: Call to a member function get_content_box() on null in /Users/jannes/projects/dompdf-repro/vendor/dompdf/dompdf/src/FrameReflower/Block.php:96
Stack trace:
#0 /Users/jannes/projects/dompdf-repro/vendor/dompdf/dompdf/src/FrameReflower/Block.php(236): Dompdf\FrameReflower\Block->_calculate_width('auto')
#1 /Users/jannes/projects/dompdf-repro/vendor/dompdf/dompdf/src/FrameReflower/Block.php(811): Dompdf\FrameReflower\Block->_calculate_restricted_width()
#2 /Users/jannes/projects/dompdf-repro/vendor/dompdf/dompdf/src/FrameDecorator/AbstractFrameDecorator.php(915): Dompdf\FrameReflower\Block->reflow(NULL)
#3 /Users/jannes/projects/dompdf-repro/vendor/dompdf/dompdf/src/FrameReflower/Inline.php(161): Dompdf\FrameDecorator\AbstractFrameDecorator->reflow(NULL)
#4 /Users/jannes/projects/dompdf-repro/vendor/dompdf/dompdf/src/FrameDecorator/AbstractFrameDecorator.php(915): Dompdf\FrameReflower\Inline->reflow(NULL)
#5 /Users/jannes/projects/dompdf-repro/vendor/dompdf/dompdf/src/FrameReflower/Page.php(141): Dompdf\FrameDecorator\AbstractFrameDecorator->reflow()
#6 /Users/jannes/projects/dompdf-repro/vendor/dompdf/dompdf/src/FrameDecorator/AbstractFrameDecorator.php(915): Dompdf\FrameReflower\Page->reflow(NULL)
#7 /Users/jannes/projects/dompdf-repro/vendor/dompdf/dompdf/src/Dompdf.php(815): Dompdf\FrameDecorator\AbstractFrameDecorator->reflow()
#8 /Users/jannes/projects/dompdf-repro/public/index.php(15): Dompdf\Dompdf->render()
#9 {main} thrown in /Users/jannes/projects/dompdf-repro/vendor/dompdf/dompdf/src/FrameReflower/Block.php on line 96

  6. bsweeney commented on Oct 21, 2025

    @bsweeney
    bsweeney
    on Oct 21, 2025
    MemberAuthor

    Thanks for the pointer. Which version of PHP are you using? I'll need to check why that change to the content retrieval logic is problematic.

  7. bsweeney
    added this to the 3.1.4 milestone on Oct 21, 2025

  8. noir04 commented on Oct 21, 2025

    @noir04
    noir04
    on Oct 21, 2025

    I'm using PHP Version 8.4.12

  9. bsweeney commented on Oct 21, 2025

    @bsweeney
    bsweeney
    on Oct 21, 2025
    MemberAuthor

    Thanks, I'll do some more testing to confirm whether or not the compatibility logic is the cause.

  10. bsweeney
    added a commit that references this issue on Oct 25, 2025

    Reset response headers before calling file_get_contents

    abcd8c5
  11. bsweeney
    linked a pull request that will close this issueReset response headers before calling file_get_contents #3677on Oct 25, 2025
  12. bsweeney
    added a commit that references this issue on Oct 26, 2025

    Reset response headers before calling file_get_contents

    e4e62f5

  13. bsweeney commented on Oct 27, 2025

    @bsweeney
    bsweeney
    on Oct 27, 2025
    MemberAuthor

    Thank you for the information you provided. It gave me the guidance I needed to find the cause.

    For stylesheets HTTP headers are parsed to look for a valid mime type. In PHP 8.4 or greater we weren't clearing previous headers meaning that a remote file retrieved before render would trigger header inspection on the base stylesheet. The remote file having a non-CSS mime type would cause Dompdf to drop the stylesheet. As a result, Dompdf did not have the core styling needed to render a document correctly.

  14. bsweeney
    closed this as completedin 43f0a8eon Oct 28, 2025
  15. pull
    added a commit that references this issue on Oct 28, 2025

    Reset response headers before calling file_get_contents

    43f0a8e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions
      Sponsor
      SponsoredKunjungi sekarang
      Promo