Jump to content
Latest News: (loading..)


  • Content count

  • Joined

  • Last visited

  • Days Won


burt last won the day on June 20

burt had the most liked content!

About burt

  • Rank
    I drink and I know things

Profile Information

  • Real Name
    G Burton
  • Gender
  • Location

Recent Profile Visitors

203,458 profile views
  1. I have no interest in a secondary CE version. All (and I do mean 100%) of the feedback I got from both developers and shopowners was; "please stop developing, and fix a release" As soon as I did that...people then decided that this was no good; now I see at least a number of new forks as well as people who have done nothing or incredibly little over the last 5 years, step up and report bugs or do some code or just even start chatting in this forum. Which is really cool, I just wish they had done this 4 years ago :-\ All that said there is one CE version, and that is at the present time called "Frozen".
  2. I have split the chitchat out of this BSv4 thread. Thanks
  3. All the others need to look at WA state. They have an excellent API to hook into to get the exact rates per zipcode, some years back I made a order_total module hooking into it. Very simple and effective system. If WA can do it...
  4. Assuming you only need to collect the STATE sales tax and not individual counties/citys etc...that would be 5 minutes work to set up. That also assumes that you can find the exact tax rate per state etc and so on. Europeans are very used to setting up multiple tax rates, so it's just the same - instead of countries, think States. As for remitting the tax after you've collected...that would be outside the scope of the software, obviously. EDIT: If you have to collect ALL of the applicable sales taxes (state, county, city, district etc)...that would be extremely difficult.
  5. Even if not correct, your change is still not needed. If not correct, they go and change the language file.
  6. I -believe- so. Use Core Code as it stands and look at a product that has a special price, it should be something like; $99.99 $49.99 In other words, old price with a strikethru, special price in red.
  7. Imagine a scenario like this; "This Review was written by John on 01/12/2018. John gave it 5 stars out of 5." I now give you two ways: define('REVIEW_TEXT', 'This Review was written by %1$s on 01/12/2018. %1$s gave it %2$s stars out of 5.'); echo sprintf(REVIEW_TEXT, 'John', '5'); OR define('REVIEW_TEXT', 'This Review was written by %s on 01/12/2018. %s gave it %s stars out of 5.'); echo sprintf(REVIEW_TEXT, 'John', 'John', '5'); OK, both do the same thing. Now take the scenario where shopowner wants to say this: "This Product gets 5 stars from John!" Easier to do this: define('REVIEW_TEXT', 'This Product gets 2$s stars from %1$s.'); No need to even look at the main module file or the template file. In the way you understand (just using %s), an error would probably occur somewhere. At the very least it gets super complicated staying in a linear outlook...
  8. That is exactly what I am saying, so long as you also take into account the placement of variables at the other end (language file). See Mary Lamb example.
  9. Variables can be given in any order, and then used in any order... First See: https://github.com/gburton/Responsive-osCommerce/blob/master/includes/modules/content/product_info/templates/tpl_cm_pi_price.php#L3 sprintf(MODULE_CONTENT_PI_PRICE_DISPLAY_SPECIAL, $specials_price, $products_price) variable 1 = new [special] price variable 2 = old [usual] price Then See: https://github.com/gburton/Responsive-osCommerce/blob/master/includes/languages/english/modules/content/product_info/cm_pi_price.php#L16 I first use #2 (old price) in the <del> I then use #1 (new price) to show the cost Notice the difference between using %s (which is what you are thinking, I think) and use of (eg) %2$s In this way, you can do this: define('BLAH_BLAH', '%1$s had a little %2$s, its fleece was white as snow and everywhere that %1$s went the %2$s was sure to go...'); and echo sprintf(BLAH_BLAH, 'Mary', 'Lamb'); That's a dumb example, but shows the concept.
  10. So, anyway, cards are a PITA. I expect that in future release of bootstrap we will see some card sizing utilities for responsiveness.
  11. YESSSSS! This. SO much this. Thanks @14steve14 People; everything that you see in the basic Responsive Build is done for a reason, always be aware of this before offering solutions that will cause problems.
  12. Now you clearly see the problem. Cards are "nice", but are a PITA to correctly code.
  13. @piernas this approach works but takes away all of the good stuff that Cards brings. The reason for Cards is to entirely remove the Columns and Rows...and make flexbox do its thing without them.