Each time there's a:

    require_once('fpdi.php');

in this module (for example when clicking "submit" on a new node) I get:

"Fatal error: Class 'FPDF' not found in /Users/webchick/Sites/buzzy/sites/all/modules/pdfstamper/lib/FPDF_TPL/fpdf_tpl.php on line 20"

This seems to be because the latest verison of fpdi.php sub-classes off of fpdf.php, which isn't loaded yet.

By explicitly adding require_once('fpdf.php'); before each of these, it seems to work.

Here's a patch.

CommentFileSizeAuthor
pdfstamper-fix-fatal-error.patch1.77 KBwebchick

Comments

yasheshb’s picture

yasheshb commented
Assigned: Unassigned » yasheshb

hi.

the problem is actually in fpdf_tpl.php. it's documented in the README_EXTERNAL_LIB_PLUGIN.txt

NOTE: In some versions of the file fpdf_tpl.php the line for require_once is missing, you'd need to add it manually.
To check it do
$ head -21 fpdf_tpl.php

if you see something like -

//  limitations under the License.
//
class FPDF_TPL extends FPDF {
    /**

please add the line "require_once("fpdf.php");" before class declaration so it now looks like
require_once("fpdf.php");
class FPDF_TPL extends FPDF {

Here's a diff of version 1.1.1, 1.1.2 of FPDF_TPL
$ diff fpdf_tpl-1.1.1.php fpdf_tpl-1.1.2.php | less
3c3
< //  FPDF_TPL - Version 1.1.1
---
> //  FPDF_TPL - Version 1.1.2
5c5
< //    Copyright 2004-2007 Setasign - Jan Slabon
---
> //    Copyright 2004-2008 Setasign - Jan Slabon
20,21d19
< require_once("fpdf.php");

but the above patch supplied would fix the need for having a line hacked in fpdf_tpl.php. thoughts on what's the best way forward ?
i.e. either add a line to fpdf_tpl.php or add the require_once "fpdf.php" to the module code inspite of the module not using it directly
(it uses only FPDI class).

rgd.

yashesh

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Hm. Yeah, I guess I did read that. For some reason it didn't register that that would be causing this problem. Maybe a sterner warning like "THIS MODULE WILL EXPLODE IN YOUR FACE IF YOU DON'T DO THIS" ;) would help. ;)

Personally, though, I think hacking third-party libraries should be avoided, especially when the fix is just a couple of one-liners. If future versions of these libraries come out for security reasons or whatever, we have to re-apply those hacks over and over. Same reason we tell people not to hack Drupal core and contributed modules.

I realize it's slightly more annoying for you as a module author to write two lines of code to import the libraries, but I think it's much better for the users of this module if this is handled transparently to them.

venuslabs’s picture

venuslabs commented

yeah. i subscribe to your point of view that for the end user it's beneficial to add the require_once for fpdf.php. i've applied the patch and modified the README file appropriately.

[venuslabs@bfc33 pdfstamper]$ cvs commit -m "#934302 by webchick: Added require_once for fpdf.php in pdfstamper.module and changed the External Library README file"
cvs commit: Examining .
cvs commit: Examining js
cvs commit: Examining lib
/cvs/drupal-contrib/contributions/modules/pdfstamper/README_EXTERNAL_LIB_PLUGIN.txt,v  <--  README_EXTERNAL_LIB_PLUGIN.txt
new revision: 1.3; previous revision: 1.2
/cvs/drupal-contrib/contributions/modules/pdfstamper/pdfstamper.module,v  <--  pdfstamper.module
new revision: 1.3; previous revision: 1.2
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
[venuslabs@bfc33 pdfstamper]$ cvs status

i'm not sure when it'll show up on the module page though - http://drupal.org/project/pdfstamper

thx.

yash

junedkazi’s picture

junedkazi commented

The new changes will not show up if you don't enable the dev version or create a new version by adding a new tag to it.