devosc

Rob :), PayPal only works to 2d.p. You could try setting the the decimal places in osC admin and/or (if possible) also set this in the PHP.ini file, otherwise might have to further coax osC.

sounds like you might need to do this: Also remember page 15.

See page 15 of this thread, also look at page fourteen, both pages have suggested code changes, you might also read page 1 which discusses email. Upload a new version of catalog/ipn.php, you shouldn't of receieved a parse error on that page for that line, unless you edited it.

I came across another contribution yesterday that was of interest called held_orders which put an order into a seperate table prior to updating the main 'orders' table, which I think would be the way to go for pending status; but (I assume) all this would then require a lot more changes within osC, etc. Anyway, if I have the time, I will try and put together another version update soley to include the remedies discussed so far in this thread - to save others from trawling through the first 20 odd pages of this thread. Please post any ideas. I haven't had time to think about pending payments all the way through, so if someone could clearly outline what they think should generally happen, a better picture can be built from which it would be easier to actually develop.

It's been awhile since playing with this contrib, and even longer since having an installed version of paypalipn 0.981, but from looking at the code for 0.981 I could not 'quickly' see where 0.981 returns the product item back into the stock inventory upon a refund, from what I could see it just updates the status of the IPN transaction. Handling refunded is not hard to do, but a clear definition of what is expected to happen when a refund notice needs to be made. Handling a pending payment probably isn't that difficult either, depending, again, on what you expect to happen, do mean that the status of the IPN is simply updated, and that when a notification is received that the payment is 'Completed' that the stock levels are then updated. Further scripting would also be required in order to prevent downloads from immediately being available if a payment is still pending. How does your contribution work, does it check the payment status before allowing a customer to proceed or is it just for the order history. Order history (payment status) is not really a problem, but the stock inventory level is a more delicate process. In a previous post I mentioned an alternative to the current method of reconstructing/accessing the cart information. I'm more interested in refining the actual verification checks, such as currencies, cart totals etc as well as the aspects mentioned by JoJo. Unless commissioned to do so, I don't have a time frame.

Hi JoJo, Thanks for pointing that out, it was developed it upon a default install and I suppose ip checking would also kill the session too. But this can be easily remedied. I have recently started to think that querying the customers_shopping_basket table might be a better alternative than recreating the session. However it is a little more involved; but this can be based upon the same principles behind the recover-cart-sales contribution. Thanks, Greg.

Tammy, you can update the code in paypal.php in the modules payment section; however the types of products/services of your site is prohibited for use with PayPal. Shanna, 1. Did you enable IPN in your PayPal account profile? 2. Don't Know 3. Don't Know; are you sure you are using this contribution, the amendments that I made to the original osC files did not not have anything to do with an order's status.

This is the support thread....This contribution was based upon the orginal MS2 2.2, I find it appaling that other people customize and release osC with other contributions and have functions like tep_admin_check_login() which is not part of the original package and is therefore an everlasting development nightmare, and to top it off they include contributions that are insecure leaving you to wonder what other crap have they put in, so you are basically back to square one, this is not development! I aprreciate that not everyone is able to debug applications, but unfortunately in this case I personally can't help because I don't know ms2-max 2.2. Incidentally the changes made in admin/functions/general.php has nothing to do with the above function. It does clearly state in the Install_Instructions.txt file that if you want to find the bits that were changed in the original osC files, then search for paypal or paypal_ipn. What you need to look into is how the authorization process works, i.e how and where does the application determine what files are associated to either a user or other files.

Hi Tom, Today I downloaded and had a look at EP's code. What time line do expect for the admin interface. Could you first provide a version that does not incorporate any other contribs, or the froogle thing. Can you write/restructure the easypopulate.php more like the other admin files, in particular the case structures that generally occur at the top of the page. I haven't seen this contrib working but, initially I would think it better if the $default_these array is generated automatically based upon the keys in the products table rather than hard coded - for some reason I'm imagining that it would (possibly) later nice to be able to select which fields are to be used via the admin interface. Moving all the ep functions into a file soley for ep functions. kill the global statments where they aren't nessecary. and if needed by a particular function pass them as an argument (if at all possible - i.e. how many need to be passed) I'm not sure but would/might be nice to have a class to hold the core operations of EP. BTW there is a function in MS2 2.2 called tep_catalog_href_link(). Anything to reduce the amount of php code occuring within the actual html section. Moving any of the tep files to easypopulate_functions.php if they do not already exist in the core osC 2.2 app already. Maybe the use to array_map instead of $iii++, not sure at present how this comes into play if automatically defining keys.

My mistake, I meant admin/includes/functions/administrators.php Here's the top part of the array that needs to be amended (not might not be exactly the same as yours, but gives the idea - i.e. customers.php). $aADMPages = array( 'configuration.php' => 'configuration.php', 'index.php' => '*', 'categories.php' => '*', 'categories.php' => 'catalog.php', 'products_attributes.php' => 'catalog.php', 'manufacturers.php' => 'catalog.php', 'reviews.php' => 'catalog.php', 'specials.php' => 'catalog.php', 'featured.php' => 'catalog.php', 'products_expected.php' => 'catalog.php', 'define_mainpage.php' => 'catalog.php', 'modules.php' => 'modules.php', 'customers.php' => 'customers.php', 'members.php' => 'customers.php', 'orders.php' => 'customers.php', 'invoice.php' => 'customers.php', 'packingslip.php' => 'customers.php',

Hopefully your using PayPal_Shopping_Cart_IPN :D Anyway, have a look at admin/administrators.php you will find an associative array that 'associates' specific files to particular files from each category box, for example, you may need to associate packingslip.php to the customers.php file, so too for invoice.php, and now paypal_ipn.php, etc... HTH.

Hmm, when I tested it yesterday I didn't strictly automatically prohibit all cookies, but rather declined to accept each one each time PayPal tried to set one, thats why I suspect I got through to the login. Anyway, yeah, it would seem that if your customers aren't accepting cookies then they shouldn't expect/be able to use PayPal no matter where they came from on the net, so my impression is that it is not anything really to do with osC or the PayPal IPN contribution. You could set in osC admin to force cookies in order for them to shop so that by the time the get to PayPal there shouldn't be any problems for them to continue finalizing the order.

Hi Susie, Which PayPal IPN contribution are you using? I went through a checkout process and blocked all cookies and was still able to login to PayPal and prompted to confirm payment? Unless it is at this very final stage that PayPal then complains about not having cookies, but I somewhat doubt that. Have you tried this process yourself?

Donno if it will help, but what I did (not for the categories/products page) was to actually have some stripslashes($HTTP_POST_VARS['description']) in the edit page too. So that when going back to the edit page the slashes that where added in posting back to the page are removed, so everything is as should be. Which seems to of worked well for me in my preliminary tests. So, open up cateories.php (or whatever) and find the bits where the variables passed are entered into the text areas and enclose them with stripslashes(). Actually I discovered the best solution is to use the osC objectInfo class, basically it strips the slashes for you, and you will also notice that it is used when retrieving data from the database. So my code now looks like this: if (tep_not_null($HTTP_POST_VARS)) { $eInfo = new objectInfo($HTTP_POST_VARS); } else { $eID = (int)$HTTP_GET_VARS['eID']; $events_query = tep_db_query("select * from " . TABLE_EVENTS . " ev where ev.events_id = '" . $eID . "'"); $events = tep_db_fetch_array($events_query); $eInfo = new objectInfo($events); for ($i = 0, $n = sizeof($languages); $i < $n; $i++) { $language_id = $languages[$i]['id']; $events_language_query = tep_db_query("select * from " . TABLE_EVENTS_DESCRIPTION . " ed where ed.events_id = '" . $eID . "' and ed.language_id = '" . $language_id . "'"); $events_info = tep_db_fetch_array($events_language_query); $events_name_array[$language_id] = $events_info['events_name']; $events_description_array[$language_id] = $events_info['events_description']; } $events_name = array ('events_name' => $events_name_array ); $events_description = array ('events_description' => $events_description_array ); $eInfo->objectInfo(array_merge($events_name,$events_description)); } Then all that is neccessary to use the data is to use $eInfo->events_id etc and you know that the slashes have been taken care of, the additional bonus of doing this is that you no longer have to worry about whether you are accessing form POST vars or database vars when constructing the form.

Hi there, I've got the WYSIWYG HTMLArea MS2 v1.7 contrib installed, the text areas seems ok, but I'm a bit unsure about the image upload, I had to tweak it so that the oscImageRoot automatically uses SSL if the admin is in a secure area, however this still didn't prevent the warning about insecure items being loaded, anyway, I'm using I.E. 6.0 but when clicking on an image or directory, I keep getting an Access Denied script error: htmlarea/popups/viewer.php?DPI=96&file=oscommerce.gif All the files in that directory are world readable/writable? Is there something else that needs to be configured? The other thing I noticed was that when uploading a file and resizing it, cleared the image? Does HTML Editor and UltraPics resolve any of this? TIA.

I would of answered you along time ago but you haven't bother to enlighten us as to which admin access contribution you are using, so whats the point in guessing. Also which PayPal IPN contrib are you using? If your using Admin Access with Levels, then look in the administrators.php file and you will see a list of files associated to particular files from each menu box. You will need to update the list to include the new IPN file and any others.

I would of thought so, plus normally the customer would be displayed a list of shipping options which have calculated weights etc... so asking them to repeatively select which shipper to use might seem a bit frustrating and confusing, especially if the customer is not familar with your whole checkout process, I only got a far as login. What I think could be an answer is the Ship in Cart contrib. This I think displays the shipping options when the customer views the cart, at least that is what I assume the contrib is for.

You wouldn't want to force the attributes for a product, it is up to the customer to decide what color, size, type etc they want. You could do a check to see if a product has attributes, and display a but now button if it doesn't but that might look a bit uphazard, unless you stick a button saying more info, for those that do have selectable attributes. Heres the code that is governing the buy_now and add_product parameters // customer adds a product from the products page case 'add_product' : if (isset($HTTP_POST_VARS['products_id']) && is_numeric($HTTP_POST_VARS['products_id'])) { $cart->add_cart($HTTP_POST_VARS['products_id'], $cart->get_quantity(tep_get_uprid($HTTP_POST_VARS['products_id'], $HTTP_POST_VARS['id']))+1, $HTTP_POST_VARS['id']); } tep_redirect(tep_href_link($goto, tep_get_all_get_params($parameters))); break; // performed by the 'buy now' button in product listings and review page case 'buy_now' : if (isset($HTTP_GET_VARS['products_id'])) { if (tep_has_product_attributes($HTTP_GET_VARS['products_id'])) { tep_redirect(tep_href_link(FILENAME_PRODUCT_INFO, 'products_id=' . $HTTP_GET_VARS['products_id'])); } else { $cart->add_cart($HTTP_GET_VARS['products_id'], $cart->get_quantity($HTTP_GET_VARS['products_id'])+1); } } tep_redirect(tep_href_link($goto, tep_get_all_get_params($parameters))); break; I now see that on the test site shown above that in actual fact the attributes to those items are shipping options ? And leads to the possibility of having each item being requested to be sent by different carriers (all to the same address?).

It's because if a product has attributes available with the product it will automatically redirect you to product_info.php, but if the product has no attributes then it will be automatically added to the cart. Have a read of application_top.php. Tied up right now otherwise I would get my mind into it more to help.

You would need to use tep_draw_form as the 'add_product' parameter will the look for POSTed items, as opposed to the buy_now which uses GET. Look at the code on the product_info.php page and copy and paste it into where previously suggested above.

Try changing $new_products['products_id'] to $featured_products['products_id'] in the above code.

Hi there, I love this contrib, and had great fun installing it. However I noticed that the sql statements would not pull out all the featured products from within a category having deep nested sub categories. So I amended the code; I think I changed the parent_id clause to this: c.categories_id IN (".implode(',',$cat_array).") And just before declaring the raw sql statement including the above, I put: function get_all_subcategories($currentParID) { global $cat_array; $haschildren = 0; //default $categories_query = tep_db_query("select c.categories_id, c.parent_id from " . TABLE_CATEGORIES . " c where c.parent_id = '" . $currentParID . "' order by sort_order"); $cat_array[] = $currentParID; while ($categories = tep_db_fetch_array($categories_query)) { $haschildren=tep_has_category_subcategories($categories['categories_id']); if ($haschildren) { get_all_subcategories($categories['categories_id']); } else { $cat_array[] = $categories['categories_id']; } } } $cat_array = array(); get_all_subcategories($featured_products_category_id); Where the above get_all_subcategories function will return an array list of all associated child sub categories pertaining to the current subcategory. I also added in the admin selction the option whether or not to include the specials in the features box. It was my first hack of having to join tables etc, so I haven't posted the entire code of modules/featured.php

A few observations, Firstly where is $billingmethod very first defined, you test to see whether it is equal to "Monthly", but where before that in the script is it set, When you echo out to the screen you have $billcylce, but a few lines above your saying $billingcyle ??? If the $billingmethod is not set (equla to Monthly, Yearly) you have set it so that the default case is '', i.e no value at all. You have to be careful about the variable names, billing_method is not the same as billingmethod.

I'm not familar with paystems etc. But in my experience what happens is the call to $payment_module->process_button(); will return all the hidden fields that will then be passed to the 3rd party. And looking at your code you do not have for example $billing_method declared global in that function like for example $currencies, so the value assigned to $billing_method outside of that function is not being referenced by the $billing_method variable inside the $process_button() function. HTH.

Jack, Can't really help you there, this contribution support thread is for PayPal_Shopping_Cart_IPN. It is not the same as PayPal IPN v0.98.