laravel-dompdf: "No block-level parent found. Not good." error when using

Hi,

I have run into a very strange issue that recently has caused my dompdf generation to fail with No block-level parent found. Not good..

After debugging and consulting the other issues regarding this error on this issue tracker, I have figured out, that none of the causes mentioned (like using CSS or line breaks) are at fault in my setup, but rather the presence of a <head> section in my HTML.

It seems to me that this issue is somehow connected to my personal development environment, since it works fine in production or even on my coworker’s machine. I have created the minimal breaking/working cases for reference: https://github.com/felixkiss/laravel-dompdf-issue/commit/38cf4a10f827c614a2ddbf8c90575d52faa1a9a9

screen shot 2017-09-21 at 19 50 11

My working environment: macOS 10.12.6 PHP 7.1.8 barryvdh/laravel-dompdf v0.8.1

Any help/hints on resolving would be much appreciated. It worked fine for the past 2 years and I don’t know what to do next to resolve this (other than not using <head> which is not really an option since I rely on CSS styles, etc. that are defined there)

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 23 (10 by maintainers)

Most upvoted comments

This is so strange. I was working with this perfectly yesterday, and now today it’s not working.

Removing whitespace between the following elements solves the problem for me:

<html><head>
</head><body>
</body></html>

Whitespace anywhere else in the file seems to be perfectly fine.

+57

benabbottnz on Sep 26, 2017

Change lines 122 to 125 in /vendor/barryvdh/laravel-dompdf/src/PDF.php From

    public function loadView($view, $data = array(), $mergeData = array(), $encoding = null){
        $html = $this->view->make($view, $data, $mergeData)->render();
        return $this->loadHTML($html, $encoding);
    }

    public function loadView($view, $data = array(), $mergeData = array(), $encoding = null){
        $html = $this->view->make($view, $data, $mergeData)->render();
        $html = preg_replace('/>\s+</', '><', $html);
        return $this->loadHTML($html, $encoding);
    }

+26

diegoflorez on Sep 29, 2017

@kinnedev For reference, here is what I ended up doing:

protected function makePdf()
{
    $html = View::make('path.to.pdf_view', ['data' => $data])->render();
    $html = preg_replace('/>\s+</', '><', $html);
    return PDF::loadHtml($html);
}

protected function savePdf()
{
    $pdf = $this->makePdf();
    Storage::disk('s3')->put('somedirectory/filename.pdf', $pdf->output());
}

+26

pactode on Sep 26, 2017

@burlap Yes, it must have been the case.

I added it to the config as you suggested and it did work.

One thing I noticed is that the DOMPDF_ENABLE_HTML5PARSER key in the config should be DOMPDF_ENABLE_HTML5_PARSER. That’s why it doesn’t get set in the first place. I made a pull request for this.

+11

pactode on Sep 26, 2017

I don’t know why set_option doesn’t work, it’s possible you are setting it after the html is already parsed.

I’ve just changed the options in dompdf.php config file, as in #384 (in the pull request I’ve left the parser disabled, but obviously I have it enabled in my application), so what I have is this:

in config/dompdf.php

"enable_html5_parser" => true,

to generate PDF download

$pdf = PDF::loadView('some.template', ['options' => $options]);
return $pdf->download('document.pdf');

burlap on Sep 26, 2017

Had the same issue, for me it was caused by the html tag not being detected as a block-level parent. Had to add the following CSS to fix it: html, body { display: block; }

victor-priceputu on Oct 22, 2018

When this bug hit me, I was sure I had html5parser enabled until I checked it wasn’t. You can make sure it works with

$pdf->getDomPDF()->get_option('enable_html5_parser');

burlap on Sep 26, 2017

Try enabling html5 parser.

See this pull request https://github.com/barryvdh/laravel-dompdf/pull/384

And this issue in dompdf https://github.com/dompdf/dompdf/issues/1494

burlap on Sep 26, 2017

For my case, it was due to the use of

      body {
        display: inline-block;
      }

The works:

      body {
        display: block;
      }

NicksonYap on Jul 3, 2019

@burlap I just tried checking as you mentioned. It surprisedly returned false even though the variable inside config/dompdf.php has been set to true.

However, I manually tried to overwriting the option like this:

$pdf->getDomPDF()->set_option('enable_html5_parser', true);

It did not work either… (the option was true, when checking this time)

Do you have some example code from your implementation?

pactode on Sep 26, 2017

I just encountered this error as well. It has been working before, but now the tests are not passing. I made several changes to my project, but will try to clone an older version of the repo to test if it could have anything to do with upgrading to L5.5.

I will update this issue, if I figure out a solution.

UPDATE I just tried running my application in another environment on another mac, then it worked fine. It seems like it is due to the local environment (in my case), so I will try to reset my mac with a fresh environment.

pactode on Sep 25, 2017