I'm pretty sure Fill PDF used to work with multiple tokens in a single mapping. It seems like this changed at some point. Need to check in 6.x-1.x and 7.x-1.x and fix the issue if it exists. It may have to do with token_replace().

Comments

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

Tagging.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented
Version: 7.x-1.x-dev » 7.x-2.x-dev
Issue tags: +fillpdf2

Should test this while working on new version.

dafeder’s picture

dafeder
he/him
Location Philadelphia, PA
commented

It seems to work if I comment out these lines (fillpdf.module lines 343-345)

          if ($token && $token != $obj->value) {
            break;
          }

SO far no ill effects. Can't say I totally understand what this was meant to do in the first place, is this an acceptable solution

dafeder’s picture

dafeder
he/him
Location Philadelphia, PA
commented

My bad, this messes up multiple nids. Looking for another solution.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

Yeah, I was just about to say the same thing about the multiple NIDs. I forget if we currently loop over each node/submission separately (we probably do) or why exactly we fixed it that way. The actual code is checking, if I'm not mistaken, that the replaced token is not the same as the token pattern itself. You can probably git log -p fillpdf.module and /$token in the mode it goes into to search for changes to that code, and then check what the commit message was to get some context.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

Yeah, I was just about to say the same thing about the multiple NIDs. I forget if we currently loop over each node/submission separately (we probably do) or why exactly we fixed it that way. The actual code is checking, if I'm not mistaken, that the replaced token is not the same as the token pattern itself. You can probably git log -p fillpdf.module and /$token in the mode it goes into to search for changes to that code, and then check what the commit message was to get some context.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

Yeah, I was just about to say the same thing about the multiple NIDs. I forget if we currently loop over each node/submission separately (we probably do) or why exactly we fixed it that way. The actual code is checking, if I'm not mistaken, that the replaced token is not the same as the token pattern itself. You can probably git log -p fillpdf.module and /$token in the mode it goes into to search for changes to that code, and then check what the commit message was to get some context.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

Yeah, I was just about to say the same thing about the multiple NIDs. I forget if we currently loop over each node/submission separately (we probably do) or why exactly we fixed it that way. The actual code is checking, if I'm not mistaken, that the replaced token is not the same as the token pattern itself. You can probably git log -p fillpdf.module and / $token in the less mode it goes into to search for changes to that code, and then check what the commit message was to get some context.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented
Version: 7.x-2.x-dev » 7.x-1.x-dev
Issue summary: View changes
Issue tags: -fillpdf2
wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented
Status: Active » Closed (won't fix)

Will keep this in mind, but cleaning up issue queue for now.