PDF attached to Email not rendered correctly

bggann

bggann

Active Member
I've got a complex form that needs to generate a pdf upon submission for the email plugin.
I've created a custom template to format it - and that template is being used both when the PDF button on the form is pressed and for the pdf attachement in the email.

The pdf renders correctly when I press the PDF button on the form.
The pdf does not render correctly when created by the email plugin and attached to the email.

Both use dompdf.
Both use the same template (I have a tag in that template that prints in both so I can see it is running through the template code).
It does not appear to be a template problem, but a problem with how the code is rendering the html to dompdf.

I've looked carefully at the code that sends to DomPDF from the form button press and the email, they are different in detail, but not in concept.

I believe the issue is related to how the html stream is created for input to domPDF.
In pdf render code (components/com_fabrik/pdf/pdf.php about line 130) the data is created by

$data = parent::render();
That is converted using mb_convet_encoding.
Then it is sent to dompdf $pdf=>load_html($data);

In the email plugin it appears the data from a "model" (There is a comment from Hugh about stuffing our model in there with already formatted data).
It is then put in an output buffer
It is then sent to dompdf with the decode built in
Roughly
$controller->display();
$html = ob_get_contents();
$domPdf->load_html(utf8_decode($html));
About line 490 in plugins/fabrik_form/email/email.php

I've tried to look at the html in the log file for dompdf - but it is huge and there is no obvious problem

----------
What I need - the email attached pdf needs to "work".
I don't know if we can substitute the code from the pdf button in there somehow - or what.
Even if I could create the pdf from the button and attach that, it would be fine.

I'm happy to provide login information to the site as well as the cpanel if needed.

I attached example pdf's to here with some data redacted (privacy). Look at the FMO Name and FMO Email. The label is there, but the data missing.
Look at the "Type" in the table. The label "Type" is there, but the data bellow it in the table is missing.
IGNORE other differences they are the result of my redacting probably. Only FMO name, FMO Email and Type are wrong.

Forgot. Current Fabrik and Joomla. Pulled Joomla from github.

-Bob
BTW:
- you may have seen this in community forum. I just got the authorization to sign up for pro support. I expect that to continue for a while at least (some months).
- Hugh - you and I have worked together on Scottish Terrier Club forms in the past- you may remember.
 

Attachments

  • PDF_OK.pdf
    33.6 KB · Views: 600
You only attached the OK version, I think.

Yes, the way they get rendered is different, simply because of the restrictions of the MVC architecture - Model, View, Controller. When you hit the PDF button on the form, you are firing off the form's controller, which loads and renders the Fabrik form view (with help from the model). When the email plugin is running, it's not in a form view, it's just part of a form submission. So the data we have is what came from the submit process (the posted data), not how it would be if we were reading that form data from the existing row in the database as part of a form view load.

And the problem is, submitted data that we are in the process of writing out during a submission, is often in different formats to table loaded data in a form view.

I'll take a look, see what I can figure out.

-- hugh
 
Thanks Hugh,

It's not essential that the pdf be generated AT submission time. If I could trigger the pdf that is generated in form view and save it somewhere, then attached it using the attachments part of the email plugin, that would work. My goal is to deliver a pdf to the submitter somehow. I know it is archaic to have pdf's, but this is part of a emergency response management system and all the equipment needs hardcopy (pdf's) of the data physically on the truck. I'm also probably going to want to figure out how to get a page break in that pdf somehow too. Break 'groups' up. The original submission form had pagation turned on and I prefer that. But that makes the pdf part worse because you only get the page that is being displayed when they hit the pdf button.

-bob
 
Oh - I'm not sure I know how to do that. Also - the site is on a development server that does not support direct IP access. You have to create an entry in hosts file that points at the server, then it will locally resolve to it. Give me a minute to find sites and I'll set it up.
 
One thing you could try is in the email.php for the email plugin, where we set that model data, try unsetting it ...

Code: 
//$controller->_model->data = $this->getProcessData();
$controller->_model->data = null;

... so comment out the existing line and add that second one.

That should force the view to reload the data, as if it was displaying a form. See if that changes anything.

-- hugh
 
Okay- I'm getting an error
Error
Unknown column 'Array' in 'where clause' SQL=SELECT DISTINCT(`list_of_resource_kinds`.`kind`) AS value, `kind` AS text FROM `list_of_resource_kinds` AS `list_of_resource_kinds` WHERE `list_of_resource_kinds`.`kind` IN (Array,Array,Array) ORDER BY text ASC
and no pdf is attached.

Not sure what that query is doing - those are valid tables and columns
 
Okay- I set that up.
As for generating the email - hmm - the easiest way is to do 2 things.
1) have you use _my_ login to the Joomla site - that will allow you to access a form that is filled out. Otherwise you have to fill it out.
2) Add your email to the email plugin list of recipients.

You'll submit as me, but you'll get copied on the email.

Back in a moment....
 
Okay- The sites information is there. Navigating to the site is tricky because the name is not registered yet. You have to put a line in hosts. That is in the 'notes'. You have both front end and back end access using the same login. You also have ftp access.
To get an email - you will need to add your target email address to the form email plugin - details in "sites" notes.
I did it this way so you have a pre-filled form to use. When you log in and click on the CRRF link - you will immediately be in a form that is filled out. All you have to do is submit it and it will generate the email
- Bob
 
OK, as per our Skype conversation ...

The issues with the 'calc' were because you were using a non-raw placeholder to get the FK value to look up another table, and the element that placeholder used had 'detail link' enabled ... so the value you were getting during PDF creation has the link wrapped round it. Appending _raw to the placeholder fixes that.

The issue with the CDD in the repeat group was a corner case problem, fixed in this commit:

https://github.com/Fabrik/fabrik/commit/11ee4f28a61c45f91268199e450f7e84f6ea1013

... which I also applied by hand to your server.

-- hugh
 
cheesegrits said:
OK, as per our Skype conversation ...

The issues with the 'calc' were because you were using a non-raw placeholder to get the FK value to look up another table, and the element that placeholder used had 'detail link' enabled ... so the value you were getting during PDF creation has the link wrapped round it. Appending _raw to the placeholder fixes that.

The issue with the CDD in the repeat group was a corner case problem, fixed in this commit:

https://github.com/Fabrik/fabrik/commit/11ee4f28a61c45f91268199e450f7e84f6ea1013

... which I also applied by hand to your server.

-- hugh
Click to expand...
Damn,

In the process of doing the "large agency upgrade"
(see http://fabrikar.com/forums/index.ph...for-a-fabrik-app-not-fabrik-application.46110)

I applied updates from Fabrik - we had discussed that in the forum discussion failures on large pdf's.

Now - a defect we had fixed has re-appeared. I'm using a custom template, so I don't think that would have be overwritten.

NOTE: This string talks about other Calc fields, not the ones failing here, but it seems they were related.

The issue is some calculated elements are not printing in an attached pdf. I recall this happening, and I think you (Hugh), fixed something to make it work. I checked and the changes you mention above that you applied to my site are included in the updated code I pulled- so I'm baffled what I did to re-introduce the error.

Attached are 2 pdf's. One with the problem, one without. The "bad" is from the new site. The "good" is from the old site.

Look at the repeated table on PAGE 5 on the right there should be a "daily rate, rate unit and daily gaurentee" value for each resource.

Does this ring a bell? Dang!!!

OH - and it works using the PDF button on the site. The data in those columns is rendered correctly. I'm sure we fixed this - but how and why did updating overwrite it....

Sites data points to the testing site with the problem
 

Attachments

  • Bad example.pdf
    11.1 KB · Views: 68
  • good example.pdf
    11.6 KB · Views: 48
Last edited:
bggann said:
Damn,

In the process of doing the "large agency upgrade"
(see http://fabrikar.com/forums/index.ph...for-a-fabrik-app-not-fabrik-application.46110)

I applied updates from Fabrik - we had discussed that in the forum discussion failures on large pdf's.

Now - a defect we had fixed has re-appeared. I'm using a custom template, so I don't think that would have be overwritten.

NOTE: This string talks about other Calc fields, not the ones failing here, but it seems they were related.

The issue is some calculated elements are not printing in an attached pdf. I recall this happening, and I think you (Hugh), fixed something to make it work. I checked and the changes you mention above that you applied to my site are included in the updated code I pulled- so I'm baffled what I did to re-introduce the error.

Attached are 2 pdf's. One with the problem, one without. The "bad" is from the new site. The "good" is from the old site.

Look at the repeated table on PAGE 5 on the right there should be a "daily rate, rate unit and daily gaurentee" value for each resource.

Does this ring a bell? Dang!!!

OH - and it works using the PDF button on the site. The data in those columns is rendered correctly. I'm sure we fixed this - but how and why did updating overwrite it....

Sites data points to the testing site with the problem
Click to expand...

Okay - I got it fixed again. It was something we (I?) had fixed.
The key was this statement.

cheesegrits said:
OK, as per our Skype conversation ...

The issues with the 'calc' were because you were using a non-raw placeholder to get the FK value to look up another table, and the element that placeholder used had 'detail link' enabled ... so the value you were getting during PDF creation has the link wrapped round it. Appending _raw to the placeholder fixes that.

-- hugh
Click to expand...

I looked at the query for the calc for the missing fields and they did not have "_raw" appended. I added that and it worked.
The weird thing is the "old" site that worked did not have the _raw either, but it worked.

So - something in the update caused this defect to appear on these fields.
The "new" site was a clone of the 'old' site using Akeeba. Then had the Fabrik updates applied. I didn't even touch these fields.

Just for clarity, the _raw I'm talking about is in an sql query shown here.

Fixed:
------------
$db = JFactory::getDbo();
$selected_kind = str_replace("%20"," ",'{crrf_3_repeat___resource_kind_raw}');
$selected_type = str_replace("%20"," ",'{crrf_3_repeat___resource_type_raw}');
if (empty($selected_kind) or empty($selected_type)) {
// Exit out
}
else {
$query_string = 'SELECT id, work_rate, work_rate_unit, daily_gaurentee FROM kind_to_type_map WHERE kind = "'.$selected_kind.'" AND type = "'.$selected_type.'"';
$db->setQuery($query_string);
$rows = $db->loadObjectList();
foreach ($rows as $row) {
$row->work_rate;
$array = (array) $row;
}
}
return $array["work_rate"];
---------
Broke
-----
$db = JFactory::getDbo();
$selected_kind = str_replace("%20"," ",'{crrf_3_repeat___resource_kind}'); <----------------------------Here.
$selected_type = str_replace("%20"," ",'{crrf_3_repeat___resource_type}');
if (empty($selected_kind) or empty($selected_type)) {
// Exit out
}
else {
$query_string = 'SELECT id, work_rate, work_rate_unit, daily_gaurentee FROM kind_to_type_map WHERE kind = "'.$selected_kind.'" AND type = "'.$selected_type.'"';
$db->setQuery($query_string);
$rows = $db->loadObjectList();
foreach ($rows as $row) {
$row->work_rate;
$array = (array) $row;
}
}
return $array["work_rate"];
 
I'm not entirely clear if you are saying it's fixed, or you still have an issue.

Bottom line, when using placeholders that you are going to use in queries, you should pretty much always use the raw ones, so the value doesn't have any formatting applied to it.



Sent from my HTC 10 using Tapatalk
 
You must log in or register to reply here.

Useful links

  • Create a Fabrik Account (Downloads)
  • Create a Forum Account
  • Fabrik Wiki
  • Fabrik 4 Changelog /Install /Upgrade
    • We are in need of some funding.
    More details.

    Thank you.

    Members online

    Total: 98 (members: 1, guests: 97)
    Back
    Top