Support entities instead of nodes

FWIW, I've rolled up a simple patch to handle my use-case for filling a PDF from Commerce Coupon entity values. This patch is based on the 1.9 release of FillPDF, patched with the following:

• #1612270: Support Webform 4.x tokens - https://www.drupal.org/files/fillpdf_1612270_webform_4.patch
• #1633060: html entities appear in the PDF - https://www.drupal.org/files/html-entities-appear-in-pdf-7.x-2.x-1633060...
• #2408735: Using FillPDF from Drush or command line PHP script - https://www.drupal.org/files/issues/fillpdf-1.9-skip-drupal-goto-in-comm...

Apologies for this, it's what I'm running and testing for my site- the first two of these are in the -dev branch already, though, so hopefully this isn't too hard to apply. I've used the entities=<type>:<id> format for parsing the URI, and tried to mimic the support for multiple entities that fillpdf provides for nodes and webforms. In my case I only have one coupon at a time, however, so I haven't really tested this piece.

The key bits of code here are in fillpdf_parse_uri() to look for the 'entities' key in $_GET, and then extract entity type/id info from that, and in fillpdf_merge_pdf(), where I do an entity_load() and a token_replace() to replace entity-based tokens for each pdf field. Aside from that, there's just a small fix to the _fillpdf_admin_token_form() helper routine (introduced in the webform 4.x patch mentioned above) to lookup a list of entities and provide their tokens in the PDF Field editing interface.

Anyway, hopefully this gives an idea of the complexity of implementing entity support in FillPDF. It seems to me, from this experiment, that it should be possible to get a reasonably general solution working in the 2.x branch without much trouble.

Not spiderman, but in response to your question - installing Commerce Kickstart ( https://www.drupal.org/project/commerce_kickstart ) is probably a great starting point from the testing perspective, as B) Drupal Commerce is entity based, and a natural fit with the FillPDF module B) it's basically a 1 click install, so you won't get bogged down on that side of things.

Also, I've updated @spiderman's patch to be compatible with 7.x-1.10 , but discovered that it does't allow for both nodes and entities to be used to populate the contents of a PDF, when I have a moment I am going to investigate if that is an easy fix.

@spiderman if you can reroll your patch against a git branch instead of local copies. ATM I cant apply your patches to any of the branches in the repo. If you let me know which these apply to that would be helpful.

For now Im going to proceed on a slightly different path. Ill create a sub-module FillPDF Entity that will add integrations for Entities.

Ok so I went with a slightly different direction. I created a Sub-module called fillpdf_entity. This module relies on the core module, token, and entity_token to do its thing. It adds a menu tab onto the Entity settings page(s) that you can upload a pdf to. This is respective of both Entity Type and Bundle, so this could allow a very flexible setup.

At the moment I purposely have excluded Nodes as I did not want to create confusion, but I hope this can be the start of a rewrite for the module as things seem quite cluttered. I would like to have the module rewritten to fully support Entities(Rather than Direct DB schema) and Field API.

Update from my last patch file. This one adds a Rule action that will generate a Managed File from a entity.

I've re-rolled my patch from the above comment #1526452-2: Support entities instead of nodes against the 7.x-1.10 release of FillPDF which incorporates 2 of the related patches needed then, but still requires the (now updated) patch from this issue:

* #2408735: Using FillPDF from Drush or command line PHP script

This was a pretty straightforward port up to the latest version of the module, and still takes the original approach, which is the same as the new Ubercart compatibility code I see in the 1.10 release. Unfortunately this is the easiest way forward for our site right now, though I'd love to see a proper backport of the d8 version of the module, of course :)

Thanks.

Updated patch in #13 to work in 7.x-1.12 . Unfortunately it does not cleanly apply to the latest 7.x-2.x dev branch due to API changes, and I just don't have the time at the moment to work on it further.

7.x-2.x has been withdrawn. Only 7.x-1.x is maintained for Drupal 7.

Thanks, sorry for my confusion, lol. That does make it a good bit easier.

Here's a new patch, to fix the missing arg in #19.

Here's a newer patch. I found out that token replacements were not working on the filenames for entities, this addresses that.

Reading the patch, it looks fine. I noticed a couple of coding standards issues; please run a check on it. I would like to see a review from someone who is using this. It would be great for the patch to include some tests.

Hi Liam,

I'm trying to use those patches for filling PDFs from entityforms, in my case embeded on a node from paragraphs.

I've patched the module first with "cmcintosh" proposal and after restarted again patching with last "jlamp" proposal. Both look equally interesting but what I can't manage to understand is how the URL for click-and-build-pdf buttons should be constructed. Anyone could explain that?, because I can't get how to tell which kind of entity I want to open and which parameter name i should use for the corresponding ID, something like:

• /fillpdf?fid=1794&type=entityform&id=10 ??

Thanks in advance!

I think you want something more like: /fillpdf?fid=1794&entity=10

Thanks for answer Liam, but that way I've got:

Notice: Undefined offset: 1 in /Volumes/Data/Sites/Compac/compac-corporativo.local/sites/all/modules/contrib/fillpdf/fillpdf.module on line 783

Fatal error: Class name must be a valid object or a string in /Volumes/Data/Sites/Compac/compac-corporativo.local/includes/common.inc on line 8051

on that code:

  // Entities
  $entity_ids = array();
  if (module_exists('entity') && is_array($entities)) {
    foreach ($entities as $e) {
      $parts = explode(':', $e);
      $type = $parts[0];
      $id = $parts[1]; (<-----   here line 783)
      $entity_ids += array( $type => array());
      $entity_ids[$type][] = $id;
      }
    $context['entities'] = $entity_ids;
  }

Now I realize that I don't know if you are telling me that this is the path that already works or if you are just making a proposal...

In any case, regarding your URL /fillpdf?fid=1794&entity=10, how is the system capable to know which entity are we requiring with that "entity=10" ID ??

I got that from quickly reading the patch. Search in the patch for "query_string".

Ok, I've used "/fillpdf?fid=1794&entities=10" according the code part that you mention and now no error pops up, and even it downloads a PDF file, but empty... fields are not filled...

So, I insist, how does FillPDF know that we are requiring data from an entityform and not from other kind of entity? and bundle?

I don't know. I didn't write the patch. It should be possible to determine my reading the code.

Well, I can't see on the #22 patch where do we select the type of entity and bundle...

It has been a bit since i looked at this, I will reread the code and provide some suggestions how to use it.

I just read #27 again. The snippet of code looks like it is identifying entities by "type:id", splitting on the colon to get $type and $id. Give that a try.

It should have better error handling. When a colon is not provided, it should at least behave like other not-found situations.

Hmmm, thanks Liam, I'll try that.

I've tried but again I'm not sure about which query it's needed: "?fid=1794&entities=entityform:90" ?? or "?fid=1794&entities:90" ?? I've tried both without any success.

I would try ?fid=1794&entity=entityform:90.

Wow! it works!! Thanks :-)))))))

This line:
$parts = explode(':', $e);
Should be:
$parts = explode(':', $e, 2);

This line:
$id = $parts[1];
Should be:
$id = isset($parts[1]) ? (int) $parts[1] : NULL;

An error should be raised later when $id is null.

Hi. I had to spend my time on other projects and finally I'm back to finnish that. I'm fillng properly PDF forms with values from the entity form, except for select fields, checkboxes and email fields. Select fields or checkbox are not reflected on the form, and email field is printed with "a mailto" tags. Is there a way to call those values?

To set things like checkboxes, the component value needs to be set to the value that the PDF is expecting. It could be something like "On". You can use pdftk dump_data_fields to get these values.

I needed this feature and I am glad I have found this page. I first tried cmcintosh's solution but couldn't apply second patch #10 after applying #8 successfully.
Solution from #13 works great, but after applying that patch (fillpdf-entity-support-1526452-2.patch) to latest 1.14 version, I now have problem that tokens inside Title field for generated PDF, are stripped and ignored e.g.

[entityform:created:medium].pdf

becomes

entityformcreatedmedium.pdf

With every other token happens the same.

Can someone help me with this problem? Thank you.

@wizonesolutions I guess I jumped to conclusion on this one. Even without the mentioned patch (I removed it) I am having the same situation that tokens are not working only for pdf file name title field. Behavior is the same as I already described. I have already looked at fillpdf.module at the few important functions but still haven't found the cause.

Please make a new ticket for the token issue.

@wizonesolutions I will first test on clean Drupal install (the same version of core and module) to see if token replacement works as intended and if it works, I will then add one by one of the other modules I use that could probably make problem.

@Liam Morland Thank you. If I encounter the problem again I will open a new ticket.

What I have found is that I have only functional version that works with Entityform by using fillpdf 1.10 with spiderman's patch. Other patches e.g. for fillpdf 1.12 even though they apply cleanly produce empty pdf fields. The problem with all of the patches is the same considering pdf generated file title token replacement - it doesn't work. Within spiderman's patch there is custom token replacement and I suppose it messes with token replecement for title field or maybe it disables it.
I was trying to manually re-implement entity support with current 1.14 dev but still haven't worked out valid solution. Until then I will use version 1.10, but that version also has title token replacement problem, and doesn't load all of the tokens e.g. date etc.

@wizonesolutions Do you maybe have time to deal with implementation of entity support? FillPDF is a great module and entityform stands side by side with webform as form solution, and I think it should be great if fillpdf for Drupal 7 would support entities in general by default. You have greater knowledge of the fillpdf code, and patch for 1.12 is almost compatible with current 1.14 dev (I don't know why it fails to produce token replacement yet).

I also think that path format that uses &entities=entity_type:nid is great but it could also be made like &entities[type]=entityform&entities[nid]=6 to be compatible with the rest of the solutions.

Thank you.

@wizonesolutions That is great news that you are wiling to support this fully. I noticed that patch #22 didn't implement rest of the functionalities like to check for permissions etc.
Considering path format I agree with you that it would be best to stick with uniform path pattern like for the rest of the content types.

I am available and willing to test your patch when you complete it. Thank you.

Just to add if it matters. Token browse loading is very slow with spiderman's patch for FillPDF v1.10. With later version it loads fast like on any Drupal page that supports tokens and loads complete list of tokens.

Hello. Thank you for the patch. I read through the code to see the changes. Then I have uninstalled the previous version 1.10 that worked well with entityform except for the title token problem, and installed current dev patched with this patch.

On the Edit PDF page I got new "Default Entity Type" field and chose "Entityform Submissions" and didn't setup "Default Node ID" because edit link for my entityform form is string. I don't know how to get NID for entityform. Also "Deafult Node ID" field has some character size limit.

Form Info
Form ID: [$fid]. Populate this form with node IDs, such as /fillpdf?fid=113&nid=10

Where used to be FID as integer now stands [$fid], but hovering over above link "See which fields are which in this PDF." shows the real FID, and it is also visible inside here /fillpdf?fid=113&nid=10

I called pdf creation like this /fillpdf?fid=113&entity_ids[]=entityform:99 and got properly filled pdf file that has filename generated from tokens.

So, for now I can say it works. I will test it further. Also permissions are checked. Link becomes /fillpdf?fid=113&entity_ids[]=node:99 so entityform gets changed to node, and entering the new link again gives access denied.

Thank you very much for taking care of this issue, I think it was generally important.

I usually wait two weeks after the last issue is marked "fixed" before issuing a release candidate and then I wait until the -rc is two weeks old with no release-blocker issues having been identified before making the full release.

No doubt, what I suggest is conservative. I don't mind if the -rc goes out sooner than the two weeks. I do think it is important for the -rc to be two weeks old before a full release.

@wizonesolutions You are right, it was my mistake it is not "Default Node ID", but "Default Entity ID" and I have Entity Token enabled.

As I used to have version 1.10 until this patch, in that version FID was printed as integer and it was convenient for admin to just go to edit page and directly see FID to be used in link creation. Then later that line wasn't wrapped within t() function. I suggest that you add double quotes on the line 422 of the current dev like:

'#description' => t("Form ID: [$fid]. Populate this form with node IDs, such as @example<br>", array('@example' => $entity_mode ? "/fillpdf?fid=$fid&nid=10" : "/fillpdf?fid=$fid&entity_id=node:10")),

so that FID is again visible on Form Info after "Form ID:".

Also help text suggest to populate only with node IDs but it actually needs to be populated with entity type (if default not chosen) and NIDs. I have also tested pdf creation when default entity type is not chosen and also not given within link and then I got access denied on the page. Both creation with default entity type chosen and not given inside link, and if it isn't chosen and given inside link works properly.

Other than these comments I don't have any bugs to report. Token replacement works fine both in title and pdf fields. Token browser loads faster than with 1.10 version and has all available tokens in the list.

One more time, thank you for supporting entities within this great module.

I don't know if it has any connection, but I tried to enable this patched version on another site with drush and got this error:

Parse error: syntax error, unexpected '[' in /sites/all/modules/fillpdf/fillpdf.module on line 1438
Drush command terminated abnormally due to an unrecoverable error.                                                                                                       [error] Error: syntax error, unexpected '[' in /sites/all/modules/fillpdf/fillpdf.module, line 1438

$data = base64_decode(drupal_json_decode($result->data)['pdf']);

It's the same whether I use php 5.6 or 7.1.

Enabling module from UI goes without complaint. I am using Drush Version : 7.0-dev

Considering drush error sorry, it was problem with drush's own php version. I set it up like this (inside ~/.bashrc) and everything works fine:

alias drush='/opt/php71/bin/php /home/user/drush/drush.php'

You can delete these comments because they are not connected to the issue. Sorry.

This change has caused #3060718: Webform default_nid does not work when entity_token is enabled. I would appreciate a review of the patch there.