Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

i960

Pioneers
  • Posts

    115
  • Joined

  • Last visited

Everything posted by i960

  1. As posted earlier, it looks like it's supposed to go after this: tep_db_perform(TABLE_ORDERS, $sql_data_array); $insert_id = tep_db_insert_id(); I got confused in the same spot when trying to install this. It appears that whoever uploaded version 1.54 changed the install instructions, and they haven't been fixed yet. I have no idea where "if (tep_not_null($sql_data_array['customers_id'])) {" came from, but it doesn't exist anywhere in my store, on a fresh download of 2.2 RC2a, or any other previous version of osCommerce I have seen. From the release notes, I'm guessing that change was supposed to be related to the PayPal IPN module, but that code doesn't show up anywhere in the PayPal module at all or in it's install instructions. Sounds like whoever made that change had some other contribution installed. [rant] People, if you're gonna create a new extension or update an existing one, PLEASE base your instructions on a CLEAN install of osCommerce. If another contribution is required, then note that in the instructions, and base your instructions on a CLEAN install of osCommerce plus the required contribution ONLY. Sorry to rant, but I am tired of people polluting what are otherwise good contributions and making it difficult for everyone to use them. And while I'm on my soapbox here, I absolutely hate it when someone updates a contribution and only includes the file they changed or just a little txt file with instructions to make changes. No one wants to track down the last complete package and then have to apply a bunch of different patches. If you are going to make a change, upload the ENTIRE contribution, or don't bother. Quit wasting everyone's time. [/rant]
  2. This fixed the problem for me. Although, I'm not sure it was a problem in my case. I did notice that all products in the category listing had the products_id of the one added to the cart like mentioned, but it didn't seem to affect adding the correct product to the cart. Not sure if it matters, but I used this fix for the continue shopping button: http://addons.oscommerce.com/info/2891 Not the original, but the one listed by Matt Peace. It takes the customer back to the category the product belongs to instead of back to the product they just added, which makes no sense. There are situations where it doesn't work exactly like that, but for the most part it does.
  3. I fixed my problem. All I had to do was change this line in application_top.php from this: if ( is_object($seo_urls) && (strpos($_SERVER['REQUEST_URI'], '.html') !== false) && (defined('FWR_VALIDATION_ON') && FWR_VALIDATION_ON === 'true') ) { // SEO URLS is active and there is .html in the querystring To this: if ( is_object($seo_urls) && (strpos($_SERVER['REQUEST_URI'], '-p-') !== false) && (strpos($_SERVER['REQUEST_URI'], '.html') !== false) && (defined('FWR_VALIDATION_ON') && FWR_VALIDATION_ON === 'true') ) { // SEO URLS is active and there is .html in the querystring Now this code will really only work in my case and it's probably not ideal. The only SEO URL's I have are the one's with -p- in them. I do not have any of the other ones. So my change makes sure that the validation code only works for URL's with -p- and .html in them. If anyone has a site where they have some static html URL's that were not written by Ultimate SEO URL's, then some form of my code might work for you too. Maybe it can be written to test for all the various forms of SEO URL's instead of just testing if it ends in HTML. Hope this helps someone.
  4. Ok, I'm a dumbass. The problem is definetly with my site and has nothing to do with your code or even Ultimate SEO URLs. I found your other thread and decided to put in that debugging code you listed and check it's output. Here's an example of what I got: Took out the debugging code, and BAM, starts working again. Turns out when I was testing before I was on category pages, not individual product pages. Product pages work with your mod, categories blow up. Then I realized, I am not using Ultimate SEO URLs on the categories. The guy that worked on this site before me didn't like the way it wrote URLs, so he came up with his own deal. He basically created static HTML files in the root named exactly how he wanted the URLs to look. For instance, there is a file in the root called electric-hoses.html. Inside that file is the following: <?php $_GET['cPath'] = "5_32"; $category_current_url = basename($_SERVER['PHP_SELF']); include('index.php'); ?> That code chokes when using your mod. I could easily revert back to using USEO for categories, but all my categories are already indexed in Google and I don't want to mess with it. I need to learn to think a little more before posting, lol. :P
  5. I know chemos mod works on Windows at least up to version 2.1d. I have not tried any newer versions. My problem seems to be with the use of constant(). I've never used it before, but I did find this: http://us.php.net/constant I will see if I can work something out and let you know how it goes.
  6. Ok, I did a little more digging. I'm running Windows Server 2003 and I log all PHP errors in the event log. Whenever I get the unable to determine page link error, this shows up in the logs: Line 1402 in general.php is this: $linkreturned = tep_href_link(constant(strtoupper($validate_array[0])), $validate_array[1]); // Get a propper new SEO link Which is obviously from your mod. My tep_href_link() function in html_output.php looks like this: //// // The HTML href link wrapper function function tep_href_link($page = '', $parameters = '', $connection = 'NONSSL', $add_session_id = true, $search_engine_safe = true) { global $seo_urls; if (!is_object($seo_urls)) { if (!class_exists('SEO_URL')) { include_once(DIR_WS_CLASSES . 'seo.class.php'); } global $languages_id; $seo_urls = new SEO_URL($languages_id); } return $seo_urls->href_link($page, $parameters, $connection, $add_session_id); }
  7. I'm having a bit of trouble with this mod. I don't necessarily think there is anything wrong with the contribution, but it does cause a serious issue with my store. As soon as I enable the mod in admin, and then visit any page with a rewritten URL, I get this: And nothing else on the page. A google search revealed a few posts on various messages boards, and they all said to disable "Use Search-Engine Safe URLs" in admin, which it is and always has been. With your mod disabled, everything appears to work fine, as it has been. I have also tried resetting the SEO URL's cache. I am using Ultimate SEO URL's 2.1d dated Nov 25 2006. I am also running RC2a, PHP 5.2.5, Apache 2.2.8, and MySQL 5.0.51a. I'm sure it's something I did wrong or a problem with my store, but I don't know where to look.
  8. It's been awhile since I've read the TOS, but it was absolutely in there. There is a reason why this module was designed to prevent GC from showing up as an option alongside the other payment options. It's possible they have since relaxed the requirement. The only thing I can find after a quick search is this: https://checkout.google.com/support/sell/bi...opic=&type= Those don't come across as being required, but that is the ideal way to do it. As already mentioned above, GC does create an account in your store and you have all the customer details that you need. Having GC as a payment option after creating an account completely defeats the purpose of GC and involves additional unnecessary steps for your customers. GC is an alternative checkout process, not a payment processor.
  9. It's against Google's TOS to have it as a payment option on the payment page. You missed the step that removes it as an option on that page.
  10. You need to use something like phpMyAdmin to run those SQL statements. They don't need to be in an SQL file.
  11. Figured this one out. I had to unregister the session on the checkout_confirmation page. I also tried upgrading to the newest Auth.net module, and I had nothing but problems with it. I either ended up with a credit card error, or it would say I didn't select a payment method, even though I did. None of the fixes in this thread worked for me. I'm just going to stick with what I have for now. It seems to work most of the time, which is better than not working at all.
  12. Tried this and it didn't work for me. In fact, if I make this change, as soon as I hit continue on the checkout_shipping page, it brings me back with the error message "Please select a payment method", even though credit card is selected. Changing it back makes the problem go away. I'm not even sure if the problem I am having is the same as everyone else. I do get the whole "Credit card error: The first four digits of the number entered are" error message, but not on every order. I have it set up to email me any error messages the customers receive during checkout. I get about 10 of those errors a day, but I also receive around 20 orders a day that go through just fine. Another thing is that I'm using the Authorize.net Consolidated v1.7 module instead of the more recent one, and it doesn't have any $_POST's in it, only $HTTP_POST_VARS. I've been meaning to upgrade to the latest module. I also have a problem where once someone enters the CVV code and hit's continue, they are stuck with that for the entire session unless they close the browser and start over. If you go back and change it and then hit continue, it shows the previous one on the confirmation page, and authorize.net will decline the card. I don't know if this has anything to do with the auth.net module I am using or if it's a FEC problem, but I thought I'd throw it out there.
  13. Preliminary testing shows that this fix also works for Google Checkout v1.3RC2. In other words, it's now working on my production site. :D
  14. Ok, testing complete! The solution in my post immediately above works perfectly. As such, I no longer recommend using the solution I posted previously. While the previous solution does indeed work, this new solution works just as well, is easier to implement, and doesn't rely on knowing the user agent for Google Checkout.
  15. Looks like there is another potential solution to the problem I was having. I found it in the Google Groups, but the thread title was highly misleading. It was suggested over there that you could redefine the Prevent Spider Sessions setting for responsehandler.php only. Here's a quote of what was said over there: Ropu responded by saying that would throw up a warning, and suggested adding this to prevent the warning from appearing: error_reporting(0); I haven't tested this yet, but I do have an observation. From looking at the code, it's quite obvious that the "Prevent Spider Sessions" option has no effect whatsoever on Google Checkout, as long as 'google checkout notification agent 1.0' is not in your spiders.txt file. In fact, if you have "Force Cookie Use" set to TRUE, then the code behind "Prevent Spider Sessions" doesn't even run. Up to this point the real solution to getting GC to work is to set "Force Cookie Use" to FALSE, but that is a terrible solution for many reasons. That option should always be set to TRUE if possible. So the solution is to set it to FALSE only in responsehandler.php. That can be done just the same as was suggested for "Prevent Spider Sessions", like this: 1.) Open up resonsehandler.php 2.) Search for error_reporting(E_ALL); and change it to error_reporting(0); 3.) Search for define('MODULE_PAYMENT_GOOGLECHECKOUT_MULTISOCKET', 'False'); 4.) Immediately below it add this: define('SESSION_FORCE_COOKIE_USE', 'False'); I have not tested this at all, but it appears to be a better solution than what I came up with, because it does not rely on knowing what the user agent is for Google Checkout. The only thing that should ever be connecting to responsehandler.php is Google Checkout, so there are no worries about starting a session for a search spider or anything like that. In fact, if you have it properly password protected via .htaccess, nothing else can get to it. I will test this out to see if it works. If so, then I will recommend using this solution instead of my previous one.
  16. Alright, here's how to make this work. STEP 1: Create a file called 'gc_user_agent.txt' and place it in your /catalog/includes/ directory. It should be in the same place as spiders.txt. Add the following to this file and save it: STEP 2: Open 'application_top.php' Search for the following: if (SESSION_FORCE_COOKIE_USE == 'True') { tep_setcookie('cookie_test', 'please_accept_for_session', time()+60*60*24*30, $cookie_path, $cookie_domain); if (isset($HTTP_COOKIE_VARS['cookie_test'])) { tep_session_start(); $session_started = true; } And replace it with this: if (SESSION_FORCE_COOKIE_USE == 'True') { $user_agent = strtolower(getenv('HTTP_USER_AGENT')); $gc_flag = false; if (tep_not_null($user_agent)) { $gc_user_agent = file(DIR_WS_INCLUDES . 'gc_user_agent.txt'); for ($i=0, $n=sizeof($gc_user_agent); $i<$n; $i++) { if (tep_not_null($gc_user_agent[$i])) { if (is_integer(strpos($user_agent, trim($gc_user_agent[$i])))) { $gc_flag = true; break; } } } } if ($gc_flag == true) { tep_session_start(); $session_started = true; } else { tep_setcookie('cookie_test', 'please_accept_for_session', time()+60*60*24*30, $cookie_path, $cookie_domain); if (isset($HTTP_COOKIE_VARS['cookie_test'])) { tep_session_start(); $session_started = true; } } Make sure you check to see that your original code in 'application_top.php' is the same as mine. The code I listed is from a stock install of 2.2 RC1, but it should be the same in MS2. If yours was modified for whatever reason, you'll need to figure out what to do with the new code to make it work. STEP 3: Set 'Force Cookie Use' and 'Prevent Spider Sessions' in Admin to TRUE. Everything else should be FALSE. That's it! Now you can force the usage of cookies for regular visitors, prevent search spiders from creating sessions, and allow Google Checkout to recreate the session it needs in order to update admin and empty the shopping cart. One thing to keep in mind is that I have no idea if Google will change the user agent string or how often. That is why I placed it in 'gc_user_agent.txt' to allow for easy updates if/when necessary. If I find that Google does change the user agent, then maybe it would be good to write some sort of script that captures the user agent string when Google connects to responsehandler.php and updates the 'gc_user_agent.txt' file automatically.
  17. It works!!! Through testing I was able to find out that Google Checkout is reporting itself as 'google checkout notification agent 1.0'. I'll post again in a few minutes showing what I did to make it work.
  18. Here is the code in application_top.php that starts the session, based on the session settings in Admin: // start the session $session_started = false; if (SESSION_FORCE_COOKIE_USE == 'True') { tep_setcookie('cookie_test', 'please_accept_for_session', time()+60*60*24*30, $cookie_path, $cookie_domain); if (isset($HTTP_COOKIE_VARS['cookie_test'])) { tep_session_start(); $session_started = true; } } elseif (SESSION_BLOCK_SPIDERS == 'True') { $user_agent = strtolower(getenv('HTTP_USER_AGENT')); $spider_flag = false; if (tep_not_null($user_agent)) { $spiders = file(DIR_WS_INCLUDES . 'spiders.txt'); for ($i=0, $n=sizeof($spiders); $i<$n; $i++) { if (tep_not_null($spiders[$i])) { if (is_integer(strpos($user_agent, trim($spiders[$i])))) { $spider_flag = true; break; } } } } if ($spider_flag == false) { tep_session_start(); $session_started = true; } } else { tep_session_start(); $session_started = true; } If my thinking is correct, it should be possible to test the user_agent string for whatever Google Checkout is calling itself (jakarta or otherwise) and allow the session to be started if it is Google Checkout accessing the site. I will see what I can come up with and post my findings. The only way I can see this not working is if Google Checkout changes it's user_agent string every once in awhile. If that's the case, then maybe setting up a file similar to spiders.txt and keeping a list of all know user_agent strings for Google Checkout would help with that.
  19. Interesting info on what 'jakarta' actually is: http://en.wikipedia.org/wiki/Jakarta_Project I'm guessing Google is using that to implement Google Checkout on their side.
  20. That's what I figured. I guess the logic would be to force cookie use for customers and search spiders, but not force it for Google Checkout. I noticed in posts on the google groups board that he's been recommending people set Force Cookie Use to false in order to get GC working. I'm going to dig into how the force cookie use option actually works and see if I can come up with something. I guess the first step is to figure out what Google Checkout is identifying itself as. I'm guessing it's 'jakarta', as that is what the documentation says to make sure is not in spiders.txt.
  21. Well, after more testing, I realized that even if my browser accepts cookies, as soon as I hit any of the secure pages, the session ID is appended to the URL. That is something I do not want. Setting "Force Cookie Use" to True solves that problem, but then Google Checkout stops working. There has got to be another way to do this.
  22. I also found this page that better explains what each setting does: http://www.oscommerce.info/kb/osCommerce/D...plementations/4 Seems to me that ideal settings would be "Force Cookie Use" to True (I don't want anyone to have session id's in the URL for privacy/security reasons) and "Check SSL Session ID" to False (So there are no issues with AOL or weird browsers that don't support it). But obviously that isn't going to work with Google Checkout. I also ran across this old thread: http://www.oscommerce.com/forums/index.php?showtopic=41451 Doesn't seem like anyone found a solution to AOL being blocked. Also, seeing as it's from 2003, it's possible that AOL is now using a browser that will work just fine. I just have no way of testing that.
  23. Continuing from the previous thread. I found a new potential issue. In looking at the osCommerce documentation, I found this note: Does this mean having "Check SSL Session ID" set to true is going to cause problems for my aol customers? We have quite a few of them.
  24. SUCCESS!!! That did the trick. The weird thing is it has to be exactly like that for it to work. I tried setting "Force Cookie Use" to False previously and it did not work. For whatever reason, changing "Check SSL Session ID" to True AND changing "Force Cookie Use" to False is the only combination that works for me. Now the question is, what are the ramifications of setting "Force Cookie Use" to False? What exactly does that setting do? As far as the real time shipping goes, that's not something I'm even remotely worried about right now. We have no intentions on using anything other than table rate shipping for the time being, which works flawlessly. The pricing we have set up is very simple for customers to understand and is totally fair. In most cases we break even or lose a dollar or 2 on the shipping, but our profit margin easily absorbs that. The only time we charge more for shipping than the actual cost is for very small items that can be sent via regular mail. Thank you SO much for your help on this. Even though GC is not something I really care to use, my employer is going to be very happy having it work properly. This has been a thorn in my side for months.
  25. I installed the responsehandler_test.php program and ran it. This is the result: Same error as before.
×
×
  • Create New...