Google or forum search on "Fatal error: Call to a member function add_current_page() on a non-object". This is not an error specific to this contribution.
You'll find lots of fixes e.g. http://www.oscommerce.com/forums/index.php?showtopic=28405
Jonathan,
This is caused by an extra whitespace character after the closing ?> php tag in includes/languages/english/tracking_module.php
This is a common problem - edit the file above and make sure there are no characters, spaces or newlines after the closing ?>
This is nothing to do with the URL changes. The International page return contains invalid HTML which chokes the script.
A fix for this is here - post #148:
I should have added this to the last updated module but forgot. Sorry!
Martyn,
The Royal Mail description text is not part of the tracking module - this is the text for a shipping module you have installed.
Have a look in
catalog/includes/languages/english/modules/shipping/whatever_shipping_you_use.php
Would this other contribution happen to be PDF Customer Invoice by any chance?
Chris
Hi Rolf,
I'm assuming the error message is occurring when you try and add the tracking ID on admin/orders.php?
If so, this will not be affected by the change in tracking url (although this may break the module in other ways!)
Doubtful your PHP version will have affected anything.
Most likely cause:
1. Swisspost have different format tracking IDs - is the ID causing the error the same format as those that were working?
2. You've made changes to admin/orders.php (?)
HTH
Chris
Now I've given this more than 10 seconds thought, there was an obvious step missing from my last post.
The file pdfinvoice.php has security checks in place to make sure that either:
1) The customer is logged in and can therefore only view invoices belonging to their customer id
or
2) The admin add-on is place and a security bypass hash is sent to pdfinvoice.php to bypass the requirement in 1)
This is where dealing with a payment module that uses a callback (eg PayPal, Chronopay etc) causes problems.
Harald's (hpdl) offical standard PayPal module replaces the checkout_process.php flow and pre-saves the order using code in the payment module. The ipn.php callback then updates the order status.
For this module, adding the PDF code to the payment module email block should work as the customer is logged in.
If you're using a different PayPal IPN that moves the email sending to the callback function, then the customer will not be logged in. In this case, I suppose the easiest solution would be to set the passthru id in the IPN page, e.g.
$HTTP_GET_VARS['passthruID'] = "your secrethashhere";
Note: all the above is based on my limited knowledge of the PayPal modules floating around the contribution area..
HTH
Chris
Hi,
I don't use PayPal IPN but you're right in what you say. You need to duplicate the PDF code in ipn.php
I *think* from a brief look (and I haven't tested this), that you'll need to change the reference
$HTTP_GET_VARS['order_id'] = $insert_id;
to
$HTTP_GET_VARS['order_id'] = $HTTP_POST_VARS['invoice'];
to ensure the order_id gets passed to pdfinvoice.php
HTH
You can't have any html or html entities in your PDF.
If your payment module is inserting these characters, edit pdfinvoice.php
FIND
$pdf->MultiCell(94, 6, $order->totals[$i]['title'] . ' ' . $order->totals[$i]['text'], 0, 'R');
and add the tep_html_entity_decode function around $order->totals[$i]['title'] and $order->totals[$i]['text']
e.g
$pdf->MultiCell(94, 6, tep_html_entity_decode($order->totals[$i]['title']) . ' ' . tep_html_entity_decode($order->totals[$i]['text']), 0, 'R');
HTH
David,
Hardcoding, while not ideal, should work fine. Are you sure you're not getting browser caching issues? I occasionally have problems trying to get changes to "stick" when regenerating the PDF. Often clearing the browser cache or a CTRL +F5 fixes this.
Rather than hardcode, try adding a constructor to the PDF class (this is something I need to add as a config option as the A4/letter issue has been discussed before).
EDIT pdfinvoice.php
FIND:
class PDF extends FPDF
{
and ADD immediately after:
function PDF($orientation='P',$unit='mm',$format='letter'){
parent::FPDF($orientation,$unit,$format);
}
I've not tested this but it should create a FPDF object with the canvas set to letter, not A4 size
HTH
Chris
To confirm, did you have Google Checkout (GCO) installed with v1.3 and working or have you upgraded to v1.4 and installed GCO simultaneously?
If my memory serves me, there was an issue with GCO and the tracking module but this was on an install on an popular OSC fork.
I don't use GCO so can't comment on this.
HTH
Chris