Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by MrPhil


    For anyone who's curious, Linux patch files are not the recommended way to request updates to projects that are on GitHub.

    They're Windows "fc" output, not Linux patch. I feel it would be a waste of time to set up a whole repository for this one set of changes, especially as GB is likely to ignore PRs (we've, ah, exchanged words in the past). Actually I'm hoping that the community here would be willing to push for changes.


    In general, there is no need to comment out code that is in source control. 

    If these were true patch files, that would be a legit complaint. But I want to provide some context, and these changes are going to have to be manually examined and OK'd anyway...


    I would also point out that if you make your living from Phoenix and do not support it, Burt is not going to be terribly interested in changing comments and language files to support you.  From his perspective, he is already doing work for free for you in providing the functionality in the releases.  Now you want him to do more work in an area where he really doesn't care.  And other than your pedantic corrections, you're not willing to contribute anything.  Not even the time to learn how to make coding contributions in a format convenient to him. 

    I am trying to help out here. I guess I should refrain from suggesting to my clients that they purchase some of GB's modules. I don't make much of my living from Phoenix, and if that's going to be the reaction from the community, I'll just leave and find a more profitable use of my time. Regarding "pedantic" corrections, these are high visibility glitches that tell non-computer types that the people who put out osCommerce just don't care about even trying to look competent. "Welcome on [my store]?" I won't blame GB for most of them -- they look like mistakes that non-native English speakers (or poorly educated Americans) would make. A polished, professional-looking product is a big selling point among business people (who are the majority of osC shop owners).


    I personally would oppose some of these changes, e.g. converting double spaces after periods to single spaces.

    OK, that's a debatable one, but I prefer to have the text file match as closely as possible. It's also confusing to non-computer savvy people (like shop owners) trying to find certain text strings by searching for a pattern with one space, when there are two in the file. Even I have had problems with that.


    And I'm not terribly excited at the idea of adding verbose comments to cover off-the-wall situations like Options -Indexes not working. 

    It's actually quite a common problem, terribly baffling to non-computer experts. The more help we can give these people, the better they'll feel about choosing osC. Or, we can make it a sadistic intelligence test. I don't care.


    Nor do I favor adding cryptic comments like "(MINIMUM Tare Weight)" to the configuration description.

    If a merchant shipping stuff doesn't know what a "tare weight" is,  they've got problems. The original text was positively misleading, giving a totally wrong idea about how total shipping weight was calculated. The tare is actually a fixed percentage of the total product weight, with a MINIMUM amount (applicable for small shipments). I'm just adding some information that I would hope would be useful for a shop owner to understand what's going on. I also added a fix so that purely virtual orders (no physical product shipped) wouldn't get tagged with the minimum shipping weight. (I carried that over from Frozen -- is it no longer necessary?)


    Adding comments to the sample data SQL to talk about files in the images/sample directory is not productive.

    Well, if you've got a better suggestion, I'm listening. If there are instructions anywhere on loading the sample data, perhaps that would be a better place. I put the comment in just in case someone would be wondering where and how they load the sample images if they want the store samples.


    The same way it currently prompts people to remove the .github directory.  The contents of which you apparently haven't read, as it explains the process to make pull requests.

    I've been wondering why the .github directory is shipped with the product. Totally useless. And I do know how to make a PR, but explained up top why I choose not to. Don't get snarky over this!


    I would agree with changing "setup" to "set up" and "checkout" to "check out" when used as a verb, but I really doubt that you can find a way to make that exciting to Burt.  I notice that you don't change login to log in.  Perhaps that means that I changed them all already.  But I wouldn't bet on it. 

    I looked for incorrect "login" and didn't see any, so maybe you already caught any. As for GB not finding it "exciting" to make such mundane corrections, well, I find a polished, professional-looking product to be more exciting (and appealing) that something crappy looking. Tastes vary, I guess.

  2. I have some clients using older osC versions that I upgrade to Phoenix. I'm fine with that, except that there are a number of silly errors in the code that I need to fix at each Phoenix release, and I'd really like to see GB incorporate the following changes into (or soon after). They are in two attached files. One is 'fc' (file compare) format, which Linux tools may be be able to read, but each change should be manually examined anyway.




  3. 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.

  4. 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.

  5. 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.

  6. You've got two entirely separate things here: 1) conversion of the DB from old schema to new, and 2) selective editing of DB content. I wouldn't try to mix them -- do (1) then (2).

    You'll often get yourself in trouble if you try to transfer table-by-table. I find it better to change the DB layout (schema) from old to new in one go, and then edit content at my leisure, either in the .sql backup, or on the live DB using phpMyAdmin.  My preferred method is to dump both the old and new databases in .sql file format, including the table creation commands (which gives you the layout). It's not rocket science to compare each table, field-by-field, and update the old DB's .sql file; it's just painstaking and meticulous work. If there are add-ons and other customizations to the old store, that is really the only way to do it. If new fields are added, you may have to synthesize appropriate data for them.

    Has anyone come up with a tool yet to take an old .sql dump and a new one, and generate the SQL needed to update the old DB to the new one's schema (leaving alone add-on changes)? You'd still have to eyeball the SQL to check what it's doing.

    Of course this requires getting your hands dirty in the depths of the database, and is not for the faint of heart. So long as you keep a backup of the database you're modifying, and know how to use that backup to restore the DB (if you've modified a live one on the system), you shouldn't cause a catastrophe -- you can always start over.

  7. If it's just some orders, and it's fairly old osC code, I've seen this problem with customers failing to properly return to the store after completing payment. That is, they "back" up or otherwise go off someplace else from the PayPal site, and never return to the store to complete the transaction. This assumes it's a PayPal mode that takes the customer offsite (to paypal.com).

    I think that some of the more recent osC versions may have code to successfully complete the transaction even if the customer never returns (but PayPal signals that it completed). You might look around at that (and discussion on this forum). Otherwise, it's operator error. About the best you could do is to put in a BIG REMINDER before they're sent off to the PayPal site that they need to come back to your store in a certain way, for the transaction to complete.

  8. On 5/21/2019 at 6:21 AM, peterbuzzin said:

    I know I said about creating a separate thread (and I hope you still do)

    At this point, I see no reason to carry this further, here. If you think there are security problems, feel free to start a new topic/thread and continue that part of the discussion there.

    On 5/21/2019 at 6:21 AM, peterbuzzin said:

    Without escaping them someone could easily perform Cross-Site Scripting (XSS) client side attacks/injections on form fields.  The $HTTP_POST_VARS and $HTTP_GET_VARS were a creation of do_magic_quotes_gpc() function in compatibility.php and even if they referred to the now deprecated PHP variables names offered basic protection against XSS.  Is there compensation for this by the use of a similar function to loop through all $_POST and $_GET arrays in frozen before they're used?

    Perhaps someone more familiar with the work and reasons for changing to the short forms ( @burt ?) could speak to this. Has Pete found an area of legitimate concern, or is he mistaken? In places where these superglobals could potentially be used to inject nasties, I was under the impression that cleanup was done on a case-by-case basis rather than globally. Of course, this does increase the chance that some case will be overlooked! Are "magic quotes" still around? I thought I heard about their being withdrawn.

    Certainly, we should always be on the lookout for places where $_* could be used to inject malicious code. Should cleanup be restricted to places where it could actually be used to do something bad (in HTML sent back to the browser, in database fields, etc.)? Is there such a thing as a universal cleanup that could be done?

  9. It appears that there are incremental updates past 5.010. Do I have it right that I manually bring Frozen up to 5.010 with the PayPal app, and then apply the incremental updates 5.011,  14, 16, and 18 to be fully 5.018 ready? And then keep an eye open for further 5.xxx updates to come? I guess that HPDL is somehow keeping up to date with PayPal patches.

  10. I'll look at the PayPal app update some more. I just want to be very careful not to break things! My end goal is still to have Frozen 5.018 out of the box. It's just that Gary's version baked into Frozen is 1) apparently 4.039, and 2) has been updated for various CE-related global changes. It looks like Harald's PayPal app was updated to 5.010, but lacks compatibility with Gary's CE changes. I'm hoping that maybe Gary will adopt the Frozen patch for PayPal 5.018 into Edge.

    1 hour ago, peterbuzzin said:

    What were the reasons for removing them, why is it a bad thing?

    Well, originally PHP had $HTTP_POST_VARS and $HTTP_GET_VARS arrays. These were removed (or at least, deprecated) a long time ago, replaced by $_POST, $_GET, and $_REQUEST. osC kept copies of them (the long names), mostly to avoid the work of changing them, until Gary decided to bite the bullet and change them in his CE work. I think the scoping rules are a little different between the old and new array versions. I seem to recall that the argument was it was better to get in line with the new way of doing things, and fix old add-ons, than to continue to muddle along with the old way of doing things and confusing people.

  11. You now have "french" language files (no missing files, but might still have English text in them), and you're still getting exactly the same error messages about missing files? Very strange. Does your server have some sort of cache that hasn't been updated yet? Are the permissions on the new files valid (644 is typical)? And of course, you copied them to the right place on the right live server? You didn't edit any of these files and have the editor leave a Byte Order Mark in them?

  12. On 5/16/2019 at 5:11 AM, peterbuzzin said:

    Hi Phil,

    I'm not familiar with Frozen/patches but I'm sure it's/they're not too different.  First question: can PayPal in Frozen auto-update like it can in the default/stock osC PayPal App?  If it can then the change is likely to be overwritten at some point.  If there's updates available it would be a good idea to update first and then apply the changes for the fix and then apply them to the repository of where the codebase lives for auto-update.

    I'm happy to look over this and use my code comparison tools.

    Again not familiar with Frozen but generally with osC it's best not to use naked $_POST/$_GET in code (as you're probably aware already) and as long as application_top.php is loaded before the PayPal files then those variables will available via $HTTP_POST_VARS and $HTTP_GET_VARS as declared by includes/functions/compatibility.php which also escapes special characters if need be.

    Yes, Frozen's PayPal (it appears to be an earlier version of the PP app built right in) has a working Update button. I'm still looking at the differences, and where the code will come from upon pressing the Update button. I'm also concerned about a future update (say, beyond 5.018) regressing to incompatible code (e.g., expecting $HTTP_POST_VARS, etc.). If it's code maintained by HPDL, that's a very real possibility. If it's from PayPal, it still might happen.

    "best not to use naked $_POST/$_GET"  could you offer some justification for that? It's been generally agreed upon that maintaining the old HTTP_ arrays is a bad thing, and one of the things @burt has been doing in the "BS" versions is changing all of them to the modern $_POST and $_GET forms. It would be stunning to discover that was a bad move!

  13. I would strongly advise you to start debugging with the first error message (the possibly missing "french" language files). There's no telling what sort of cascade of effects are coming from that -- if you're quite fortunate, all your problems might go away with fixing that! Besides, it's an easy fix (just copy in "english" files for the time being, until you find or make a French translation). Might as well attack easy things first.

  14. It says that includes/classes/payment.php is trying to use some file in includes/languages/french/modules/payment/. The first thing I'd check is whether includes/languages/french/modules/payment/ has French versions of all the modules that you want to use that are found in the "english" version, as shipped (includes/languages/english/modules/payment/). There will be some English text in those files that will (eventually) need translating. With luck, that will be your problem. At least, you can see if just copying the "english" files you need for your payment method(s) gets you past the current problem. There may be other empty "french" directories that need similar treatment.