Jump to content

burt

Team
  • Content count

    15,336
  • Joined

  • Last visited

  • Days Won

    634

Everything posted by burt

  1. Change: btn-group To: btn-group-vertical d-flex AND; undo everything else you've done. eg centering. If you do not want the buttons in a group (ie so they do not "touch" each other); Remove the buttons from the block entirely and add btn-block and margin on each button. So; Change: <div class="btn-group" role="group"> To: <div> and each button (eg) as so; 'btn-light btn-product-listing btn-buy btn-block my-1'
  2. Never used this addon, so cannot comment in any meaningful way. Does the addon call on its own class file ?
  3. Try it? STORE_COUNTRY is always set. So you would replace the whole block of shonky code with that 1 liner.
  4. // DOES SHIPPING_ORIGIN_COUNTRY exist if (defined("SHIPPING_ORIGIN_COUNTRY")) { // IF YES if ((int)SHIPPING_ORIGIN_COUNTRY > 0) { // SET SHIPPING_ORIGIN_COUNTRY to an integer (number). // THis will always be "0" if SHIPPING_ORIGIN_COUNTRY IS set BUT is not an integer $countries_array = tep_get_countries((int)SHIPPING_ORIGIN_COUNTRY, true); $this->country = $countries_array['countries_iso_code_2']; //// note 1 - is an INT if(!strlen($this->country) > 0) { //when country failed to be retrieved, likely because running from admin. $this->country = $this->country_iso('', (int)SHIPPING_ORIGIN_COUNTRY); } } else { $this->country = SHIPPING_ORIGIN_COUNTRY; //// note 2 - is not an INT } } else { // IF NO // this will never be set to anything $this->country = STORE_ORIGIN_COUNTRY; ///// note 3 - is unset } SO: Note 1: define('SHIPPING_ORIGIN_COUNTRY', 223); $this->country = 'US'; // most likely (assuming 223 is the US in your database) Note 2: define('SHIPPING_ORIGIN_COUNTRY', 'US'); $this->country = 'US'; Note 3: and if SHIPPING_ORIGIN_COUNTRY is not defined at all; $this->country IS NOT SET and will likely error out;
  5. burt

    Paypal Standard Payments Failing

    Upgrade to the Paypal App; https://apps.oscommerce.com/fZMiN&paypal-app This app is written specifically for 2.3.4 shops.
  6. burt

    Paypal Standard Payments Failing

    @saxcbr please put in a ticket to Paypal.
  7. burt

    Paypal Standard Payments Failing

    @Cary did you get a ticket into Paypal. The more replies back from them, the easier it is to get a fix.
  8. It's perfectly OK to disagree. It is what makes the world go round. All the old code dating back to 2001 is available, so for anything taken out...put it back to suit your needs.
  9. burt

    Paypal Standard Payments Failing

    @cdetdi please get a ticket in to Paypal. Let's see what they have to say to you as well as what they say to @Cary and @Mac Fly as well.
  10. Lots of things get removed/changed in order to facilitate the forward movement of the codebase. Filenames and DB tables - easier installation of addons/apps Cache - antique system. Actually slowed down Phoenix in testing. The beauty of the open code base is such that anyone can add it back in to suit their needs.
  11. burt

    Paypal Standard Payments Failing

    @Cary @Mac Fly
  12. Please also (as @Mac Fly has done) raise a support ticket with Paypal. Let's see what they have to say (to both)...
  13. That is a two-way street. As you say, never mind.
  14. You have asked that question via PM and you got your answer via PM. Yet here you are, stirring the pot of negativity. <--- that is why
  15. Says the guy who got chucked out of the Phoenix club for an attack on another member. LOL.
  16. Yeah, there's a few in this forum who would prefer to see osCommerce dead rather than have me as the one pushing it forward.
  17. Fake News. It stops today. Take this as a friendly reminder to be positive instead of constantly negative.
  18. user.css https://github.com/gburton/CE-Phoenix/blob/master/user.css This would be located in the root of your Phoenix installation.
  19. burt

    attribute prices

    On a backburner.
  20. burt

    attribute prices

    This is something that is still on the to-do list. It was arranged with a developer for this backport (along with modern updates) to be done and put into Phoenix Core but "things didn't work out" so although it was at an advanced stage, it had to be put on the backburner. I'm still hopeful we can somehow revive [Henry was going to do it and not sure if he is still available/interested] it but it's a long way off I think due, as always, to budget.
  21. burt

    Phoenix Dashboard

    Malcolm artcoinc and I posted pretty much the same thing at the same time. All code is on github, fill your boots. We've got some really nice things in the pipeline.
  22. burt

    Email queuing system

    It did get finished but it turned out to be one of the projects where things didn't quite go according to plan, and the code ended up not being ready for public release. I do plan to revisit it soon as part of the Phoenix Updating process as this system (or something similar) would supercharge outgoing (and incoming) customer contact.
  23. @TomB01 Exactly this. This is the main reason why I output updates in bite-size chunks on a fairly regular basis. It allows those who want to keep up-to-date the ability to do it in an easy 5 or 10 minutes. It also allows those who can't or don't want to take that time to come back to it at a later date or even to disregard the point updates entirely and just do an update blowout on each .0 release. Point being; take your time. If there was anything super important to get done "NOW" (eg if a insecure thing appeared or some show-stopping bug was introduced between versions) I'd be sure to mention that in the relevant version update post to try to get shopowners to get that part of an update done pronto.
  24. I usually just do everything bar the configuration and configuration_group tables (which are the two "controlling" database tables). Then make sure that all the tables I just brought over have the same columns [and settings] as a core Phoenix.
  25. We (that is Henry and I) months back, had plans to update the DB schema to make things uniform across tables. customer_id, customers_id, customers_info_id => customer_id language_id, languages_id => language_id and so on. This would make the possibility of doing some super things with joining and filtering and reporting etc. But as with loads of other things, it's on a backburner as there are loads more important things in the list. Sorry that doesn't answer the Q, but is somewhat related. It's on the to do list.
×