Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

i960

Pioneers
  • Posts

    115
  • Joined

  • Last visited

Profile Information

  • Real Name
    Jeff

i960's Achievements

  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.
×
×
  • Create New...