Jump to content

MrPhil

Members
  • Content count

    8,156
  • Joined

  • Last visited

  • Days Won

    111

Reputation Activity

  1. Like
    MrPhil got a reaction from mcmannehan in What's the sence?   
    Your observation is correct that it's redundant code. Presumably the author meant to get the fields name, type, size, and tmp_name from somewhere else, if $_FILES[$this->file] wasn't available. Does anyone have any idea where these fields might come from?
  2. Like
    MrPhil got a reaction from edoscript in Login with Paypal   
    IIRC, 5.010 is indeed the last full installation, and there are a number of incremental updates following it, up to 5.018. I haven't looked to see if all the updates will be applied in one "update" click, or if you have to update several times to get to 5.018, but you might want to keep an eye on what it's doing. I recall that there are gaps in the sequence (i.e., there are not 8 updates to get to 5.018).
    There have been some recent changes to PayPal (e.g., Connect vs Login), so 5.018 isn't the last word, but I think Harald has to manually do some code changes to bring it up to date. I don't know what his plans are there.
  3. Like
    MrPhil got a reaction from valquiria23 in Frozen   
    Well, your frustration is understandable, but new software releases are a fact of life. You can continue to run Frozen for a while (especially if you patch it), even past its official EOL, but don't push it too far. A lot of people get into deep trouble by trying to hold on to releases years after they're obsolete. My biggest concern is getting Frozen and Phoenix past PHP 7.1, as hosts are starting to make 7.2 their minimum.
    The database should be very close to (if not the same as) Frozen, but the only way to tell for sure is to do a test install of Phoenix (or look at oscommerce.sql) and compare the database schemas (structures). My understanding is that it's mostly going from Bootstrap v3 to v4, and maybe the admin side is now BS'd. I would assume that a number of bugs have been quashed, but I haven't had a chance to look at it yet. Maybe later this summer.4
    I keep telling people that when they install a new version of osC, they should keep careful track of every single change they make, and every single add-on installed, and why the change was made. This makes it so much easier to transfer to a new base install.
  4. Like
    MrPhil got a reaction from Smoky Barnable in Thoughts on the review system   
    Well, the most obvious thing is to permit only confirmed actual purchasers with an account to post reviews. State that clearly, to improve trust. That should keep out fake reviews. The store would have to keep around purchase records for some period of time, say, one year (bar reviews after that period), and could automatically check that the account did in fact purchase this very item within the last year.
    As to the ability to respond, especially to refute bad reviews (not necessarily to censor or edit them, just present the store's side of the story), that sounds useful. I'm not sure that it would be good to permit a back-and-forth (a conversation), as that can get out of hand pretty quickly in this day and age (when almost everyone online lacks any civility whatsoever). One review per account, up to one response by the store.
  5. Thanks
    MrPhil got a reaction from alex121121 in Auto Update Currencies   
    If the code only looks at the time of day, and doesn't keep track of the day on which it was last run, it's not very good code. Anyway, if you can't run a proper "cron" job, look at "poor man's cron" examples that do track when the last time something was run was, and kick off the run if enough time has passed. Such code would be started from some place in osC such as application_top.php. I think there may be a poor man's cron in one of the mass mailing add-ons, where you don't want to dump an avalanche of emails on the system, but just dribble out a few at a time, then wait for the next run of osC that's a few minutes later. I don't know if anyone has generalized a PMC to run arbitrary modules at arbitrary times/dates, but that would be a great feature for osC.
    Perhaps you would be better off if you worked with your host to understand what their limitations are on cron jobs. It's understandable that they want to keep out-of-control scripts off their servers, but cron is a necessary part of any non-trivial website. You got burned once by not understanding what they allowed, but that doesn't mean you can't craft a cron job that they will allow.
  6. Like
    MrPhil got a reaction from alex121121 in Auto Update Currencies   
    Does your host actually not let you run cron (on a Linux server), or do they restrict the kinds of things you can run, such as PHP scripts using 'php'? Mine does the latter, but they allow using cURL to run PHP scripts.
  7. Like
    MrPhil got a reaction from valquiria23 in Curious find in Edge/Frozen regarding definitions   
    Certainly, you don't want to release something with known serious errors, but as a practical matter you can't get rid of every single bug, nor can you find every possible bug. You have to choose between getting something decent out to market in a reasonable time, and releasing something perfect years from now (don't worry, someone will find a bug immediately!).
    If this is Edge being released as a sanctioned branch (i.e., not the official osC release), well, that's almost useless. If it's not an official 2.3.5 or whatever, the server distributions (Softaculous, etc.) will never pick it up, and osC will continue to suffer under the 2.3.4.1 official release.
  8. Like
    MrPhil got a reaction from valquiria23 in Curious find in Edge/Frozen regarding definitions   
    Certainly, you don't want to release something with known serious errors, but as a practical matter you can't get rid of every single bug, nor can you find every possible bug. You have to choose between getting something decent out to market in a reasonable time, and releasing something perfect years from now (don't worry, someone will find a bug immediately!).
    If this is Edge being released as a sanctioned branch (i.e., not the official osC release), well, that's almost useless. If it's not an official 2.3.5 or whatever, the server distributions (Softaculous, etc.) will never pick it up, and osC will continue to suffer under the 2.3.4.1 official release.
  9. Like
    MrPhil got a reaction from peterbuzzin in Discussion about Hard Coded Database Tables   
    Interesting. Can you elaborate on how this is supposed to work? I assume it means that any ad-hoc hard-coded queries will fail to be updated on the fly, and only those going through a "proper" glue layer will get the desired prefix (hello, broken add-ons). I'm wondering how that is any improvement in readability and execution speed over TABLE_* constants in code (yes, they need to be looked up and substituted too).
     
    If it's a clean way to add a prefix to all osC tables, that might be usable, although I can think of cases where you might want to prefix only selected tables (e.g., while testing a change where you have a different table structure, and want to preserve the old one for possible reuse). Any thoughts on this?
  10. Like
    MrPhil got a reaction from peterbuzzin in Discussion about Hard Coded Database Tables   
    OK, some hosting accounts are limited to one database, so if you want osC in addition to another application, you have to be careful that your table names (all in the same database) don't collide. The easiest way to do this is with a prefix, such as osc_. Now, if your table names are hard coded (inline) everywhere, you have to look at every possible place that a table name is mentioned, and change it there. That, instead of changing it one database_tables.php file. A one time job, you say? How about if you want to run two copies of osC, such as a production and a development copy with osc1_ and osc2_? You have to do it again. Use global search and replace, such as the sed utility? OK, instead of "TABLE_PRODUCTS" you have "products". How do you easily keep from hitting an innocent text string in a comment or message, rather than just where it's used as a table name? I suspect that those clamoring for table names to be inlined for clean code, simply haven't thought it through all the way.
     
    On the other hand, I can't think of any legitimate reason a user would need to change file names, so inlining file names is probably harmless. Examples of harm are welcome.
  11. Like
    MrPhil got a reaction from Smoky Barnable in Thoughts on the review system   
    Well, the most obvious thing is to permit only confirmed actual purchasers with an account to post reviews. State that clearly, to improve trust. That should keep out fake reviews. The store would have to keep around purchase records for some period of time, say, one year (bar reviews after that period), and could automatically check that the account did in fact purchase this very item within the last year.
    As to the ability to respond, especially to refute bad reviews (not necessarily to censor or edit them, just present the store's side of the story), that sounds useful. I'm not sure that it would be good to permit a back-and-forth (a conversation), as that can get out of hand pretty quickly in this day and age (when almost everyone online lacks any civility whatsoever). One review per account, up to one response by the store.
  12. Like
    MrPhil got a reaction from jamieereynoldss in Do I need permission to use beauty product pictures on a website?   
    Just remember that taking your own pictures, while protecting you from copyright violation claims, does nothing to protect you from claims that you are infringing on a trademark. You still should get permission to carry and promote a product.
  13. Like
    MrPhil got a reaction from Smoky Barnable in Transactional email service   
    I think we've got 2 or 3 different issues mixed together here:
    Excessive volume of emails (exceeding host's per-minute, per-hour, per-day caps). You need to find out from your host what the limits are. Unless they are ridiculously low, or your site is very, very busy; routine emails such as order confirmation should not be a problem. Newsletters and other such mass-mailing rates have to be low enough to not to interfere with routine emails. It's possible that you will need to use an external service to handle newsletters and other mass mailings. Newsletters and other "not necessary" communications (mass mailings) have to be explicitly "opt in", to avoid legal problems and accusations of spamming. Don't forget in every mailing to right at the top remind the reader that 1) they had signed up to receive the communication, and 2) how to easily unsubscribe (without reporting your store as a spammer). If your host (or other systems, such as Yahoo or Gmail) are flagging the content of any of your emails as spam, you will need to adjust the wording and contents to pass the spam tests. Certain words, certain phrases, an excessive number of links, etc. might have to be changed.
  14. Thanks
    MrPhil got a reaction from cDGo IT Consultancy in Forum Changes   
    Harald, I have said it before, and I'll say it again:
    You cannot leave a product unattended for more than 12 months, or the ecommerce market declares it dead. You must have a major refresh or release at least annually, to stay in the public mind as a "current" product. The official product (currently 2.3.4.1) is the one that "one button" installers will pick up. That's the one that all newcomers will be using. It must be kept current. It doesn't matter if @burt's dazzling BS4 responsive PHP 7.3-ready plutonium-powered incredible edible edition is "available" on the main page -- that's not the one installers will pick. It would be best to take Frozen + patches and rebrand it as osC 2.5 (since 2.4 is already taken), and make it the official release. At least that will buy some time for a newer edition to be developed. If your work isn't ready by early 2020, Gary's BS4 edition could be 2.5.1, buying another year's grace. It's a very bad habit to not keep the current release updated, on the expectation that your work will be ready (Gold) Any Day Now -- history has shown that never happens, and these things slip for years. It doesn't matter how wonderful whatever you're working on will be -- it may well be the greatest thing since sliced bread, but if it's been more than a year since the last update, it will be starting from scratch in the public marketplace. In fact, it's worse than that -- it will have to first dig itself out of the "osCommerce is dead, dead, dead" hole before it's even in the race. Please declare everything earlier than (official) 2.3.4.1 to be immediate End of Life, and bar any further support discussion, except for how to migrate to the current version. 2.3.4.1 and Gary's CE works should go EOL in a year or so. Let's clear the decks of all the ancient stuff, and get everyone to the new 2.5 (a.k.a. Frozen) and eventually to whatever you release. Yes, tools are needed to make migrations less painful. If this feels like a bucket of ice water poured over your head, it's meant to be. Time to wake up!
  15. Like
    MrPhil got a reaction from Smoky Barnable in Transactional email service   
    I think we've got 2 or 3 different issues mixed together here:
    Excessive volume of emails (exceeding host's per-minute, per-hour, per-day caps). You need to find out from your host what the limits are. Unless they are ridiculously low, or your site is very, very busy; routine emails such as order confirmation should not be a problem. Newsletters and other such mass-mailing rates have to be low enough to not to interfere with routine emails. It's possible that you will need to use an external service to handle newsletters and other mass mailings. Newsletters and other "not necessary" communications (mass mailings) have to be explicitly "opt in", to avoid legal problems and accusations of spamming. Don't forget in every mailing to right at the top remind the reader that 1) they had signed up to receive the communication, and 2) how to easily unsubscribe (without reporting your store as a spammer). If your host (or other systems, such as Yahoo or Gmail) are flagging the content of any of your emails as spam, you will need to adjust the wording and contents to pass the spam tests. Certain words, certain phrases, an excessive number of links, etc. might have to be changed.
  16. Like
    MrPhil got a reaction from valquiria23 in Domain change, SEO and new oscommerce site version   
    Can you show us the full .htaccess file on both sites, and which directory they're in? ***-out any sensitive information. You don't have anything on your new site redirecting back to the old site, do you? Your description of what is happening is very confusing. Is this happening on the old site or the new site? If it's on the new site, it should have nothing to do with the redirection from the old site. Are both sites on Apache servers, or did you change server types?
  17. Like
    MrPhil got a reaction from valquiria23 in PayPal App v5.018 Log In with PayPal is now dead   
    Pete, "Frozen" has PayPal Pro built in -- it doesn't use the paypal-app you linked to. However, it's at 5.010, so my concern is whether you need to install, configure, upgrade, and then apply the patches above, or if the Frozen files could be updated ahead of time (via my Frozen patch). The best would be to update Frozen (via patches) to PayPal 5.018 so that when installed, it's there (along with the patches above). No further manual operations for the store owner. I will try to find a Frozen implementation that's been updated to 5.018, and compare files, and see if I can first update my Frozen patches to 5.018, then apply the patches found above. That would be the most desirable thing for anyone using Frozen.
    Update: I've started looking at the PayPal app vs. what's in Frozen. A lot of the differences in Frozen are trivial stuff -- use of $_GET/$_POST, __construct, hard coded file and table names, etc. However, it looks like Frozen is still at PayPal 4.039 while the app is 5.010. There are a lot of non-trivial differences between the two that will take some thinking about (which one is correct to use). Then, there is still the issue of various fixes proposed in this and other threads, and whether they can be applied to 5.010, and whether it's possible to upgrade Frozen to have 5.018 out of the box. (does the "upgrade" change the PHP files?) This is not going to be quick.
  18. Like
    MrPhil got a reaction from valquiria23 in Ezsocial for osC2.3.4BS v1.0a   
    Since Google+ has mostly gone away, should we be thinking about removing it from stores? I never used it, but my understanding is that it's only available for "G Suite", whatever that is. Do the Google+ functions on osC still do anything, or are they just an embarrassment that osC hasn't been updated in ages? If it should go away, I can add that to my Frozen patch set. It will be up to others to fix Edge and the official product.
  19. Like
    MrPhil got a reaction from valquiria23 in Confusion over osC Versions.   
    OK, Peter, let's draw a diagram:
    +--------------------------------------------------> osC 2.3.4.1 ------------------------------------> ??? | (official) basically suppress PHP 7 warnings osC 2.3.4 ---+ (official) | Gary Burton's now 2.3.4.1 +---- CE stream -----> Gold (snapshot) ---> known -----> changes -----> Frozen (snapshot)----> Edge continues on GitHub as Edge incorporated development BSv3 store only modularity, PHP 7 BSv4 both sides PHP 7.2 That, as I understand it, is more or less the history of osC over the last 4 years or so.
    Forget about "Gold". It's an obsolete snapshot. The "Frozen" snapshot is a quite stable, but needs a few patches. It is BSv3 (on the public store side only, not on admin). Gary has stated that he intends to make no further changes to Frozen -- that's what it literally is. He is working only on "Edge", with BSv4 responsive on both sides (store and admin), and some level of PHP 7.2 compatibility (eventually fully). It is a work in progress.
    There is no such thing as "Frozen BS4". It's either Frozen (with BS3) or Edge (with BS4), unless someone has their own private fork. In that case, they should make it very clear when discussing on this forum what they're talking about.
    Most people should use Frozen (plus patches), unless they want to be on the bleeding Edge of development. If what you want is a working store, I'd stick with Frozen. If you have the time and skills, and enjoy working with a constantly-changing code base, Edge could be for you.
    Yes, Frozen should be officially released as osC 2.5, but I'm not holding my breath. Yes, naming and versioning could be much improved by Gary, to reduce confusion. Only one repository is needed, as Gold and Frozen are fixed in time and space.
  20. Like
    MrPhil got a reaction from valquiria23 in modal info popup   
    I've run into problems with the popup manager. It would only edit or delete the first popup listed. I traced this to confusion in the code over when to use 'pID' and when to use 'popups_id' in the URL Query String (input and output -- it was a mixture of both). Basically, all popups_id= in building an href have to be changed to pID=, all $_GET['popups_id'] change to $_GET['pID'], and all '&pID=' in building a UQS apparently have to be just 'pID='. Leave $_POST['popups_id'] alone. Using pID consistently to mark which is the selected popup (for editing or deletion) seems to work.
    I'm still having problems with expired popups remaining active. Looking through the code, it looks like it is very confused in how it's implemented, like someone started with one train of thought and changed back and forth. For instance, the date_scheduled and expires_date get set to NULL, but status is still 1 (so it keeps being displayed). I'm not sure this setting the date fields to NULL when changing status was thought through all the way. I also have popups with a future expiration date having their expires_date field cleared to NULL for no apparent reason (possibly when clicking the "Activate" green button).
    I propose to change things a bit. status=0 would mean "not desired to be shown (by owner)", and status=1 would mean "desired to be shown". Instead of only 0 or 1 popups with status 1, any number could be 1. In cm_footer_pop_up.php, instead of playing with status when start/end dates are explicitly given, just loop through each status=1 popup (ordered by date_added, descending order). Check if date_scheduled (start) is NULL (started long ago) or in the past AND expires_date (end) is NULL or in the future, and output this popup. In popup_manager.php, the green/red light status change simply changes status to 0 or 1 for this one popup (doesn't affect others). The popups are again ordered by date_added, descending order. So, the first popup encountered in a specific order (most recently added to least) where status=1 (desired to show) and it falls within the given start/end dates, will be run. If an undesired one runs, the owner would have to temporarily deactivate the offending popup. In both cases, if expires_date is found to be in the past, status will be forced to 0. In neither case will start/end dates be changed to NULL.
    I think that this behavior would be closer to what a user would intuitively expect to see. What do you think (especially @Mikepo and @JcMagpie)? If Mike wants to update his add-on with the revised code, I can send it as a zip file once I've tested it and am happy with the behavior.
  21. Like
    MrPhil got a reaction from valquiria23 in Confusion over osC Versions.   
    OK, Peter, let's draw a diagram:
    +--------------------------------------------------> osC 2.3.4.1 ------------------------------------> ??? | (official) basically suppress PHP 7 warnings osC 2.3.4 ---+ (official) | Gary Burton's now 2.3.4.1 +---- CE stream -----> Gold (snapshot) ---> known -----> changes -----> Frozen (snapshot)----> Edge continues on GitHub as Edge incorporated development BSv3 store only modularity, PHP 7 BSv4 both sides PHP 7.2 That, as I understand it, is more or less the history of osC over the last 4 years or so.
    Forget about "Gold". It's an obsolete snapshot. The "Frozen" snapshot is a quite stable, but needs a few patches. It is BSv3 (on the public store side only, not on admin). Gary has stated that he intends to make no further changes to Frozen -- that's what it literally is. He is working only on "Edge", with BSv4 responsive on both sides (store and admin), and some level of PHP 7.2 compatibility (eventually fully). It is a work in progress.
    There is no such thing as "Frozen BS4". It's either Frozen (with BS3) or Edge (with BS4), unless someone has their own private fork. In that case, they should make it very clear when discussing on this forum what they're talking about.
    Most people should use Frozen (plus patches), unless they want to be on the bleeding Edge of development. If what you want is a working store, I'd stick with Frozen. If you have the time and skills, and enjoy working with a constantly-changing code base, Edge could be for you.
    Yes, Frozen should be officially released as osC 2.5, but I'm not holding my breath. Yes, naming and versioning could be much improved by Gary, to reduce confusion. Only one repository is needed, as Gold and Frozen are fixed in time and space.
  22. Like
    MrPhil got a reaction from peterbuzzin in Confusion over osC Versions.   
    I can't agree with Gary's reasoning on this. Since it's obvious that Harald will never legitimize Frozen as the official osC 2.5 (and later, some form of Edge as 2.5.1), it's time to stop bending Frozen to try to fit with the news and updates stuff. Just comment out all the code that interacts with updates and "latest version" items, and put up a "check GitHub here for latest version(s)." Or something like that.
    What developers keep losing track of is that most of the users of osC are business people, not computer nerds. It is unreasonable to expect them to dig through source files to find vague and confusing version stamps, and to have to remember the exact date on a zip file! They're just trying to run their business, and the more roadblocks we put in their way to making it relatively easy to manage their online store, the more of them will desert to easier-to-use platforms. What most want is a selling appliance, not a whole new career. The whole mess of ancient official versions (why in 2019 do we still have to tell newbies that they installed the wrong version?) and "Frozen with BSv4" fiascos couldn't be better designed by a competitor to sink osC.
  23. Like
    MrPhil got a reaction from peterbuzzin in Confusion over osC Versions.   
    I can't agree with Gary's reasoning on this. Since it's obvious that Harald will never legitimize Frozen as the official osC 2.5 (and later, some form of Edge as 2.5.1), it's time to stop bending Frozen to try to fit with the news and updates stuff. Just comment out all the code that interacts with updates and "latest version" items, and put up a "check GitHub here for latest version(s)." Or something like that.
    What developers keep losing track of is that most of the users of osC are business people, not computer nerds. It is unreasonable to expect them to dig through source files to find vague and confusing version stamps, and to have to remember the exact date on a zip file! They're just trying to run their business, and the more roadblocks we put in their way to making it relatively easy to manage their online store, the more of them will desert to easier-to-use platforms. What most want is a selling appliance, not a whole new career. The whole mess of ancient official versions (why in 2019 do we still have to tell newbies that they installed the wrong version?) and "Frozen with BSv4" fiascos couldn't be better designed by a competitor to sink osC.
  24. Like
    MrPhil got a reaction from Demitry in Database Optimizer   
    Keep in mind that it's more than just changing function names mysql_ to mysqli_. Some parameter lists in the calls will also be changed, so you need to check those.
  25. Like
    MrPhil got a reaction from valquiria23 in modal info popup   
    I got it working after comparing every file line-by-line. Something got munged moving the JS code in and out of template_bottom and other places. In the process, I found a few minor glitches:
    admin/includes/languages/english/popup_manager.php   line 27 indefinitely.. -> indefinitely.   line 49 glag -> flag admin/popup_manager.php  line 182  why is po.popups_id in the SELECT twice? Should one of them be pod.popups_id? I see pod.popups_id = po.popups_id in the WHERE clause. It seems to work as-is, but I think later versions of MySQL may get upset that pod.popups_id isn't listed in the SELECT clause. admin/popup_manager.php  line 228 includes class="ckeditor" on a textarea. I don't think that CKEditor is built in to Frozen. Is it harmless to leave it in that class, and you get some benefit if you happen to install CKEditor? includes/languages/english/modules/content/footer/cm_footer_popup.php   line 4  one every page -> on every page includes/modules/content/footer/cm_footer_popup.php  line 22  function cm_footer_popup(   ->  function __construct( install.txt  is misleadingly simple. After copying in the files, you need to go to Admin > Modules > Boxes > available boxes to install and order it to install the Popup Manager (or whatever it's called... it's gone now). You might note that nothing will show up in the installed Boxes list -- it goes into the Tools menu. Thanks to the (late) De Dokta, Mike, and Zahid  for their work on this.
    My client wants two things:
    Not only have a Close button, but also to automatically go away after 10 seconds. Does adding this after   $('#popupModal').modal('show'); in includes/modules/content/footer/templates/tpl_cm_footer_popup.php // disappear after 10 seconds setTimeout(function() { $('#popupModal').modal('hide'); }, 10000); look like it would do the job? Since popups would have varying amounts of information, maybe the time delay (10 seconds here) should be a parameter in the popup database entry. '0' second delay would mean "don't go away until explicitly dismissed" (and should be the default).
     
    Does this work cleanly on small devices? I'm wondering if a large image size would cause scrolling on a phone. I don't think customers would be pleased to have an important message disappear before they're done scrolling around the read the whole thing! Maybe it would be better just to stick to the Close button.
×