Jump to content
Latest News: (loading..)

cinolas

Members
  • Content count

    135
  • Joined

  • Last visited

  • Days Won

    2

cinolas last won the day on January 7 2017

cinolas had the most liked content!

Profile Information

  • Real Name
    Nicolas

Recent Profile Visitors

6,093 profile views
  1. As I understand the code, the Pigal image container is set to be 250px wide, and to use the image aspect ratio. I use square images, but the container they appear in is 250px by 244px with overflow: hidden, so the bottom of the image gets cropped. I dug into the product_info.php file but that's not where the height gets calculated. I looked at the tep_image function in html_output.php and it looks like the function can receive a width and a height as parameters, but when I add those parameters to the function call in product_info.php it doesn't seem to be passed through: the image is still 244px tall... Where else should I look? Thanks!
  2. I'm having the same problem as @tgely ... I use square images but the container they appear in is 250px by 244px with overflow: hidden, so the bottom of the image gets cropped. I dug into the product_info.php file but that's not where the size gets calculated. I looked at the tep_image function in html_output.php and it looks like the function can receive a width and a height as parameters, but when I add those parameters to the function call in product_info.php it doesn't seem to be passed through: the image is still 244px tall... Where else should I look?? Thanks!
  3. Or, how would I go about modifying the existing 3.1 PayPal Express Checkout not to change the shipping method? Any help would be seriously appreciated
  4. @Jack_mcs Thank you! That's exactly what I needed. I haven't tried it yet, but it gives me enough of a clue that I should be able to make it work if it doesn't outright. Cheers!
  5. @MrPhil All very good concerns, thanks for bringing them up, but I think we're good. It's not mission critical. The specifics of the situation is a bit of a long story, but essentially we're trying to hide products so they are only accessible from certain places. The reason we want those products not to be accessible from search engines is to prevent the user from being confused once they navigate away from the hidden products and can't find it anymore. We want to narrow down the entry points so that the user remembers how they got to it.
  6. @Jack_mcs That's very close to what I need. Two questions: would this work with the SEO URL contrib? My URLs look like this: /directory/some-product-name-p-1943.html Is there any way to query another field than products_id using the method above? I would need it to read a custom boolean field in the products table, so it would have to look something like: (I don't know how $_GET works... or are you getting the products_id from the URL?) <?php if (basename($PHP_SELF) == 'product_info.php && $_GET['products_custom_field'] == 1) ?> <META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW"> <?php } ?> Thanks a bunch!
  7. Greetings! I'm using osC 2.3.4 BS with SEO URL's . I would like to make it so that some of my products don't get indexed by search engine. Those products are clearly tagged in a custom field I created in the Products table. The problem is that the <head> section of product pages, where I would need to put the NOINDEX tag, gets generated in template_top.php I don't want to use robot.txt because I would then have to update the list of pages manually... no fun. Is there any way to query the products record from template_top? Or a way to add the NOINDEX in product_info where I can check the database field to see if that product needs to be indexed or not? Or a third method to achieve this that I'm not thinking about right now? THANKS!!
  8. Any other way to fix this than installing the PayPal App? Where is the latest PayPal Express Checkout payment module? Can I extract it from the App? Thanks!
  9. I'm not really keen on installing the PayPal App. It changes too many other aspects of osCommerce, our staff is well trained for the way things are now. Plus it just includes all up to date payment modules, so I should be able to get the up to date version of PayPal Express Checkout payment module without the App, no? I looked around and it looks like the most recent version is the version I have, 3.1. So I'm not sure the Paypal App would help. Or is there a newer version of PayPal Express Checkout somewhere? Or, does the PayPal App include a newer PayPal Express Checkout? If so, can I get the PayPal Express Checkout payment module from the PayPal App package? Thanks!
  10. Greetings, I'm working with osC 2.3.4 BS and PayPal Express Checkout 3.1 (the payment module, not the app). The problem I am having occurs only when the customer is NOT logged into paypal before selecting paypal express as their payment option. Here is the general flow of the order process: 1. customer finishes their order and selects a shipping method other than the cheapest (express shipping) 2. Customer selects Paypal Express as payment option 3. Customer is taken to Paypal where they log in and see their order including shipping. The total shown is the correct total, including the express shipping. Customer confirms order on Paypal site. 4. Customer is sent back to checkout_confirmation.php where shipping has reverted to the cheapest shipping option, not what they had chosen. This apparently started happening out of the blue a couple months ago. There were no changes made on our end. So I'm assuming that the problem is in the data sent back to osC after payment is confirmed. I have no idea where to look to solve this, since it seems to be coming from Paypal... Any help would be greatly appreciated thanks!
  11. Hi, I'm having the same problem but I'm using the old PayPal Express payment module v3.1 Regardless of what shipping method the user chooses at checkout_shipping.php, upon returning from PayPal the shipping method gets changed to the cheapest method. This was all working fine a few months ago, and started acting up out of the blue. A change at PayPal I'm guessing. I checked my configure.php and the paths are all correct and complete. What else could be causing this? How do I ensure that the selected shipping method sticks throughout the PayPal Express checkout process? Any info is greatly appreciated. I'd rather not upgrade to the PayPal app v5 if I don't have to, it's likely to cause more problems. Plus it was working fine just a couple months ago and I haven't changed anything since. Any help is greatly appreciated!
  12. cinolas

    Shipping/CCGV/PayPal

    Hi, I'm having the same problem but without any CCGV. I suspect we actually have the same problem, did you ever figure it out? I use PayPal Express, and regardless of what shipping method the user chooses at checkout_shipping.php, upon returning from PayPal the shipping method gets changed to the cheapest method. I use a conditional shipping module that offers snail mail if the order thickness is small enough, this method is always the cheapest but not always available. Regardless of wether that option was available to the user on checkout_shipping.php it's always the selected option when returning from PayPal. Note that the order total displayed on PayPal is the correct one with the shipping method selected by the user, it's when the user comes back to checkout_confirmation.php that the shipping method, and therefore the total, are changed. This was all working fine a few months ago, and started acting up out of the blue. A change at PayPal I'm guessing. How do I ensure that the selected shipping method sticks throughout the PayPal Express checkout process? Any info is greatly appreciated. Thanks!
  13. Anyone? Even if you don't know about Moneris or the eSelect payment module, perhaps you'd know if it's likely to stop working due to these changes? Thanks!
  14. Hi, I'm running osCommerce 2.3.4 and the Moneris eSELECTplus Canadian Gateway Version 1.1.0 contribution with my Canadian Moneris account. It works well. I've just received an email advising me of upcoming changes that I should verify compatibility with. The changes that might be pertinent are: DigiCert and Entrust Certificates (Moneris Gateway and IP Gate) Effective March 13, 2018 We will be changing our internet communication security certificates from Verisign to DigiCert and Entrust. This will impact businesses that have not updated their digital certificate or have ‘hard coded’ the existing Verisign certificate. Action Required: Integrated and e-commerce merchants who do not have DigiCert and Entrust certificates stored will need to download the packages to their certificate store or trust store. and Public IP Address Changes (Moneris Gateway) Effective March 28, 2018 We will be updating Moneris Gateway Production IP addresses. This will impact any business that uses static IP addresses or firewall rules/whitelists to connect to the Moneris Gateway. Action Required: Merchants will need to update their IP address whitelists or firewall rules to allow connections to the new IP addresses. I've looked through the payment module files and there doesn't appear to be any hard coded IPs. I'm not even sure where to look to see about the certificates. Are these changes likely to affect the payment module I'm using? If yes, how do I correct that? If maybe, how do I make sure? Thank you all!
×