|
wvnet-support
|
April 9, 2021 at 9:59 am
Our webserver is behind a proxy … it both offloads https processing as well as uses a 2nd NIC for communication, and of course has a different IP than the one presented to the public.
so when dompdf wants to use, say, http://wvstc.com/wp-content/plugins/event-espresso-decaf/core/templates/global_assets/images/calendar_year-24×24.png
that image works fine when presented to a real user with a real browser out in the public, but when dompdf tries to pretend to be a browser in order to render the page as it creates a pdf, that URL is never processed/satisfied. The same happens for our logo image on the Payment Methods panel.
generic blog searching for dompdf issues suggest the dompdf package itself might be capable of using relative or absolute file paths (like /wp-content/plugins/event-espresso-decaf/core/templates/global_assets/images/calendar_year-24×24.png) in place of a FQDN URL …
please help
|
|
Tony
|
April 12, 2021 at 5:28 am
Hi there,
Are you sure this is connected purely to the proxy?
With the current set up DOMPDF requires allow_url_fopen to be enabled for all ‘external’ resources (images, scripts, etc) and looking at your PDF’s none of the images or scripts load. So the first check I would do is to confirm if allow_url_fopen has been disabled on your server as it often has.
The same happens for our logo image on the Payment Methods panel.
That one is a little different as it uses wp_remote_request() so generally a ‘standard’ curl request.
If your getting this issue in both sections then switching to use relative paths within DOMPDF isn’t a fix here.
If I borrow the URL for your company logo and set it within the Invoice settings on one of my sites, DOMPDF has no trouble creating the PDF’s using the URL and it’s shown correctly in the Payment method settings if I use HTTPS.
Are you loading the images via http or https?
|
|
wvnet-support
|
April 12, 2021 at 4:24 pm
allow_url_fopen is enabled. Everything displays perfectly on my normal user browser window that is accessing the server from the “outside”.
My two NIC config along with the internal IP of the actual server is a known issue to me that prevents CURL from working, hence I feel the relative or absolute path method of directly accessing the images may work while any http/https methods will absolutely (sadly) fail. In addition the actual server only supports http while everything presented to the public is https; and if the public does get a http URL, our load balancer/proxy F5 when it sees an incoming http request, will issue a redirect to ask the users browser to re-try it with https …
Again everything works perfectly when I am outside the F5, as all public users will be. and YES, I think the image config items are listed as HTTPS.
the site in question is our registration page for a conference this summer; you can register if you want, then choose CHECK or INVOICE as payment method (no need to use a credit card) to go all the way thru the process … we can cancel your registration later. https://wvstc.com … but again, the on-screen display is perfect for all normal users.
|
|
wvnet-support
|
April 19, 2021 at 10:54 am
any ideas ?
|
|
wvnet-support
|
May 6, 2021 at 10:28 am
I really need help with this … or just tell me its a limitation of Event Espresso and I need to change my configuration to make it work.
|
