Support

June 12, 2019 at 4:57 am

Can you link me to an Invoice for a test registration so I can take a look?

Just to add. The invoice is show correctly on the screen but only the downloaded PDF file has encoding issue.

That’s expected, its DOMPDF (which we use to generate the PDF’s) that is struggling with the characters, your browser will display them fine as it will have the font’s installed on your system.

June 12, 2019 at 7:45 am

It looks like we need to update the UTF8 add-on the pre-release channel to include the latest changes for DOMPDF included in core, I’ll get that updated soon.

In the meantime, you can use the version HERE.

De-activate and delete the current ‘EE4 UTF8 Template Variation’ add-on you have, then install and activate the above.

That should load the font correctly in the PDF.

June 12, 2019 at 8:11 am

Ok, looking at your Invoice I can see its loading the utf8 files however the PDF has no styling applied at all.

That’s normally an indication that allow_url_fopen has been disabled on the server, meaning DOMPDF can’t pull in the ‘external’ files (CSS, images and so on are considered external in this case).

If you go to Event Espresso -> Maintenance -> System information

Search for ‘allow_url_fopen’ what does it show?

June 12, 2019 at 8:27 am

Ok, can you temporarily enable WP_Debug on the site so I can see if there are any errors?

To do that you add the snippet shown here:

https://eventespresso.com/wiki/troubleshooting-checklist/#wpdebug

To your wp-config.php file, somewhere above this line /* That's all, stop editing! Happy blogging. */

June 12, 2019 at 8:45 am

Thank you, but no error captured in relation to the PDFs.

Try just using define( 'WP_DEBUG', true ); temporarily (fair warning any errors/notices etc will be shown to your visitors whilst that is enabled) and I’ll download PDF whilst errors are shown.

Or, you can use:

define( 'WP_DEBUG', true );
if ( WP_DEBUG ) {
        @ini_set( 'display_errors', 1 );
        define( 'WP_DEBUG_LOG', true );
        define( 'WP_DEBUG_DISPLAY', true );
}

Again, errors will be output to that page whilst this is enabled so set it and let me know, I’ll download a PDF and post here so you can disable again, or you can download the PDF and disable again, then send me the PDF if preferred.

June 13, 2019 at 3:24 am

I’ve switched back to Simple Template Style

Thank you, so I’ve used that to confirm you have the same issue on the standard template, so encoding issue aside there’s something on your server preventing the CSS files from being loaded into DOMPDF.

I tested the UTF8 add-on my site after switching the language to Polish and downloading a PDF: https://monosnap.com/file/IDsSAd90U6GmIXkQsJ6lY5ridcr7Zl

As you can see the non-latin characters are loading correctly there.

I ran a few more tests against the files on your site and as mentioned, it does appear that ‘external’ files are being blocked.

I ran this from one of my servers:

$test = file_get_contents('http://www.rozkodujmyafazje.pl/wp-content/plugins/event-espresso-core-reg/core/libraries/messages/defaults/default/variations/html_base_default.css');
var_dump($test);

Which returns: failed to open stream: HTTP request failed! HTTP/1.0 403 Forbidden

I recommend you contact your host and have them investigate this further, something on your server is blocking the above connections (file_get_contents() is the function used by DOMPDF, so it needs to function).

June 13, 2019 at 5:47 am

No, there’s no workaround for this.

DOMPDF will apparently try to use cURL if allow_url_fopen is disabled but we often have reports from users with allow_url_fopen that PDF’s aren’t working, they then enable allow_url_fopen and it works as expected so it appears the cURL method often doesn’t work.

You apparently already have allow_url_fopen enabled (which is what file_get_contents() uses) which is generally what hosts will state is a security risk.

If your host is not willing to enable the functions required you’ll need to change hosts.