MrPhil

You may be able to get past the "please contact us" message: check and install the PHP module "fileinfo" on your server's control panel and see if that clears that up.

I was experiencing this error message, and the fix I was told was to install and/or configure the PHP module "fileinfo" in cPanel. You might give it a try.

OK, thanks, that seems to have done the job. And PM next time! I'll change the pw just to be sure. By the way, I've found a few typos in the English version (both PHP code and SQL). Is there a good place to report those?

OK, here it is. I hope I found and scrubbed out all the passwords, since this is public. logs_28_1695229570.zip

Ah, changing http to https seems to let me now get much deeper into Admin. Thanks! However, trying to go into any of the four sample stores now yields a blank white page with "please contact us if you see this page". Any suggestions? I had to change the security key and flush the OPcache, per instructions.

OK, the forum was down much of the day, but I was finally able to get to it. First, I tried getting into Admin again, but was presented with a warning that the System Status Check had detected "security keys were generated for a different security store key" and gave me a new key to put in params-local.php (I saved the old one). Per the instructions, I went to Settings > Cache Control, selected OPcache, flush. It hung. After a half hour I killed it and did a removal and reinstall. Signing into Admin, I got the warning to save the menus (as before, it took me straight to the Menus page). Pressed F12, Clicked on Network, Clicked on Save and got the same hang as before. The three GET font entries were there before I clicked Save; the POST appeared after. Enclosed is a screen shot at that point -- I hope that's what you're looking for. I see no problem with sending you the password for the admin account (is that the envelope icon at the upper right of this page?). I hope you don't need cPanel access (I'd have to clear it with the site owner). Thanks much for looking at this.

OK, here's what it produced, after bog-standard installation (via Softaculous on cPanel). Go into admin, says "added new categories". Clicked on "see changes", which didn't seem to do anything (still on menus page). X'd out of dialog, click "Save" button. After waiting a while for the thing to finish (it never did), X'd out and when to Settings... and got the logs you requested. Thanks much for looking at this! logs_28_1694730508.zip

Thanks. Let me see how the client wants to handle this. I don't dare try installing V4 on his working store's server (in a subdirectory), as last time it appears to have mangled his working store (2.3.3) and it took quite a bit of effort to fix it. It will have to be on the other server/host, where I currently have a test Phoenix (V3) installation the client is playing with. I would prefer to stick with the Softaculous installer, but if push comes to shove, I can consider a manual installation of V4 (so long as there are clear, cookbook directions).

I am trying to do a test install of V4.12 for a client currently running on 2.3.3. What happens is that it appears to go through the installation (via Softaculous from cPanel) OK, but when I try to use the sample store from either customer or admin side, a pop-up dialog says something about "menus have changed" and that needs to be dealt with first thing. I don't remember the exact wording, as I had to remove V4 in order to try an install of V3 (Phoenix). Anyway, I end up on some kind of menu editor page, and, lacking any more specific instructions, I press "Save" to try to save the "changed" menus. The dialog just spins forever (hangs). I can't get past it. I've tried multiple removals and reinstalls, with the same results. This is the absolutely stock, fresh out of the box, V4 installation. This occurs on two hosting servers the client is trying, HostMonster and GreenGeeks (both Linux, with cPanel & Softaculous), and I tried both PHP 7.4 and 8.0. Oddly, I was able to install OK (at least, without the menu issue) on my personal site (on HostPapa server, again PHP 7.4/8.0 Linux cPanel Softaculous), which I had to delete subsequently. Has anyone seen this kind of problem on an installation, and if so, how did you fix it? Is the Softaculous installer at fault, and I have to install manually in some manner? I seem to have Phoenix working with their current data, but I'm reluctant to recommend going into production with it, as I understand that code base is something of a dead end.

Phoenix 1.0.0.2, not 2.0.0.2?

Have you read the full thread, as well as related ones in the PayPal section? "Login with PayPal" is gone, replaced by "Connect". There are some suggested code changes to get this to work.

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.

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.

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.

I'll include it in the next release of Frozen patches. This is a separate issue from the Login/Connect with PayPal in the other thread, or does it affect it, too?

Is this issue the same as (or related to) ? If it is, at the very least please put a pointer in that thread pointing to this one.

Are the interface and logo unchanged, or is osC's implementation going to have to be completely redone, anyway? It sounds like the latter to me, but I guess it hasn't settled down yet.

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.

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.

Login with PayPal has been changed to Connect with PayPal. See if anything in helps you.

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

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.

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

should be now()); insert Any idea how it got corrupted?

No, but it sounds like your store has a problem. What are these error reports (debug emails) telling you? Very similar problems? Do you need to check whether an upgrade is needed on your USPS module? (Wasn't there one recently?) Did your host just upgrade PHP? Have you been hacked?