Phenix 1.6.X Cannot Print a Deliver Note

[Bitfarmer]

I wonder if anyone else has suffered from this bug. Everything else works normally but if you try to print a delivery note for an order, you get a Prestashop Exception always

 #1 ($order_invoice) must be of type OrderInvoice,
 	Order given, called in /var/www/sites/phenix/classes/pdf/PDF.php on line 161 and
 	defined in /var/www/sites/phenix/classes/pdf/HTMLTemplateDeliverySlip.php:43

Stack trace:
 #0 /var/www/sites/phenix/classes/pdf/PDF.php(161): HTMLTemplateDeliverySlipCore->__construct()
 #1 /var/www/sites/phenix/classes/pdf/PDF.php(86): PDFCore->getTemplateObject()
 #2 /var/www/sites/phenix/controllers/admin/AdminPdfController.php(493): PDFCore->render()
 #3 /var/www/sites/phenix/controllers/admin/AdminPdfController.php(451): AdminPdfControllerCore->generatePDF()
 #4 /var/www/sites/phenix/controllers/admin/AdminPdfController.php(109): AdminPdfControllerCore->generateDeliverySlipPDFByIdOrder()
 #5 /var/www/sites/phenix/classes/controller/AdminController.php(1160): AdminPdfControllerCore->processGenerateDeliverySlipPDF()
 #6 /var/www/sites/phenix/controllers/admin/AdminPdfController.php(41): AdminControllerCore->postProcess()
 #7 /var/www/sites/phenix/classes/controller/Controller.php(338): AdminPdfControllerCore->postProcess()
 #8 /var/www/sites/phenix/classes/Dispatcher.php(427): ControllerCore->run()
 #9 /var/www/sites/phenix/storeadmin/index.php(81): DispatcherCore->dispatch()
 #10 {main} thrown in /var/www/sites/phenix/classes/pdf/HTMLTemplateDeliverySlip.php on line 43

I have tried for hours to track this to no avail. Any pointers or help would be greatly appreciated. It is a Type error but if so, how did it ever work! I have been thinking that it must be some change in the database possibly from the data originally coming from OSCommerce, Prestashop, and finally to Phenix Suite, but I can't any changes that alter field definitions in the tables.

[doekia]

@Bitfarmer bugger, once again legacy code bites us. The prototype of the function that was solely an information, gets to be be controlled. The prototype of the function here SHOULD NOT pretend the value is of type x when the code is ready for type x or y. Let's the proto to ignore type.

Change the proto that says
public function __construct(OrderInvoice $order_invoice, $smarty, $bulk_mode = false)
to
public function __construct($order_invoice, $smarty, $bulk_mode = false)

Further code will inclus the fix.

[Bitfarmer]

I am delighted to confirm that the problem is fixed. Thank you very much.

Maybe it doesn't matter but I did notice the same structure in HTMLTemplateInvoice.php as was in HTMLTemplateDeliverySlip.php

grep -r '__construct(OrderInvoice $order_invoice'

classes/pdf/HTMLTemplateInvoice.php:    public function __construct(OrderInvoice $order_invoice, $smarty, $bulk_mode = false)

[eolia]

No, the HtmlTemplateInvoice() class always expects an object of type OrderInvoice, so there will never be a problem.

The HtmlTemplateDeliverySlip() class accepts both types of objects (Order or OrderInvoice). This historical code error only triggered a warning up to PHP 7.2, but beyond that, it's a fatal error.