Background-image url absolute paths #1683
Comments
|
Same problem here. |
|
@jonathanpmartins As a work around I can confirm you that passing the image as base64 does indeed work. |
|
than you very much @SergioReis97! This solve my problem! Base64 it is... |
|
Does this continue to be an issue? I was unable to reproduce using the latest version. |
|
Yes it is an issue. I'm building for many months now a plugin working with domPDF among other things and i never never never managed to set a working background image. I'd love to help to improve the domPDF on this but how could I? For now i just tried the current release 0.8.3 with php 7.2 and it does not work. I also tried the current nightly version and it did not work either. I tried with both relative and absolute paths. I also tried with a base64 encoding function and then it worked. It also worked with a simple url, if isRemoteEnabled on true of course (which i can't use). Still can't use background with a path.. |
|
OK, yes, I think I can confirm this is a problem ... at least with minimal testing. I'll do some more research and provide a fix if necessary for the next release. |
|
I've got the same problem here, base64 and external links works fine as long the system path dont. Using php 7.3 and dompdf 0.8.3. Any clue on how I can help to fix it? |
|
@bsweeney If you can tell me where to look I can probably make a PR for this to help out. |
|
This may not still be an issue with the 0.8.6 release. We made some changes to how local resources are processed. Is anyone able to confirm? |
|
It is still an issue. I had to change code for this today. It's not only with background images, but also with an IMG tag. |
|
For local resources, generally, the issue after an upgrade to 0.8.6 may be related to the change to honor the chroot (see #2229). I'll double-check, but in working on the updates I know I tested URLs of the form indicated by the OP. |
|
I believe this should be addressed now. FIlesystem URLs beginning with a "/" are retrieved relative to the filesystem root (not the document root). There is an issue with not root relative references from external stylesheets that have a different base path from the document itself. That should be fixed by (5a9fafb). Please post back if this is still problematic when using the forthcoming 1.0.0 release. |
|
Sorry, what's the difference between filesystem root and document root? Thank you. |
|
Filesystem root is the highest level the user can reach on the filesystem. Usually: |
|
To follow up on that, setBasePath is relevant only in regards to relative paths, something like "images/image.png". Anything starting with a root-path string "/" or "" is treated as an absolute path and prepending of the base is not done. |
|
Got it thanks all! |
I've been reading the issues about images ( i know there's a couple already) but none fitted 100% what i need, #1209 is basicly the same but that solution doesn't work in my case since i need image on every page.
When trying to use background-image prop, images never load, but the exacly same path does load on a img tag,
Some of urls i tried.
However, this img tag works
<img src="/var/www/html/project/storage/app/randomFolder/sidebar.png">If I place an image on public folder and try
<body style="background-image: url('http://localhost/sidebar.png');>It does load, but i'm trying to not have the image publicly accessible.
Also a route to access the image brings kind of the same problem since the request to get the image would need to be authentified,
As a workaround i'm going to try to fetch the file instead of the path and attempt to use it as a base64 string url encoded since base64 image seem to work.
Sys info:
Linux mint 18.2,php 7.0, Laravel 5.5 using:
"barryvdh/laravel-dompdf": "^0.8.1",The folders do have the right permissions
Issues for reference
#50, #1209, #1346
The text was updated successfully, but these errors were encountered: