Form won't use selected PDF layout and always fallback to the details layout

[joomlamate]

I have 2 similar forms. Both they have custom detail and pdf layouts.
Fabrik and Joomla have been updated recently to their latest versions.
After the update, one of the 2 forms refuse to use the selected PDF layout and will always use the details one.
The other form is working as expected. Any idea what may be causing this?

 

[joomlamate]

Actually my main problem is: why PDF attachments use the details template instead of the PDF one?

 

[troester]

This is fixed in the current GitHub version.

 

[joomlamate]

I updated from github, but the problem now is that during the initial form submit the PDF is blank. I only get a printed PDF with the form data, after editing and re-saving the form.

 

[troester]

Not sure what you mean.
Are you using the PDF button in the form which will always create a PDF of the loaded data, not of the modified one?
Or are you speaking of the attached PDF in the email plugin?

 

[joomlamate]

Hey, sorry for the confusion - I though it was clear from the discussion on the this thread. My bad for not clarifying it.
I am talking about attaching PDF with the email plugin when form is submitted.
All the issues are about that. Initially Fabrik wouldn't peak the right PDF template - when attaching PDF to the email but it would always use the Details template.
Then after updating from github it attaches a blank PDF. I need to re-save the form in order to get a proper PDF.

 

[troester]

I can't replicate.
I can add a new record or edit an existing one: the attached PDF uses the PDF-template and contains the new (or modified) data.

Did you try with an "original" Fabrik one (e.g. just copy details/tmpl/bootstrap to details/tmpl/bootstrapPDF and insert some additional text into default.php)?

 

[joomlamate]

Found the issue. It was related to the Details view ACL. After a lot of debugging I reached at that point.
Well actually, it wasn't the Email PDF attachment the one with the problem, but another custom Form plugin that was handling the PDF generation. So, when it was reaching at the Details View, the view was checking for access and denied the further processing.

This custom PDF plugin needed some extra updates and also set the Allow Local PDF setting in config.
Troester thanks a lot for your feedback.

 

[troester]

Thanks for the update, it may help others.

 

[joomlamate]

Just a few more concerns - as I am uploading the fixes on the online server - but still getting some sorts of issues - still related with the ACL of the details view.
I am checking the canViewDetails method of the list model:

it does:

if (in_array($_SERVER['REMOTE_ADDR'], $whitelist))
{
    $allowPDF = true;
}

but in fabrik config it says add the Local Server IP address. So what's the case here?
Isn't supposed we should allow the PDF for calls coming from the server itself?

 

[joomlamate]

Also on the online server, the email plugin - pdfAttachment method - the

$model->getListModel()->setLocalPdf();

isn't setting the $localPdf var to true. It is always set as false, so pdf view will never have the needed access to be rendered.
The same however works on my localhost.
I am not getting it why the above fails on the server.

 

[cheesegrits]

Just a few more concerns - as I am uploading the fixes on the online server - but still getting some sorts of issues - still related with the ACL of the details view.
I am checking the canViewDetails method of the list model:

it does:

if (in_array($_SERVER['REMOTE_ADDR'], $whitelist))
{
    $allowPDF = true;
}

but in fabrik config it says add the Local Server IP address. So what's the case here?
Isn't supposed we should allow the PDF for calls coming from the server itself?

As the tooltip for the "Allow Local PDF" explains, this is only relevant in certain situations, specifically the list download plugin, where we have to generate PDF views by making a CURL call from the server, to the server (because we're in a list view controller, we can't build a details view ... it's a J! MVC thing). In those case, the REMOTE_ADDR will be the server itself. And of course, as it's the server calling itself, not your browser calling the server, it won't have your session, so won't have your ACL access. Hence the need for the "Allow Local PDF".

The email plugin doesn't use that mechanism, it actually drives the details view controller from within the same session. I can't remember why I call setLocalPdf() in that code, I think it was for a different reason - I think I had a client who didn't allow his users details view, but still wanted to attach a PDF to a form view submission, so I do the setLocalPDF() to make sure the details view of the row being submitted can always be built as a PDF view.

As to why that isn't apparently working on your server, I don't know.

-- hugh

 

[joomlamate]

Hey Hugh!
Thanks for the follow-up.

The email plugin doesn't use that mechanism, it actually drives the details view controller from within the same session. I can't remember why I call setLocalPdf() in that code, I think it was for a different reason - I think I had a client who didn't allow his users details view, but still wanted to attach a PDF to a form view submission, so I do the setLocalPDF() to make sure the details view of the row being submitted can always be built as a PDF view.

Reading the code, that exactly seems to be the case with the setLocalPDF(). Only that it refuses to work on that server - It does work on my localhost though. It does so for both the email PDF attachment and my other PDF form plugin.
For now and my use-case I just had to hack the canViewDetails() and always set AllowPDF = true, when the document is PDF.

Regarding the REMOTE_ADDR, it now makes sense - although I didn't know that the Download List Plugin could generate PDFs. Can it be displayed as a button next to each row, so that it will force a new PDF download of the row's data, using the PDF template?

 

[cheesegrits]

Hey Hugh!

Regarding the REMOTE_ADDR, it now makes sense - although I didn't know that the Download List Plugin could generate PDFs. Can it be displayed as a button next to each row, so that it will force a new PDF download of the row's data, using the PDF template?

Yes. And it handles multiple rows. If you select multiple rows for download, with the PDF option enabled (it's a setting on the plugin), we create a ZIP file with the multiple PDF's in it.

I haven't tested it recently to make sure it adheres to the PDF template - I know we had to do some remedial work on other PDF mechanisms, after a change in J! a few releases ago, to get them to pick up the right template. I think I fixed the download plugin as well. If I didn't, it's a simple enough fix.

-- hugh