Jump to content

beercityhooligan

Members
  • Content count

    9
  • Joined

  • Last visited

Profile Information

  • Real Name
    Johnny Hastings

Recent Profile Visitors

2,093 profile views
  1. Looks like I found the answer to my own question. In the discountcodesfolder\catalog\includes\modules\header_tags\ht_discount_code\ht_discount_code.php file, it references the markup section I pasted in my previous post. It seems like I can simply update the bolded part of the following line (#s 18 to 24): $('div.contentContainer div.contentText .form-group').parent().before('<h2><?php echo TEXT_DISCOUNT_CODE; ?></h2><div class="col-xs-6 col-sm-3">\n\ <div class="form-group has-feedback">\n\ <input type="text" class="form-control" name="discount_code" value="<?php echo isset($sess_discount_code) ? $sess_discount_code : ''; ?>" id="discount_code" />\n\ <span class="form-control-feedback" id="discount_code_status" style="right:0;"></span>\n\ </div>\n\ </div> \n\ <div class="clearfix"></div><hr>'); to select on the same part of the code, but as it applies to my file rather than the default. Pretty straight forward. Sorry to ask a dumb question here, but maybe this will help someone else!
  2. In the install instructions there's a note that says this: ------------------------------------------------------------------------------- IMPORTANT: Make sure the following original code is present and not altered or uncommented in checkout_payment.php: The ht module uses this code as a reference to inject the discount code input field. about line 241-245: <hr> <div class="contentText"> <div class="form-group"> <label for="inputComments" class="control-label col-sm-4"><?php echo TABLE_HEADING_COMMENTS; ?></label> ------------------------------------------------------------------------------- My checkout_payment is rather well customized, and this code is not present. I browsed through this thread, but I didn't see any tweak in order to make things work. Can I do something to make it work without that original code in place?
  3. I have a client with OSC 2.3.4. I recently updated the install to include the latest version of the PayPal app, that I pulled down Saturday morning. The PayPal app zip shows version 4_039. The general and PayPal standard app configuration has been completed for the PayPal app. Sometimes things work fine, sometimes it doesn't. The symptoms when it doesn't are that after a customer makes a payment: emails aren't sent, and the inventory isn't reduced. The payments do still succeed in PayPal, and the status in OSC admin just sits at Processing and never updates. I've been digging into this for days trying to figure it out, and am having little luck. Seems like these symptoms are common, but for a variety of reasons. Under the PayPal IPN listings, none of them show as failed. One thing to note is that the PHP error_log shows the following error most times standard_ipn.php is accessed: Fatal error: Call to a member function getCredentials() on a non-object in /home2/sitename/public_html/ext/modules/payment/paypal/standard_ipn.php on line 29 That line of code (line 29 from standard_ipn.php) is this: $seller_accounts = array($paypal_standard->_app->getCredentials('PS', 'email')); After some debugging, the issue is that the _app member object of the paypal_standard object is null. Which is obvious from the error message in the log. If you track it through, you see that when you create a new paypal_standard object in catalog/includes/modules/payment/paypal_standard.php via the class constructor, it calls the constructor for OSCOM_PayPal(). If you go to catalog/includes/apps/paypal/OSCOM_PayPal.php you'll see that there is no explicit constructor function. None should be needed, as there's nothing requiring configuration/set up there. The call to new paypal_standard() in standard_ipn.php happens before the offending line 29 mentioned above, so _app should always have a value. That led me to confirm that the OSCOM_PayPal file was in the correct spot, and accessible. Everything appears correct in that regard, and I don't get any kind of class not found exception being kicked out anywhere. Any ideas, or things to investigate to discover the issue here would be extremely appreciated. This is driving me a bit crazy, and I'd love to have a solution (or at least a decent explanation and work around).
  4. beercityhooligan

    ULTIMATE Seo Urls 5 - by FWR Media

    I have this plugin installed, and it's working great in almost every case. There are some products in my store that have characters in their name that aren't too common, such as ê. When this character exists in the product name, it gets stuck in the URL by the plugin, and the product page will not load when I attempt to navigate to it. The product does show up in the list of products just fine, and when you mouse over the URL has the funny character in it, but looks otherwise legit. When I try to navigate to the product page I get an error page saying that the page cannot be displayed, after it thinks about it for a few minutes. All the other product pages work, but the items that have such characters in their names do not. Can you add some kind translation to convert this character list to their nearest vowel/letter equivalent in the URL? Or perhaps come up with some other solution? Here's the complete list of offenders: ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖÙÚÛÜÝßàáâãäåæçèéêëìíîïðñòóôõöùúûüýÿ I found some related info here: http://cubiq.org/the-perfect-php-clean-url-generator Before I implement my own change, I thought I'd see if you would incorporate a fix for everyone in the package. Thanks for any feedback / help.
  5. I'm having this exact same problem on a client site. I worked through everything mentioned in all 3 pages of this post, and have had no luck. Can anyone offer any advice on how to fix this issue. To reiterate the issue: I've been working on this on and off for weeks. Any advice or direction would be greatly appreciated.
×