Jump to content
Sign in to follow this  
dynamoeffects

PayPal WPP Direct Payments & Express Checkout Support

Recommended Posts

Michelle,

The error message says that php is trying to access something from a database. This has absolutely nothing to do with the PayPal WPP module itself. Do you have a table called "sources" in your database? It is not part of a standard osC shop.

 

I can only guess where the problem might lie, but it may have something to do with step 11 of the installation instructions, as this is where the code to handle "action=express_checkout" is added. Either that, or it is an interaction with the contribution that adds the "sources" table, which sounds like some sort of ad tracking tool. What other contributions have you installed in your shop?

 

--Glen

 

 

Yes I did install the ad tracking module to this website

Share this post


Link to post
Share on other sites
Yes I did install the ad tracking module to this website

 

I do have a table in my php database called source can I add anything to it? Table structure for table `sources`

--

 

CREATE TABLE IF NOT EXISTS `sources` (

`sources_id` int(11) NOT NULL auto_increment,

`sources_name` varchar(64) NOT NULL,

PRIMARY KEY (`sources_id`),

KEY `IDX_SOURCES_NAME` (`sources_name`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=8 ;

 

--

-- Dumping data for table `sources`

--

 

INSERT INTO `sources` (`sources_id`, `sources_name`) VALUES

(1, 'Google'),

(2, 'Yahoo!'),

(3, 'AOL'),

(4, 'MSN'),

(5, 'osCommerce'),

Edited by lgayle

Share this post


Link to post
Share on other sites
Yes I did install the ad tracking module to this website

 

Which ad tracking module? Please provide a link to it, or at least the name of it in the contributions area.

 

--Glen

Share this post


Link to post
Share on other sites

We are using Paypal pro for express checkout.

For some reason instead of Paypal CERTIFICATE we would like to use Paypal SIGNATURE.

 

Any way to do this.

 

Thanks!!

Satish


Ask/Skype for Free osCommerce value addon/SEO suggestion tips for your site.

 

Check My About US For who am I and what My company does.

Share this post


Link to post
Share on other sites
We are using Paypal pro for express checkout.

For some reason instead of Paypal CERTIFICATE we would like to use Paypal SIGNATURE.

 

Any way to do this.

 

Thanks!!

Satish

Satish,

It could be done, with some changes, but the module doesn't support it at the present time. I added API certificate support to another payment module that only supported API signature once, and it took an hour or two of coding and testing. The other direction should be about the same level of difficulty. It has been on the "to do" list for a while, but hasn't been a high priority.

 

The reason this module only supports API certificate is that was the only option available at the time the module was written. API signatures weren't introduced until the NVP API was released, then back-ported to the SOAP API.

 

--Glen

Share this post


Link to post
Share on other sites

I recently integrated the PayPal Website Payments Pro v1.0.4 contribution into an osCommerce 2.2 rc2a site and thought I’d share my experiences.

 

I did a lot of testing and found a number issues which needed fixing before the site could go live. The site primarily sells virtual products and uses PayPal UK which might explain why I had problems.

 

Some changes are bug fixes and others are enhancements, if other users are experiencing the same problems then you might find these changes useful or perhaps they can be improved upon and added to the contribution in a future version?

 

I also wanted to list some issues I found which I was not able to fix. It would be good to capture these in the TODO list in case someone else fancies a go at fixing them.

 

The site has been running reliably for a number of months with both Direct and Express Payments working great!

 

I’m in the process of integrating v1.0.5 and v1.0.6 into the site and so far to my knowledge these same issues exist, will post a future update on this.

 

Thanks for all the time and effort made by all the osCommerce contributors!

 

Kind regards

Scott

 

Bugfix/Enhancement:

 

1. If a shopping cart contains only virtual products we still need to pass a Shipping Address to PayPal otherwise the Billing Address will be returned as blank to osCommerce when using Express Checkout with Address Override or for using Automatic Account Creation.

 

This happens because PayPal never returns any address if a shipping address is not provided in the ExpessCheckout request.

 

Modify catalog/includes/modules/payment/paypal_wpp.php

 

FIND these lines of code around line 592:

 

      /* 
       Check that the word "virtual" is in the content_type property instead 
       of checking that it *is* set to "virtual" because there's another
       popular contribution that modifies the actual field.
      */

     if (strpos($order->content_type,'virtual') !== false) {
       $order_info['PAYPAL_NO_SHIPPING'] = '1';
     } else {
       $order_info['PAYPAL_NO_SHIPPING'] = '0';
     }
    /* If the address in the database should be used, only set 
        PAYPAL_ADDRESS_OVERRIDE to '1' if the user is logged in
        and this is a physical purchase.  If we find out later
        that they have an account, the address will be switched
        once they return.
      */
     if (MODULE_PAYMENT_PAYPAL_EC_ADDRESS_OVERRIDE == 'Store' && 
         $order_info['PAYPAL_NO_SHIPPING'] == '0' && 
         tep_session_is_registered('customer_first_name') && 
         tep_session_is_registered('customer_id') && 
         $order->delivery['street_address'] != '' && 
         $order->delivery['state'] != '') 
     {

 

REPLACE with this code below:

 

      $order_info['PAYPAL_NO_SHIPPING'] = '0';

     /* If the address in the database should be used, only set 
        PAYPAL_ADDRESS_OVERRIDE to '1' if the user is logged in
        and this is a physical purchase.  If we find out later
        that they have an account, the address will be switched
        once they return.
      */
     if (MODULE_PAYMENT_PAYPAL_EC_ADDRESS_OVERRIDE == 'Store' && 
         strpos($order->content_type,'virtual') === false &&
         tep_session_is_registered('customer_first_name') && 
         tep_session_is_registered('customer_id') && 
         $order->delivery['street_address'] != '' && 
         $order->delivery['state'] != '') 
     {

 

2. Allow customers to enter spaces in credit cards numbers. Some customers type the number as it appears on the card with spaces between the 4 digit blocks. I didn’t want the customer to have to enter the details again and risk losing a sale.

 

Modify catalog/includes/modules/payment/paypal_wpp.php

 

FIND these lines of code around line 193:

 

} else {
  require_once(DIR_FS_CATALOG . DIR_WS_CLASSES . 'cc_validation.php');

 

and REPLACE with this code below:

 

} else {	
  $_POST['paypalwpp_cc_number'] = preg_replace('/[^0-9]/i', '', $_POST['paypalwpp_cc_number']);
  require_once(DIR_FS_CATALOG . DIR_WS_CLASSES . 'cc_validation.php');

 

3. Allow Direct Payment using the customers selected currency (assuming this currency is supported by PayPal). This is instead of forcing the checkout into a default currency.

 

I think it’s better if the sales invoice and the PayPal Receipt or Credit Card statement are in the same currency to avoid discrepancies in prices due to exchange rates.

 

Ideally the Module Admin should also be updated to make this configurable via the “Transaction Currency”. At the moment it’s hardcoded to always use the stores currency where possible.

 

Modify catalog/includes/modules/payment/paypal_wpp.php

 

REPLACE wpp_get_currency function with the code below:

 

function wpp_get_currency() {
     global $currency;

     switch ($currency) {
       case 'AUD':
       case 'CAD':
       case 'EUR':
       case 'GBP':
       case 'JPY':
       case 'USD':
         $my_currency = $currency; 
         break;
       default:
         $my_currency = MODULE_PAYMENT_PAYPAL_DP_CURRENCY;
         break;
     }

     return $my_currency;
   }

 

ToDo:

 

1. Order Total Discrepancy = $0.00 sometimes appears in the invoices when a customer purchases multiple products. I have been unable to understand why this is happening, the code appears to be checking for this condition.

 

2. Refunds fail for Express Checkout transactions which are not in the default currency. I had a look at fixing this but it is not straight forward. The refund amount returned from PayPal is in the checkout currency but osCommerce needs to use the default currency, if the exchange rates change then it could result in the order total not being set to zero.

 

3. Changing the Order Status when Refunding is not updating the order_status in TABLE_ORDERS, this remains the same even though TABLE_ORDERS_STATUS_HISTORY has been updated. This can be manually updated via the order details page. I was not sure if this was intentional but would be a useful improvement in a future version as this is the status which is displayed to the customer on the account_history_info page.

Share this post


Link to post
Share on other sites
Heh, no worries, as was mine.

 

 

 

 

 

That's the behavior that PayPal suggests for EC users who want to change their address. I see what you mean about leaving it more in-house, though.

 

 

 

More or less. SteveDallas showed me that there are four or five countries that should have a blank state field, so I've added his fix for that. Otherwise, as long as the customer fills in their address information correctly, it should work. I would like to hear some results (successful and unsuccessful)!

 

 

 

It's deleted near the end of the checkout_success.php page after all of the order entry queries have finished.

 

 

Hey Glen and Brian,

 

Thanks so much for supporting this contrib.

 

I know this quote is from a while back, but it looks like problems with the shipping address override have been around a long time. I'm wondering if this old post is saying it's supposed to work in such a way that the shipping address can't be changed once the customer returns from PayPal.

 

Or, has the issue actually been fixed and I've just got a problem with my install? Basically, if I set the override to store, PayPal gets new shipping name but old address. If I set the override to PayPal, I get a new address but the customers name.

 

Thanks again for your continued support!

 

 

Art

Edited by Escaping

Share this post


Link to post
Share on other sites
Hey Glen and Brian,

 

Thanks so much for supporting this contrib.

 

I know this quote is from a while back, but it looks like problems with the shipping address override have been around a long time. I'm wondering if this old post is saying it's supposed to work in such a way that the shipping address can't be changed once the customer returns from PayPal.

 

Or, has the issue actually been fixed and I've just got a problem with my install? Basically, if I set the override to store, PayPal gets new shipping name but old address. If I set the override to PayPal, I get a new address but the customers name.

 

Thanks again for your continued support!

 

 

Art

 

Art,

Yeah, that is a blast from the past. I'm of the opinion that one should never set Shipping Address Override to "store", at least, not as it is implemented in the WPP module. That option was added to the Express Checkout API to handle the case of a customer choosing PayPal as a payment method on the payment options page, after signing in and providing a shipping address, not the case where a customer clicks the EC "Check Out with PayPal" button prior to logging in.

 

Case 1: (Customer signs in to shop, ignoring the big yellow PayPal button)

a. Customer clicks usual Checkout button, then logs in.

b. Customer enters shipping address and method.

c. Customer selects PayPal as payment method.

d. Customer confirms details.

e. Shop sends customer to PayPal to enter password and confirm details. Since customer already provided shipping address in step (B), set Address Override to True and send shipping address to PayPal to prevent customer from changing shipping address, and possibly requiring a new shipping calculation.

 

Case 2: (Customer clicks EC button)

a. Send customer to PayPal to log in. Customer will select shipping address and payment source.

b. [shop collects data returned from PayPal.]

c. Customer selects shipping method.

d. If shop accepts coupons, allow customer to enter a coupon or voucher on payment page, otherwise skip this step.

e. Present confirmation page. Customer confirms details.

f. [send final totals to PayPal to complete transaction.]

 

Case 1 has the shop telling PayPal the shipping address, while Case 2 accepts the shipping address customer selected while at PayPal. We don't handle Case 1 in WPP, but we have the optional EC button on the payment options page.

 

I don't think that the customer using Express Checkout should be able to change the address in the shop after returning from PayPal. This would void the determination as to whether the address is confirmed and eligible for Seller Protection. It would also require recalculation of shipping charges, and possibly taxes, depending on the new address.

 

PayPal has added some callback functions for Express Checkout that would allow more streamlining of the checkout process, so the customer could select a shipping method while on the PayPal page, but this is not currently supported in the WPP module. I haven't examined whether it can be done using the osC shipping module architecture, but I have thought about examining this as a future direction.

 

--Glen

Share this post


Link to post
Share on other sites
Art,

Yeah, that is a blast from the past. I'm of the opinion that one should never set Shipping Address Override to "store", at least, not as it is implemented in the WPP module. That option was added to the Express Checkout API to handle the case of a customer choosing PayPal as a payment method on the payment options page, after signing in and providing a shipping address, not the case where a customer clicks the EC "Check Out with PayPal" button prior to logging in.

 

Case 1: (Customer signs in to shop, ignoring the big yellow PayPal button)

a. Customer clicks usual Checkout button, then logs in.

b. Customer enters shipping address and method.

c. Customer selects PayPal as payment method.

d. Customer confirms details.

e. Shop sends customer to PayPal to enter password and confirm details. Since customer already provided shipping address in step (B), set Address Override to True and send shipping address to PayPal to prevent customer from changing shipping address, and possibly requiring a new shipping calculation.

 

Case 2: (Customer clicks EC button)

a. Send customer to PayPal to log in. Customer will select shipping address and payment source.

b. [shop collects data returned from PayPal.]

c. Customer selects shipping method.

d. If shop accepts coupons, allow customer to enter a coupon or voucher on payment page, otherwise skip this step.

e. Present confirmation page. Customer confirms details.

f. [send final totals to PayPal to complete transaction.]

 

Case 1 has the shop telling PayPal the shipping address, while Case 2 accepts the shipping address customer selected while at PayPal. We don't handle Case 1 in WPP, but we have the optional EC button on the payment options page.

 

I don't think that the customer using Express Checkout should be able to change the address in the shop after returning from PayPal. This would void the determination as to whether the address is confirmed and eligible for Seller Protection. It would also require recalculation of shipping charges, and possibly taxes, depending on the new address.

 

PayPal has added some callback functions for Express Checkout that would allow more streamlining of the checkout process, so the customer could select a shipping method while on the PayPal page, but this is not currently supported in the WPP module. I haven't examined whether it can be done using the osC shipping module architecture, but I have thought about examining this as a future direction.

 

--Glen

 

Hey Glen,

 

Thanks for such a quick reply around a holiday!

 

Taking your suggestion, if I select PayPal on the override, I get the new address that PayPal sends, but it includes the customers name even if the buyer attached a different name to the address while in PayPal (that's if the customer has an account on our site, I'm not 100% sure I checked that particular issue with a new customer). I guess that's only an issue if the customer wants to send the item to someone else, say as a gift. Is that the correct behavior, or is there a way to change the mod to use the name returned from PayPal with the address?

 

Thanks again, it's so awesome to post a support request and get real help! BTW, with the exception of wondering how the override is supposed to work, the contrib is cranking along flawlessly. Thanks to you and Brian for great work.

 

Art

Share this post


Link to post
Share on other sites
Hey Glen,

 

Thanks for such a quick reply around a holiday!

 

Taking your suggestion, if I select PayPal on the override, I get the new address that PayPal sends, but it includes the customers name even if the buyer attached a different name to the address while in PayPal (that's if the customer has an account on our site, I'm not 100% sure I checked that particular issue with a new customer). I guess that's only an issue if the customer wants to send the item to someone else, say as a gift. Is that the correct behavior, or is there a way to change the mod to use the name returned from PayPal with the address?

 

Thanks again, it's so awesome to post a support request and get real help! BTW, with the exception of wondering how the override is supposed to work, the contrib is cranking along flawlessly. Thanks to you and Brian for great work.

 

Art

Art,

That may be a bug. I'll test it this week.

 

--Glen

Share this post


Link to post
Share on other sites
Art,

That may be a bug. I'll test it this week.

 

--Glen

 

I tested this and have confirmed that it is a bug. It will take a little bit of work to get sorted out correctly, but it will probably make it into the next release.

 

On Express Checkout, we only get one address, so when we build the customer record, the payer will have the same address as the shipping address. If you follow the default of not creating a permanent account for EC users, the account will get deleted at the end of the checkout process, so it doesn't matter all that much.

 

--Glen

Share this post


Link to post
Share on other sites

First, kudos to the authors for a great contrib, and an easy-to-follow readme!

 

I'm still working with the sandbox environment, and I have it set up to only do an AUTH. Using a test customer, I can enter a test order into my store, and it shows up in the admin beautifully. When I go into the admin, and pull up the order, then press the Capture funds button, it does not capture the funds, and instead opens a new window that says:

 

FATAL ERROR: register_globals is disabled in php.ini, please enable it!

 

Except I do have globals enabled in the php.ini in both the catalog dir and the admin dir. I've never had that error in my catalog (or in my admin for that matter), so I even tried replacing my admin php.ini with my catalog's php.ini. Admin > Tools > Server Info says register_globals is on. Below is the entire php.ini file from my admin directory. I've read some about how .htaccess can have settings for register_globals too, but I don't have a .htaccess file in my admin directory.

 

My inexperienced eyes think it looks like this line in paypal_wpp_include is causing it:

        var paypal_wpp_window = window.open('<?php echo DIR_WS_INCLUDES; ?>paypal_wpp/paypal_wpp_'+action+'.php?oID='+<?php echo (int)$_GET['oID']; ?>, 'paypal_wpp_window', 'toolbar=0,scrollbars=0,location=0,statusbar=0,menubar=0,resizable=0,width='+w+',height='+h+',left='+leftPos+',top='+topPos);

 

If I take out the (int)$_GET['oID'] and replace it with some text - <?php echo 'removed global'; ?> - then it doesn't display the error, but it also doesn't do anything.

 

I could really use some help to get past this! Thanks!

Share this post


Link to post
Share on other sites
First, kudos to the authors for a great contrib, and an easy-to-follow readme!

 

I'm still working with the sandbox environment, and I have it set up to only do an AUTH. Using a test customer, I can enter a test order into my store, and it shows up in the admin beautifully. When I go into the admin, and pull up the order, then press the Capture funds button, it does not capture the funds, and instead opens a new window that says:

 

FATAL ERROR: register_globals is disabled in php.ini, please enable it!

 

Except I do have globals enabled in the php.ini in both the catalog dir and the admin dir. I've never had that error in my catalog (or in my admin for that matter), so I even tried replacing my admin php.ini with my catalog's php.ini. Admin > Tools > Server Info says register_globals is on. Below is the entire php.ini file from my admin directory. I've read some about how .htaccess can have settings for register_globals too, but I don't have a .htaccess file in my admin directory.

 

My inexperienced eyes think it looks like this line in paypal_wpp_include is causing it:

        var paypal_wpp_window = window.open('<?php echo DIR_WS_INCLUDES; ?>paypal_wpp/paypal_wpp_'+action+'.php?oID='+<?php echo (int)$_GET['oID']; ?>, 'paypal_wpp_window', 'toolbar=0,scrollbars=0,location=0,statusbar=0,menubar=0,resizable=0,width='+w+',height='+h+',left='+leftPos+',top='+topPos);

 

If I take out the (int)$_GET['oID'] and replace it with some text - <?php echo 'removed global'; ?> - then it doesn't display the error, but it also doesn't do anything.

 

I could really use some help to get past this! Thanks!

 

More info:

Well it turns out it's not the code from paypal_wpp_include. That code is opening a new window with a new url and it correctly reflects the $_GET['oID']. The url of the new window is:

http://mydomain.com/admin/includes/paypal_...ture.php?oID=71

and then the new window contains the FATAL ERROR above about register_globals.

 

I thought I had read earlier posts that said this mod worked without register_globals. Can someone clarify if it requires register_globals to be on?

 

Right now I'm reading through the register_globals contrib readme to see if I can figure out what's causing it, but would still really appreciate any help. I've already spent days fiddling with this.

 

P.S. If it matters, the auth transaction does go through to Paypal, and if I capture it on the Paypal side, the status is not sent back to osc (not sure if it's supposed to). If I change my Payment action to Sale instead of Authorization, the sale does go through, but the osc admin shows the order as pending (not sure if that's right or not).

Share this post


Link to post
Share on other sites
More info:

Well it turns out it's not the code from paypal_wpp_include. That code is opening a new window with a new url and it correctly reflects the $_GET['oID']. The url of the new window is:

http://mydomain.com/admin/includes/paypal_...ture.php?oID=71

and then the new window contains the FATAL ERROR above about register_globals.

 

I thought I had read earlier posts that said this mod worked without register_globals. Can someone clarify if it requires register_globals to be on?

 

Right now I'm reading through the register_globals contrib readme to see if I can figure out what's causing it, but would still really appreciate any help. I've already spent days fiddling with this.

 

P.S. If it matters, the auth transaction does go through to Paypal, and if I capture it on the Paypal side, the status is not sent back to osc (not sure if it's supposed to). If I change my Payment action to Sale instead of Authorization, the sale does go through, but the osc admin shows the order as pending (not sure if that's right or not).

The capture window works correctly in my MS2 shop where I have register_globals disabled on the admin side. I will do some testing to verify that the setting is 'off' for the popups and that they work correctly.

 

Status not being returned to osC is a known issue. It's supposed to be returned in an IPN, but the current code doesn't work. It's fairly high on my list of things to do, but it's invisible to the customer. I do all my captures through Batch Capture on the PayPal side, so it isn't at the top of my list yet.

 

Order status on a completed sale can be set in the module admin. The setting is 'completed order status'. Upon installation, it is set to "default", which is usually 'pending'. You can change it to 'processing' or create a new status that indicates that payment has been received. Because IPN doesn't work, the status won't change automatically for some operations (capture on the PayPal site, chargeback). Once I fix IPN, this will work as expected.

 

--Glen

Share this post


Link to post
Share on other sites
I tested this and have confirmed that it is a bug. It will take a little bit of work to get sorted out correctly, but it will probably make it into the next release.

 

On Express Checkout, we only get one address, so when we build the customer record, the payer will have the same address as the shipping address. If you follow the default of not creating a permanent account for EC users, the account will get deleted at the end of the checkout process, so it doesn't matter all that much.

 

--Glen

 

Thanks for checking on that and for clearing the issue up. I'll know to go ahead with our current install. I'll watch for future releases. Thanks again for your awesome work!

Share this post


Link to post
Share on other sites
Thanks for checking on that and for clearing the issue up. I'll know to go ahead with our current install. I'll watch for future releases. Thanks again for your awesome work!

 

I spent some time with it in the past 24 hours or so and found a bunch of bugs in the way Express Checkout handled addresses. I'm almost done testing this set of changes and will commit them to the development tree on github. There are a bunch of test cases, and I haven't even begun to test what happens when you change an address in the shop after you return from PayPal.

 

--Glen

Share this post


Link to post
Share on other sites
The capture window works correctly in my MS2 shop where I have register_globals disabled on the admin side. I will do some testing to verify that the setting is 'off' for the popups and that they work correctly.

 

Glen, Thanks so much for your earlier reply. After sticking the phpinfo function into application top and checking a variety of admin files, I found that for some reason register_globals wasn't on for the paypal_wpp files, even though it was on for the rest of my admin. I managed to hack globals back on in the paypal_wpp files by copying the php.ini file into the paypal_wpp directory, not sure how good an idea that is, but it has gotten me past the error for now. I want to disable it in my whole shop before I go live, so it's good to know that it works in your environment. I must have something inconsistent in mine.

Share this post


Link to post
Share on other sites

In a nutshell, is this how the default add-on code works?

 

before_process() – sets vars somewhat specific to if it's EC or DP

wpp_execute_transaction() – sets vars that all transactions need (like currency, ip, api connection stuff), then creates or replaces the xml file with the correct var names, then sends the data to paypal

 

Reason for asking – I’m looking at adding a recurring payments call, and am trying to figure out:

1. the best place to put it

2. if I need to create my own xml template or the code auto-generates it – I’m guessing I do need to create my own template, and that the code will just auto-populate it

 

So if the above is correct, I need to:

1. add the code to set the additional variables that the recurring payments call needs

2. add the recurring payments call(s)

3. create the xml template

 

Does that sound right? Is there anything more that you know of that I'll need to do?

 

Thanks!

Share this post


Link to post
Share on other sites

hi, i'm having trouble with errors in the admin area on the order page after installing this module and i'm wondering how to go about fixing this.. i read through this thread and someone had the same problem that seemed to be coming from a misconfiguration in the configure.php files, but i've gone over mine and adjusted what i could and still can't see where it is going wrong.....

 

so the errors i receive are:

 

Warning: main(xxxx/xxxx/mysite.org/includes/configure.php) [function.main]: failed to open stream: No such file or directory in xxxx/xxxx/mysite.org/admin/orders.php on line 16

 

Warning: main(xxxx/xxxx/mysite.org/includes/configure.php) [function.main]: failed to open stream: No such file or directory in xxxx/xxxx/mysite.org/admin/orders.php on line 16

 

Warning: main() [function.include]: Failed opening 'xxxx/xxxx/mysite.org/includes/configure.php' for inclusion (include_path='.:/usr/local/lib/php') in xxxx/xxxx/mysite.org/admin/orders.php on line 16

_____________

 

here the path to the configure.php is wrong.. it should be: 'xxxx/xxxx/mysite.org/catalog/includes/configure.php'.

 

my includes/configure.php looks like this:

  define('HTTP_SERVER', 'http://mysite.org'); // eg, [url="http://localhost"]http://localhost[/url] - should not be empty for productive servers
 define('HTTPS_SERVER', ''); // eg, [url="https://localhost"]https://localhost[/url] - should not be empty for productive servers
 define('ENABLE_SSL', false); // secure webserver for checkout procedure?
 define('HTTP_COOKIE_DOMAIN', '');
 define('HTTPS_COOKIE_DOMAIN', '');
 define('HTTP_COOKIE_PATH', '');
 define('HTTPS_COOKIE_PATH', '');
 define('DIR_WS_HTTP_CATALOG', '/catalog/');
 define('DIR_WS_HTTPS_CATALOG', '');
 define('DIR_WS_IMAGES', 'images/');
 define('DIR_WS_ICONS', DIR_WS_IMAGES . 'icons/');
 define('DIR_WS_INCLUDES', 'includes/');
 define('DIR_WS_BOXES', DIR_WS_INCLUDES . 'boxes/');
 define('DIR_WS_FUNCTIONS', DIR_WS_INCLUDES . 'functions/');
 define('DIR_WS_CLASSES', DIR_WS_INCLUDES . 'classes/');
 define('DIR_WS_MODULES', DIR_WS_INCLUDES . 'modules/');
 define('DIR_WS_LANGUAGES', DIR_WS_INCLUDES . 'languages/');

 define('DIR_WS_DOWNLOAD_PUBLIC', 'pub/');
 define('DIR_FS_CATALOG', dirname($HTTP_SERVER_VARS['SCRIPT_FILENAME']) . '/');
 define('DIR_FS_DOWNLOAD', DIR_FS_CATALOG . 'download/');
 define('DIR_FS_DOWNLOAD_PUBLIC', DIR_FS_CATALOG . 'pub/');

 

and my admin/includes/configure.php looks like this:

  define('HTTP_SERVER', 'http://mysite.org'); // eg, [url="http://localhost"]http://localhost[/url] or - [url="https://localhost"]https://localhost[/url] should not be NULL for productive servers
 define('HTTP_CATALOG_SERVER', '');
 define('HTTPS_CATALOG_SERVER', '');
 define('ENABLE_SSL_CATALOG', 'false'); // secure webserver for catalog module
 define('DIR_FS_DOCUMENT_ROOT', $DOCUMENT_ROOT); // where your pages are located on the server. if $DOCUMENT_ROOT doesnt suit you, replace with your local path. (eg, /usr/local/apache/htdocs)
 define('DIR_WS_ADMIN', '/admin/');
 define('DIR_FS_ADMIN', DIR_FS_DOCUMENT_ROOT . DIR_WS_ADMIN);
 define('DIR_WS_CATALOG', '/catalog/');
 define('DIR_FS_CATALOG', DIR_FS_DOCUMENT_ROOT . DIR_WS_CATALOG);
 define('DIR_WS_IMAGES', 'images/');
 define('DIR_WS_ICONS', DIR_WS_IMAGES . 'icons/');
 define('DIR_WS_CATALOG_IMAGES', DIR_WS_CATALOG . 'images/');
 define('DIR_WS_INCLUDES', 'includes/');
 define('DIR_WS_BOXES', DIR_WS_INCLUDES . 'boxes/');
 define('DIR_WS_FUNCTIONS', DIR_WS_INCLUDES . 'functions/');
 define('DIR_WS_CLASSES', DIR_WS_INCLUDES . 'classes/');
 define('DIR_WS_MODULES', DIR_WS_INCLUDES . 'modules/');
 define('DIR_WS_LANGUAGES', DIR_WS_INCLUDES . 'languages/');
 define('DIR_WS_CATALOG_LANGUAGES', DIR_WS_CATALOG . 'includes/languages/');
 define('DIR_FS_CATALOG_LANGUAGES', DIR_FS_CATALOG . 'includes/languages/');
 define('DIR_FS_CATALOG_IMAGES', DIR_FS_CATALOG . 'images/');
 define('DIR_FS_CATALOG_MODULES', DIR_FS_CATALOG . 'includes/modules/');
 define('DIR_FS_BACKUP', DIR_FS_ADMIN . 'backups/');

 

if any one can help in any way it would be greatly appreciated..

Share this post


Link to post
Share on other sites
hi, i'm having trouble with errors in the admin area on the order page after installing this module and i'm wondering how to go about fixing this.. i read through this thread and someone had the same problem that seemed to be coming from a misconfiguration in the configure.php files, but i've gone over mine and adjusted what i could and still can't see where it is going wrong.....

 

so the errors i receive are:

 

Warning: main(xxxx/xxxx/mysite.org/includes/configure.php) [function.main]: failed to open stream: No such file or directory in xxxx/xxxx/mysite.org/admin/orders.php on line 16

 

Warning: main(xxxx/xxxx/mysite.org/includes/configure.php) [function.main]: failed to open stream: No such file or directory in xxxx/xxxx/mysite.org/admin/orders.php on line 16

 

Warning: main() [function.include]: Failed opening 'xxxx/xxxx/mysite.org/includes/configure.php' for inclusion (include_path='.:/usr/local/lib/php') in xxxx/xxxx/mysite.org/admin/orders.php on line 16

_____________

 

here the path to the configure.php is wrong.. it should be: 'xxxx/xxxx/mysite.org/catalog/includes/configure.php'.

 

 

if any one can help in any way it would be greatly appreciated..

 

In admin/orders.php, find:

//---PayPal WPP Modification START ---//
 include(DIR_FS_DOCUMENT_ROOT . DIR_WS_INCLUDES . 'configure.php');

 

Change to:

//---PayPal WPP Modification START ---//
 include(DIR_FS_CATALOG . DIR_WS_INCLUDES . 'configure.php');

 

This should fix it. The problem occurs due to a difference in how FS_DOCUMENT_ROOT is defined. Many early installations have, for one reason or another, set FS_DOCUMENT_ROOT to the catalog folder. The change I made above works for those who use the default setting of FS_DOCUMENT_ROOT, and should work equally well for everyone else. I'll modify the installation instructions for the next release to use the above change.

 

--Glen

Edited by SteveDallas

Share this post


Link to post
Share on other sites
In admin/orders.php, find:

//---PayPal WPP Modification START ---//
 include(DIR_FS_DOCUMENT_ROOT . DIR_WS_INCLUDES . 'configure.php');

 

Change to:

//---PayPal WPP Modification START ---//
 include(DIR_FS_CATALOG . DIR_WS_INCLUDES . 'configure.php');

 

This should fix it. The problem occurs due to a difference in how FS_DOCUMENT_ROOT is defined. Many early installations have, for one reason or another, set FS_DOCUMENT_ROOT to the catalog folder. The change I made above works for those who use the default setting of FS_DOCUMENT_ROOT, and should work equally well for everyone else. I'll modify the installation instructions for the next release to use the above change.

 

--Glen

 

 

thank you very much, glen! that fixes it.

Share this post


Link to post
Share on other sites

Glen,

 

I'm going to go ahead and try updating again. Have there been any recent updates since July that you can add into a zip if it is not a "final" release for the time being?

Share this post


Link to post
Share on other sites
Glen,

 

I'm going to go ahead and try updating again. Have there been any recent updates since July that you can add into a zip if it is not a "final" release for the time being?

 

Jason,

You can always download the latest development version from github. I try to ensure that each update is bug-free before pushing it up to the server. When I feel I have made a significant upgrade, I pull the archive from github and upload it here. The "popup windows on the orders.php page only show on HTTP" bug that stopped you last time was fixed after 1.0.6 if you prefer to install that version, but the fix is posted here in the forum a few pages back.

 

--Glen

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×