Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No block-level parent found. Not good. #902

Closed
Steinweber opened this issue Feb 14, 2015 · 68 comments

Comments

@Steinweber
Copy link

commented Feb 14, 2015

Fatal error: Uncaught exception 'DOMPDF_Exception' with message 'No block-level parent found. Not good.' in /var/www/web50/htdocs/system/library/dompdf/include/inline_positioner.cls.php:37

All installaled
PHP 5.0+
MBString extension
DOM extension
GD extension

No Images, just external css/js

@bsweeney

This comment has been minimized.

Copy link
Member

commented Feb 15, 2015

Check your PHP error log. Typically this error is the result of a null value being parsed, which probably means your document content was lost during initial processing.

@Steinweber

This comment has been minimized.

Copy link
Author

commented Feb 17, 2015

new install of dompdf resolved the problem

@Steinweber Steinweber closed this Feb 17, 2015
@VerzatileTom

This comment has been minimized.

Copy link

commented Jun 11, 2015

Hi, dompdf is working on my localhost but im getting this error on live server. what could be the solution for this?

@bsweeney

This comment has been minimized.

Copy link
Member

commented Jun 11, 2015

You should check your inputs to make sure the content variable (if using $dompdf->load_html()) isn't being nulled out. Also look in your PHP logs for any errors. Also, perhaps you're missing a PHP extension or an external PHP library (e.g. the HTML 5 parser) on the server?

@tomvo

This comment has been minimized.

Copy link

commented Jun 18, 2015

I had this happen when I tried to call loadHTML() twice on the same object.

@VerzatileTom

This comment has been minimized.

Copy link

commented Jun 30, 2015

i'm using $dompdf->loadView()

@bsweeney

This comment has been minimized.

Copy link
Member

commented Jun 30, 2015

$dompdf->loadView()? Are you using dompdf with another library? That method isn't part of dompdf.

@VerzatileTom

This comment has been minimized.

Copy link

commented Jun 30, 2015

oh silly me! im so sorry, I thought its the same. Sorry for bothering you. flies away

@bsweeney

This comment has been minimized.

Copy link
Member

commented Jun 30, 2015

Ha ha ... we all do it (you will not look at my recent github activity). The error is from dompdf, but you might have better luck with the other library. If that doesn't help come on back over and we can hash it out in the support form.

@themao

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2016

I'm doubling @tomvo, I also receive this error when using loadHtml() twice on the same object. I need to generate several pdf files from a list of html templates, so there's no way to avoid using this method twice.

Is there anything that has to be called before loading new html? It looks like it creates new DOMDocument every time, but still it might have some leftovers from the previous 'generations', am I right?

@themao

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2016

For googlers like me, it refers to this bug #1056

@bsweeney

This comment has been minimized.

Copy link
Member

commented Mar 17, 2016

I haven't yet spent much time trying to figure out exactly what would need to be changed to support this. I thought maybe the canvas and frame tree would need to be reset. But the canvas is currently set at render time and the frame tree when a document is loaded. So...

You should be able to unset($dompdf) to clear out any objects that may be causing conflicts.

@themao

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2016

Yes, that's how I'm handling it now. I tried debugging a little bit, but couldn't yet find more that you've just said - everything seems to be set at render time.

@aquaticpond

This comment has been minimized.

Copy link

commented Jun 8, 2016

I am seeing this error as well in my vagrant and my production server. I have the extensions and it throws whether or not html5 parser option is enabled. Only thing I can think is I'm using PHP7?

// error

Notice: Trying to get property of non-object in /var/www/lib/core/Dompdf/Dompdf.php on line 744
Fatal error: Uncaught Dompdf\Exception: No block-level parent found. Not good. in /var/www/lib/core/Dompdf/Positioner/Inline.php:48
Stack trace:
#0 /var/www/lib/core/Dompdf/FrameDecorator/AbstractFrameDecorator.php(788): Dompdf\Positioner\Inline->position()
#1 /var/www/lib/core/Dompdf/FrameReflower/Inline.php(46): Dompdf\FrameDecorator\AbstractFrameDecorator->position()
#2 /var/www/lib/core/Dompdf/FrameDecorator/AbstractFrameDecorator.php(801): Dompdf\FrameReflower\Inline->reflow(NULL)
#3 /var/www/lib/core/Dompdf/FrameReflower/Page.php(133): Dompdf\FrameDecorator\AbstractFrameDecorator->reflow()
#4 /var/www/lib/core/Dompdf/FrameDecorator/AbstractFrameDecorator.php(801): Dompdf\FrameReflower\Page->reflow(NULL)
#5 /var/www/lib/core/Dompdf/Dompdf.php(834): Dompdf\FrameDecorator\AbstractFrameDecorator->reflow()
#6 /var/www/public_html/test-pdf.php(17): Dompdf\Dompdf->render()
#7 {main} thrown in /var/www/lib/core/Dompdf/Positioner/Inline.php on line 48

// code

$dompdf = new Dompdf(['isHtml5ParserEnabled' => true]);
$dompdf->setPaper('A4', 'landscape');
$dompdf->loadHtml("<strong>yer a pdf harry!</strong>");
$dompdf->render();
@bsweeney

This comment has been minimized.

Copy link
Member

commented Jun 8, 2016

@aquaticpond using the 0.7.0 final release? Do you get anything back if you call $dompdf->output_html(); instead of render? What if you disable the HTML5 parser?

@aquaticpond

This comment has been minimized.

Copy link

commented Jun 9, 2016

Checked out from master. output_html() returns the same string input to load_html(). Toggling isHtml5ParserEnabled yields no difference. Checkout from v0.7.0 yields no difference.

@bsweeney

This comment has been minimized.

Copy link
Member

commented Jun 9, 2016

Typically this error is thrown when the variable containing the HTML contents is null. There have been issues in the past where a bug in the HTML processing would result in the HTML content being nulled before by dompdf, but I believe those have been cleared up with the latest release.

Do you see any notices or warnings thrown by PHP besides the initial one.

@aquaticpond

This comment has been minimized.

Copy link

commented Jun 9, 2016

No sir, what you see is all I have. I also tried wrapping in a DIV and providing a full HTML5 document.

@aquaticpond

This comment has been minimized.

Copy link

commented Jun 9, 2016

$dompdf->loadHtml("<div>herp</div><div>derp</div>");

Uncommented line 800 of AbstractFrameDecorator and got:

html:

Id: 0
Class: Dompdf\Frame
Decorator: Dompdf\FrameDecorator\Page
Position:
Array
(
    [x] => 
    [y] => 
    [0] => 
    [1] => 
)
Containing block:
Array
(
    [x] => 0
    [y] => 0
    [w] => 841.89
    [h] => 595.28
    [0] => 0
    [1] => 0
    [2] => 841.89
    [3] => 595.28
)
Margin width:
auto
Margin height:
auto
Style:
Array
(
    [parent_font_size] => 12
    [font_size] => 12
    [width] => auto
    [margin_left] => 0
    [margin_right] => 0
    [border_left_width] => medium
    [border_left_style] => none
    [border_right_width] => medium
    [border_right_style] => none
    [padding_left] => 0
    [padding_right] => 0
    [height] => auto
    [margin_top] => 0
    [margin_bottom] => 0
    [border_top_width] => medium
    [border_top_style] => none
    [border_bottom_width] => medium
    [border_bottom_style] => none
    [padding_top] => 0
    [padding_bottom] => 0
)
body:
Id: 1
Class: Dompdf\Frame
Parent:html (0000000032258bd2000000002aa63c94) 
Decorator: Dompdf\FrameDecorator\Inline
Position:
Array
(
    [x] => 
    [y] => 
    [0] => 
    [1] => 
)
Containing block:
Array
(
    [x] => 0
    [y] => 0
    [w] => 841.89
    [h] => 595.28
    [0] => 0
    [1] => 0
    [2] => 841.89
    [3] => 595.28
)
Margin width:
auto
Margin height:
auto
Style:
Array
(
    [parent_font_size] => 12
    [font_size] => 12
    [float] => none
    [position] => static
    [display] => inline
    [width] => auto
    [margin_left] => 0
    [margin_right] => 0
    [border_left_width] => medium
    [border_left_style] => none
    [border_right_width] => medium
    [border_right_style] => none
    [padding_left] => 0
    [padding_right] => 0
    [height] => auto
    [margin_top] => 0
    [margin_bottom] => 0
    [border_top_width] => medium
    [border_top_style] => none
    [border_bottom_width] => medium
    [border_bottom_style] => none
    [padding_top] => 0
    [padding_bottom] => 0
)
@bsweeney

This comment has been minimized.

Copy link
Member

commented Jun 13, 2016

Certainly looks to be that there was not content. What OS are you running on? Version of PHP?

@aquaticpond

This comment has been minimized.

Copy link

commented Jun 13, 2016

PHP7, tried on Ubuntu 14.04 and CentOS 6.7.

DOM version: 20031129
libxml version: 2.9.1
mbstring engine: libmbfl
libmbfl version: 1.3.2

mbstring settings all at default

@marcleimvs

This comment has been minimized.

Copy link

commented Oct 30, 2016

I use Dompdf within Joomla projects and I've changed Dompdf directories to suite my projects needs, then I started to have such an error 'No block-level parent found. Not good'. Checking the Stylesheet class, it loads the default CSS 'html.css' in 'res' directory and I noticed that the method getDefaultStylesheet() specify a relative path which makes the css file inaccessible, thus Dompdf does not create the 'base' style to process when render() method is called. Without it, block-level parent rise such an error. After I changed the relative path in getDefaultStylesheet() method of Stylesheet class, pointing right to the resource file, everything worked fine. Hope this help!

@akovalyov

This comment has been minimized.

Copy link

commented Dec 20, 2016

I have a very same trouble when reusing a Dompdf instance for multiple PDF documents creation. Quite confusing if using DI and Dompdf as a service. Looks like, something is not cleaned up correctly after rendering.

@bsweeney

This comment has been minimized.

Copy link
Member

commented Dec 20, 2016

@akovalyov hoping to fix this in the next release. Follow #1056 for updates.

@UweKeim

This comment has been minimized.

Copy link

commented Dec 29, 2016

Same here as @marcleimvs said:

After I configured alternative directories, I get the same error:

No block-level parent found. Not good.

@bsweeney

This comment has been minimized.

Copy link
Member

commented Dec 29, 2016

@marcleimvs, @UweKeim: when you state that you change the Dompdf directories to suite your project's needs ... what exactly does that mean? There is a level of configuration possible, but moving the lib/res directory isn't one of those options. We can look at making that a possibility if it's something that's needed.

@UweKeim

This comment has been minimized.

Copy link

commented Dec 29, 2016

@bsweeney In my case I tried to move the writable font folders outside my PHAR.

This was not sufficient.

What currently works on my Windows dev machine is to remove all realpath calls inside the dompdf sources.

I.e. this:

$dir = realpath(__DIR__ . "/../..");

will become this:

$dir = (__DIR__ . "/../..");

Inside PHAR archives, realpath for paths inside a PHAR file returns false (See #52769).

@bsweeney

This comment has been minimized.

Copy link
Member

commented Dec 29, 2016

@UweKeim let's move this discussion to #621.

@iiamfawad

This comment has been minimized.

Copy link

commented Apr 27, 2017

Hi there, I'm facing the same issue on my server. What are the possible solutions? Can anyone help please, I'm stuck!

@alanducnguyen

This comment has been minimized.

Copy link

commented Nov 28, 2017

I got the same issue "No block-level parent found. Not good".
After the investigation, I tried to call loadView() with simple HTML only.
I discovered that my HTML view is not well-form. (The "<link>" tag located outside of "<head>" tag).
I corrected the HTML validation, then the issue has been gone.
In hopeful, anyone had the same case with me can fix the issue.
Sometimes, The error "No block-level parent found. Not good" cause of some HTML is not valid.
Try to make sure the HTML tag valid, then the issue will be gone.
Thanks.

@murph133

This comment has been minimized.

Copy link

commented Nov 29, 2017

I had the same problem. It was solved simply by update the software version.

Run composer update

@nadiyaparaamit

This comment has been minimized.

Copy link

commented Jan 22, 2018

Remove <thead> and <tbody> tags
and remove space between <html><head> , </head><body> and </body></html>

It will work fine.!

@rmoni3000

This comment has been minimized.

Copy link

commented Jan 22, 2018

@nadiyaparaamit solution's worked perfectly for me too! (Y)
Ps. I could not update my dompdf version on live server!

@nadiyaparaamit

This comment has been minimized.

Copy link

commented Jan 22, 2018

👍

@wreardan

This comment has been minimized.

Copy link

commented Jan 24, 2018

Remove <thead> and <tbody> tags - I did not do this because these were needed for multi-page table headers.

Remove space between <html><head> , </head><body> and </body></html> I did this and it worked! Thank you so much! I did not think this would work but for some reason it did.

@jeffersonor900

This comment has been minimized.

Copy link

commented Jan 30, 2018

@sitilge where?
"After enabling the HTML5 parser, the error was solved."
$options = new Options([
'isHtml5ParserEnabled' => true
]);

$dompdf->setOptions($options);

@jeffersonor900

This comment has been minimized.

Copy link

commented Jan 30, 2018

@nadiyaparaamit it did not work

"Remove and tags
and remove space between , and

It will work fine.!"

@jeffersonor900

This comment has been minimized.

Copy link

commented Jan 30, 2018

Hi there, I'm facing the same issue. What are the possible solutions? Can anyone help please, I'm stuck!

@hanoii

This comment has been minimized.

Copy link

commented Feb 6, 2018

@nadiyaparaamit what is this dark magic 😄 ? It did work for me 🥇 .

This happened on an old project (where I am using an old version of dompdf) and just moved it to a new server. It wasn't happening on the old one with the same codebase. Any ideas of this?

@themao

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2018

@jeffersonor900 there is a workaround for this issue #902 (comment)

@jdicdican

This comment has been minimized.

Copy link

commented May 7, 2018

#902 (comment) - thanks @nadiyaparaamit, this saved my day

@LiamMcArthur

This comment has been minimized.

Copy link

commented May 21, 2018

@hanoii did you ever manage to fix this? I'm currently migrating from one server to another and having the same problem!

@josephdicdican

This comment has been minimized.

Copy link

commented May 28, 2018

I am working on local, php version - PHP 5.6.36 (cli) removing spaces did not working for me. Please help

exception 'DOMPDF_Exception' with message 'No block-level parent found. Not good.' in

@hanoii

This comment has been minimized.

Copy link

commented May 28, 2018

@liam @josephdicdican I fixed it by following #902 (comment)

Make sure ALL spaces are removed.

@josephdicdican

This comment has been minimized.

Copy link

commented May 29, 2018

thanks @hanoii , I doubted it would solve the issue but it really did. My bad, I am editing the wrong pdf layout blade.

@LiamMcArthur

This comment has been minimized.

Copy link

commented May 29, 2018

It turned out composer update was failing because my directory path exceeded 260 chars. Instead, I've manually copied across all of the files from the updated version and it's all working perfectly now!

@nospoon

This comment has been minimized.

Copy link

commented Jun 12, 2018

This is not fixed as of 0.8.2. Removing tags and spaces is NOT a solution, it's a hack.

christian-forgacs added a commit to christian-forgacs/PhpSpreadsheet that referenced this issue Jul 20, 2018
@egan95

This comment has been minimized.

Copy link

commented Aug 2, 2018

Remove tag <head> and </head> . it's worked for me...

@victor-priceputu

This comment has been minimized.

Copy link

commented Oct 22, 2018

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

This comment has been minimized.

Copy link

commented Oct 22, 2018

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; }

@bsweeney

This comment has been minimized.

Copy link
Member

commented Dec 31, 2018

Interestingly, in our default CSS we style the HTML element with display: -dompdf-page; ... but that display type isn't referenced anywhere. I'll have to research this a bit more.

The BODY element is appropriately styled with display: block; but that can be overridden. I'll update the base stylesheet to at least add !important to the body display styling.


Removing tags and spaces is NOT a solution, it's a hack.

Agreed, and if the problem were with Dompdf we would (eventually) address the issue so the hack wouldn't be needed. For the cases discussed where this is the workaround the bug is not with Dompdf but with a system library. That's beyond the scope of our control and should be reported to the team that maintains that library.

That being said, there is one issue we have not yet addressed brought up by the previous comment: display styling on the body element can throw an exception. And if you're interested in seeing that fixed follow #1869.

@tuckbloor

This comment has been minimized.

Copy link

commented Mar 5, 2019

For googlers like me, it refers to this bug #1056

thank you

@ovisopa

This comment has been minimized.

Copy link

commented Apr 7, 2019

I used domPDF (0.5.1) on many websites I made in the past, everything was fine for years, until yesterday when I updated my cPanel server to newer PHP (7.1 and for older websites also 5.6, before I had 5.4)

Now with PHP 5.6 all websites I made in the past CAN'T generate anymore the PDF invoices, all have this error, which I'm not yet sure yet how to solve after reading the comments, so far I tried to delete ( tags), tried the #902 comment suggestion to unset($dompdf) nothing worked.

So , is there any fix ?

Thank you.

UPDATE. FIXED this way :

instead of having properly formated html code like this:

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

I deleted all the new lines or spaces between the tags, now it looks like this :

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

This way I have no errors , I have PDF invoice generated again in my websites.

@Sheep42

This comment has been minimized.

Copy link

commented Apr 17, 2019

Can confirm that updating from dompdf 0.8.0 to 0.8.3 fixed the issue for me. In our case, the server was switched to PHP-fpm and that's when it broke.

@hguru

This comment has been minimized.

Copy link

commented Apr 30, 2019

an update will be required

@bsweeney bsweeney removed this from the dompdf-next milestone May 18, 2019
@javacado

This comment has been minimized.

Copy link

commented Jun 18, 2019

@nadiyaparaamit solution's worked perfectly for me too! My issue happened after an update of apache/cpanel etc. Just removing the spaces did the trick.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.