|
secretariaat
|
January 17, 2023 at 9:59 am
I’m using the shortcode [DISPLAY_PDF_BUTTON]. It seems that the class “print_button_div noPrint” does not prevent the button from being shown in the generated invoice PDF file.
|
|
Tony
|
January 17, 2023 at 11:45 am
Hi there,
Where are you adding the above shortcode? I’ll see if I can reproduce this.
|
|
secretariaat
|
January 18, 2023 at 12:29 am
in the WP dashboard > event espresso > messages > default message templates > invoice (Edit Purchaser) > main content
|
|
secretariaat
|
January 18, 2023 at 12:34 am
I would like to add to the problem the generated and downloaded PDF invoice does not have the same font as the webpage. It seems that CSS is ignored.
|
|
Tony
|
January 18, 2023 at 3:13 am
in the WP dashboard > event espresso > messages > default message templates > invoice (Edit Purchaser) > main content
That’s where the default button is added:
https://monosnap.com/file/F1XojqBS8pH2nFRbx2DJFR7vbNxMdu
In text mode:
https://monosnap.com/file/moFZvcT6j0AMcgGk4Ibx7EbgpDnzyO
Are you using the same setup?
I would like to add to the problem the generated and downloaded PDF invoice does not have the same font as the webpage. It seems that CSS is ignored.
That usually happens when allow_url_fopen has been disabled on the server.
Your host will often have options within your control panel to enable allow_url_fopen but if not you’ll need to contact them and request they enabled it for you.
Note – that is likely related to the above as the CSS wont be loading into DOMPDF to hide the button.
|
|
secretariaat
|
January 18, 2023 at 3:48 am
Okay could there be another solution? I just verified with phpinfo() that allow_url_fopen is enabled for Local value and Master value.
|
|
Tony
|
January 18, 2023 at 4:05 am
Can you send me a link to the invoice so I can take a look?
You can mark your reply private so only staff can view it.
|
|
secretariaat
|
January 18, 2023 at 5:01 am
This reply has been marked as private.
|
|
Tony
|
January 18, 2023 at 5:13 am
The output your getting is what happens when allow_url_fopen is disabled (yes I know you’ve said it’s enabled above).
If you enable WP_DEBUG on the site do you see any error when you load the Invoice page or PDF?
Or, you can enable logging using this snippet in your wp-config.php file:
https://eventespresso.com/wiki/troubleshooting-checklist/#wpdebug
Then download the PDF and see if any errors are logged.
|
|
secretariaat
|
January 18, 2023 at 5:49 am
This reply has been marked as private.
|
|
Tony
|
January 18, 2023 at 5:56 am
I’ve seen PHPInfo show allow_url_fopen to be enabled but then it’s not, or specific transport protocols have been disabled so it’s enabled but then doesn’t actually allow the request.
Also, if you go to Event Espresso -> Maintenance -> System information, you’ll get a PHPinfo output from within the WordPress environment (because yes, it can be different).
Then try enabling WP_DEBUG so that display_errors is enabled and retry. You’re looking for warnings, notices or anything on loading the HTML and PDF requests for the above link.
|
|
secretariaat
|
January 18, 2023 at 6:35 am
Okay but even in WP it shows as enabled. I have asked our network admin to look in to this. Meanwhile I have added
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
if ( WP_DEBUG ) {
@ini_set( 'display_errors', 0 );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
}
But there are no errors and so a log is not created.
|
|
Tony
|
January 18, 2023 at 7:32 am
So your site throws no notices, warnings, or anything at all?
Usually, there is at least 1 notice, warning or something.
You’re on PHP8 and WordPress itself throws deprecated notices on the requests with PHP8, so something isn’t adding up here.
|
|
secretariaat
|
January 19, 2023 at 1:09 am
Our websites won’t be public until the frontend console shows us zero errors.
In the backend when using block editor, I do see some typeerrors from event espresso but these are not related to this problem.
After using the registration form I have found one Deprecated notice in the logs this morning, but to me it does not look related to the PDF/CSS problem:
PHP Deprecated: Required parameter $compare_to follows optional parameter $validation_error_message in ***/wp-content/plugins/event-espresso-core-reg/core/libraries/form_sections/strategies/validation/EE_Equal_To_Validation_Strategy.strategy.php on line 24
To be sure it is not a PHP8 problem I have asked the hosting provider to downgrade to PHP7.4
|
|
Tony
|
January 20, 2023 at 2:18 am
Our websites won’t be public until the frontend console shows us zero errors.
Sure, but front-end/console errors aren’t what I’m referring to. The issue with your PDF’s isn’t a frontend issue, it something happening within DOMPDF when it generates the PDF from the HTML passed to it and generally issues within DOMPDF will show some form of warning/notice/something in the PHP error logs.
After using the registration form I have found one Deprecated notice in the logs this morning, but to me it does not look related to the PDF/CSS problem
Yep, I’d also say that’s unrelated to this.
To be sure it is not a PHP8 problem I have asked the hosting provider to downgrade to PHP7.4
Did that change anything with this?
|
|
secretariaat
|
January 25, 2023 at 1:11 am
We have tried PHP7.4 with the same result. There were no PHP errors. We did find some errors about missing files in the server log but after I made these files available I found that EE switches to the old invoice system.
(receipt_body.template.php invoice_body.template.php html_invoice_base_default.css html_invoice_print_default.css html_invoice_main_default.css in various places)
So I reverted these changes and for now I have removed the download button.
|
|
Tony
|
January 25, 2023 at 4:30 am
Hmm, ok.
Let’s take a step back here and see if the default Invoice content works, I suspect it will still show the same issue but lets confirm.
Go to Event Espresso -> Messages -> Default Message Templates, find the Invoice message type and click ‘Create Custom’ on that line.
That’s going to create a custom template based on your current default and take you to the page to edit that template.
On that custom message template, hit the ‘Reset templates’ button.
Create a temp test event and in the ‘notifications’ section, click the HTML section and chose the Custom template for invoice.
Register onto that event, view the invoice (it should look different than your template) and see if the PDF is broken on that.
(Note I’m testing here to see if there is something within your customized template that DOMPDF doesn’t like, its much more finick over HTML than your browser is)
|
|
secretariaat
|
January 26, 2023 at 6:20 am
Changing the template didn’t help but we found that adding www. to our domain fixed the problem.
|
