Post images not included

I’ve been puzzling over this one for a while this evening, with no real conclusion as yet. I’m not giving up on it, though.

We don’t actually follow the filesystem at all when grabbing the images. We take the HTML as rendered, add a bit to it, and then hand the resulting (modified) output to TCPDF to convert to PDF.

I know we have an issue with absolute vs relative paths (check out the support threads here for some discussion), but I think what we’re seeing in your case is a different condition, where we’re not applying the rewrite rule before generating the HTML, and that’s what I’m trying to wrap my head around right now.

Do you have a link to share?

Thanks!

Lewis

Hello,

I do not have a public example. In the PHP log files the error is shown, that for example the function createfrompng can not find the image /files/image.png.

Of course because the folder is a virtual directory. I think it is not related only to the wordpress rewrite rules. Many sites use htaccess rewrite rules or virtual webserver directories. In all cases there will be the same problem.

But one question:
Does it work when the absolute url with https:// is stored in the post content? So can the PHP function call the image from a url?

This is not a solution because then a further problem will occur. This is described in the other topic related to relative paths and for example a private site it is more a general question.
Maybe it is possible to render the images with the html img tag and rewrite/add the path with the called server name before process to TCPDF.

You are asking me questions beyond the scope of my plugin, unfortunately, which I can’t answer with confidence. TCPDF is maintained by someone else, although that’s what I use to generate the PDF. The error you are seeing is coming from TCPDF.

My best read is that if the image url can be located without rewrite rules, and the server grants access (i.e., no permissions issues), then we should be able to successfully pass it along to TCPDF in the HTML and the image will render. A number of things can break this chain however (I’ve mentioned permissions as a second consideration).

Looking around the net, however, this does not seem uncommon. There is even a suggested workaround (related to Drupal, which also uses TCPDF). I’ll look at that to see if it might apply here so that we can determine the absolute path when putting the intermediate HTML together. This is what you have proposed, I believe.

You are right to mention that yours is likely not an isolated incident, and certainly when I need to address things for multisite (and I do have plans to make this multisite-aware) I’ll need to review the situation regarding these image paths.

Meanwhile, have a look at the link above, and do some Googling (tcpdf image url) to see if there’s anything which looks closer to your particular situation.

Cheers. I’m looking at this, so please bear with me.

Lewis

Oops…

imagecreatefrompng is a PHP function, and not one from TCPDF. That doesn’t mean that the issue isn’t the same (can’t find the image to render), but it means that we are (probably quite logically) getting notified by PHP and not by TCPDF.

Sorry; I should have clarified earlier.

Cheers

I’d like to close this one as it appears to be beyond the scope of this plugin and/or other plugins exist to work around the absolute vs relative path issue (if that is indeed the problem).

In short, if we can’t reach the image file to render it, we give up. I’ve entered an enhancement request in my internal bug tracker to fail more gracefully.

Also:

Maybe it is possible to render the images with the html img tag and rewrite/add the path with the called server name before process to TCPDF.

This rewriting is certainly do-able, if necessary, but it may be more problematic, especially if urls change (archiving, etc.)

Trunk builds are handling these urls a bit differently, now, too (and I think that 1.0.3 implemented the change, as well). Please advise if this is still an issue.

Thanks!

Lewis