Jump to content
Latest News: (loading..)

Ben23

Members
  • Content count

    11
  • Joined

  • Last visited

Profile Information

  • Real Name
    Ben Wheeler
  1. Ben23

    Mail Manager for OSC v2.3

    Also missing was the definition for EMAIL_TEXTHTML_STATUS_UPDATE. I added this to admin/includes/languages/english/orders.php: define('EMAIL_TEXTHTML_STATUS_UPDATE', '<p>Your order has been updated to the following status.</p>' . "\n\n" . '<p>New status: <b>%s</b></p>' . "\n\n" . '<p>Please reply to this email if you have any questions.</p>' . "\n");
  2. Ben23

    Mail Manager for OSC v2.3

    I think this instruction was supposed to be for catalog/includes/languages/english/tell_a_friend.php Also, it results in a subject line that says that the recipient has recommended it! ie, if A sends the recommendation to B, then it says "B has recommended..."! I fixed this by changing line 25 of catalog/includes/modules/mail_manager/tell_a_friend.php from $output_subject = $to_name.' ' .TEXT_RECOMMEND.' '. $product_info['products_name'].' '.TEXT_FROM.' '.STORE_NAME; to $output_subject = $from_name.' ' .TEXT_RECOMMEND.' '. $product_info['products_name'].' '.TEXT_FROM.' '.STORE_NAME; as I think it makes more sense to have the originator in the subject anyway rather than the recipient. Also to fix the product image in the recommendation email, I changed line 35 of this file from $product_image = tep_image($image_urlfix.DIR_WS_IMAGES . $product_info['products_image_med'], $product_info['products_name'], '', '', ''); to $product_image = tep_image($image_urlfix.DIR_WS_IMAGES . $product_info['products_image'], $product_info['products_name'], '', '', '');
  3. Oh yes, one more thing. When a date range filter is in effect, it would be great if it would apply to the sub-tables that unfold as well as to the main table. For example, if I set a date range of say 1st-7th May 2015, then I get only the May 2015 line in the main table which is correct, but if I then click the (+) button, the expanded table shows the sales figures for every day in May, whereas I would expect it to only show the sales for the 1st-7th. The other filters *do* seem to be applied to the expanded view, just not the date filter.
  4. Hi I've just installed this module (on a modified 2.3.4+Bootstrap Gold) and I have to say it's a fantastic piece of work. Easy to install, looks spiffy, loads of features, and significantly higher code quality than the majority of OSC modules! Thankyou so much for all the work that's gone into it. I have a couple of minor bugs to report. The first one is with the Customer filter, which fails with the following error in the Apache log: PHP Fatal error: Call to undefined method mysqli_stmt::get_result() in /var/www/hht/hhtadmin/advanced_statistics/ajax_request.php on line 93 Looking at the documentation for that function at http://php.net/manual/en/mysqli-stmt.get-result.php, it says it's only available with mysqlnd. Since you claim at the top of this thread that mysqlnd should not be required, does this need rewriting to use a different method? Or is mysqlnd essential for this to work? I'm using PHP 5.4. The second concerns the menubar. At the moment, only the leftmost icon (which keeps changing - presumably this is intentional but it makes it harder to describe to users what they should be looking for) has a decent tooltip describing what it does. The rightmost one (which is showing as an "unknown character" glyph on my system) also has a tooltip but it is needlessly tall and narrow: see attached screenshot. The other three icons are not showing tooltips at all, thus they have no explanation what they do. And one further suggestion: It took me a while to figure out how to close the filter sidebar (by clicking outside it), so how about adding a Close button inside it just to avoid any frustration. Thanks again for your excellent work.
  5. Ben23

    Stripe payment option not recognizing discount coupon amount

    Thankyou AdmiralRedBeard! I ran into this same problem with Paypal when using a CCGV coupon - Paypal would claim it was going to debit the discounted amount, and the order would show the discounted amount, and yet the actual amount being taken by Paypal was the full pre-discount amount. It was doing my head in, but your solution is right on the money, so to speak. $payment_modules->before_process() needs to be called *after* $order_total_modules->process() in checkout_process.php, as it is in the stock 2.3.4, whereas CCGV's version of this file inexplicably moves it to the wrong place. It would be good to get a fixed version of CCGV uploaded if anyone has access to do that; this is bound to bite other people. Thanks again.
  6. en_UK is not normally a valid locale. For the UK you should use en_GB. The I18N code mainly determines the language of the text (day names, month names, prev, next etc) that appear within the datepicker. The en_GB code does also set dateformat to dd/mm/yy. So if you use this (or you set JQUERY_DATEPICKER_FORMAT to dd/mm/yy separately) you probably also need to make the change to tep_date_raw() that I outlined earlier as well, because that always expects date in mm/dd/yy.
  7. Ben23

    AJAX Attribute Manager support

    Greetings all I've just installed this module on a shop, and I just wanted to say a massive THANKYOU to Nimmit and everyone who has worked on it over the years. It is a thing of beauty. The installation is straightforward and quick, and doesn't require manually hacking away at a billion files like most OSC add-ons. It doesn't even require any manual database fiddling. The file layout is modular and self-contained, thus easy to upgrade and to use on different versions of OSC. The widget itself is well designed and although it looks complicated at first, it's intuitive enough to figure out quickly, and does the job superbly. It makes a complicated thing (the handling of attributes/options) a thousand times simpler and faster - especially with the Templates feature which is truly inspired. If only all OSC add-ons were like this! So, good job, and my heartfelt thanks to everyone involved. Ben
  8. I think you need to change tep_date_raw() - note that it expects to receive the date as mm/dd/yyyy (and pays no attention whatsoever to the DATE_FORMAT* etc constants), so you need to change the substrs to swap over the positions of month and day if you are providing it as dd/mm/yyyy So change function tep_date_raw($date, $reverse = false) { if ($reverse) { return substr($date, 3, 2) . substr($date, 0, 2) . substr($date, 6, 4); } else { return substr($date, 6, 4) . substr($date, 0, 2) . substr($date, 3, 2); } } to function tep_date_raw($date, $reverse = false) { if ($reverse) { return substr($date, 0, 2) . substr($date, 3, 2) . substr($date, 6, 4); } else { return substr($date, 6, 4) . substr($date, 3, 2) . substr($date, 0, 2); } } Better yet, this function should be rewritten to parse the date using the appropriate date format constant... this is left as an exercise :)
  9. Yes I've read that. My concern is that since the last GOLD release, Responsive-OScommerce:master has become a mixture of some Bootstrap-related fixes, and a lot of random stuff that seems like it belongs in the mainline OSC repo instead. But maybe that doesn't matter if the plan is for OSC[r] to be merged back to OSC soon anyway? I'd like to start contributing (to OSC and OSC[r]) via github, but the lack of clear separation is confusing me as to where I should be punting my PR. I have what should be a simple thing to contribute to start with: Category names aren't currently escaped when sent to the screen in some places, and they should be. The difficulty is there's a difference between the mainline and BS versions - the BS version appears to be worse. So do I have to do two PRs, or can I just roll it up into one and send it to Responsive because that will feed it into mainline OSC in due course anyway?
  10. Hi guys. First of all, massive kudos to everyone involved in this project, it is much needed. Secondly though, I see there have been a number of recent changes in the github project which have nothing to do with getting it working with Bootstrap, but are instead changes to the core OSC code. These include things like changing intval() to (int), and while(list($foo,$bar) = $array) to foreach ($array as $foo=>$bar) I'm concerned that including core changes like this that don't have anything to do with the Bootstrapification will make it harder to merge into sites that use a lot of add-ons, because with every additional diff, you increase the risk of a conflict needing to be manually resolved. And in many cases these changes don't seem to add enough value to justify that risk. For the sake of cleanliness might it be better to keep the Responsive project only for the changes necessary against stock 2.3.4 to make it responsive, and leave everything else to the mainline oscommerce project? Or at least have a branch which is "pure" in this way - just the *minimal* set of changes required, without this extra cruft?
  11. Ben23

    Paypal / OSC Rounding Totals

    This is a common problem with various shopping cart software, not just OSCommerce. Google "Paypal VAT rounding" and you'll find a whole heap of examples. It generally occurs if you are setting exact figures for the Gross (inc VAT) price, and letting the system calculate the Net (ex VAT) price. This can result in a Net price with more than 2 decimal places. Within the e-commerce software, the net total is summed from the exact net prices, but when the prices are sent to Paypal, they round each price to 2dp and sum the result of that. For example, say you have a product whose gross price is 9.99. The system will calculate the net price as 8.325. But Paypal will round this to 2dp before applying the VAT. They will probably round it up to 8.33, which results in a total of 10.00. But even if they were to round it down to 8.32, then the total would be 9.98. You simply cannot get a gross price of 9.99 from a 2dp net price. This is the crux of the problem. There are various ways around it: Set your products to all have 2dp net prices. This means that certain gross prices will be impossible, such as 9.99. Send gross prices to Paypal and tell it not to add VAT. I don't know if this is legally ok. Don't send individual items to Paypal, only the net total, and pre-round it in such a way to ensure that the gross total will be the same after adding VAT. But you will still have problems if your gross total can't be obtained from a 2dp net. Alter the price of one of the items to account for the discrepancy, as seen this example for Magento. That's an interesting idea, but may result in the user seeming to be charged more than they should have for that item. Out of all of these, I would be minded to keep it simple and go for the first one. It's very easy to achieve in MySQL, assuming that your products table contains net prices as it should: UPDATE products SET products_price = ROUND(products_price, 2); Of course this will result in some of your gross prices changing by a penny, but will at least ensure that the Paypal total matches the OSCommerce total. You can also ensure that this remains the case by changing the field type so that it only has 2dp: ALTER TABLE products CHANGE products_price products_price DECIMAL(15,2) NOT NULL; This will ensure that any price entered with more than 2 decimal places gets rounded to 2dp. You might also like to change the javascript that calculates the net from the gross and vice versa, so that it does it to 2dp. In admin/categories.php, there are two calls to doRound() with 4 as the second argument - change that to 2. If your shipping prices are set including VAT then you may need to change them as well.
×