Jump to content

KirkM

Member
  • Content Count

    124
  • Joined

  • Last visited

  • Days Won

    1

KirkM last won the day on December 6 2014

KirkM had the most liked content!

Community Reputation

3 Neutral

Profile Information

  • Location
    Kapaau, HI
  1. First, I have to apologize for hijacking this thread. I was just trying to get resolution for the same issue and let it get away from me. Last thoughts on this PHP discussion and then back to only trying to find solutions to the issue of this thread: What makes PHP so great is that you can learn more easily because of its built-in tolerance. I would have quit on day 2 when I started learning the language if I ran into an execution brick wall every time I tried to run a script that wasn't pristine. I don't think I am alone on that one. However, I have been accused of being slightly detail-obsessed ("YOU'RE A LUNATIC!"), ahem, so PHP also allows you to get things as refined as you like using the errors display detail in development. I like this approach even though it may increase my code by a tad here and there but may help me from shooting myself in the foot downstream: From the PHP Manual: From PHP documentation on using empty() as an alternative to isset(): From stackoverflow community wiki: Their recommended solution: Since I have a dedicated server to host my SaaS data management systems, I can use PHP 7.3 and the null coalesce operator in a process or function where a variable may or may not be present and I can satisfy my obsessiveness. If there is any way I can shoot myself in the foot, I will find it, so it is best for me to try to minimize the chances everywhere I can. OK, PHP tangent over, back to topic. This is interesting. And as I think about it, I am wondering if it is as simple as not changing the obscured admin.php file to the new version code and only uploading the new admin.php file. I honestly can't remember for sure if I did, but if that is the case, I will be kicking myself. (REALLY hate that obfuscation approach to the admin) I have done the upgrade so many times and then restore to the old version I can't remember all of the things I tried. I will give it another go in a bit and see if that is actually the error I am making.
  2. I figured since I was so far behind in updates that it was probably fixed in 6.2.x. Yes, I am familiar with these PHP traits (and its detractors) writing SaaS programs for many years now. Of course, I always write on my testing server with all warnings and notices displayed and was taught not to let a single one ever show under any scenario before pushing to production. And that there should always be conditionals and other catches to account for any situation the script might legitimately encounter so there are never anything that would trigger a notice or warning unless something is actually wrong with the script execution for whatever reason. Since I know Al's work is top-notch and wouldn't intentionally throw warnings and notices, my concern is that something is wrong with my server setup or CC installation. Hosting a couple of CC stores is kind of an "on the side" thing for me now with just a few legacy clients from way back in the CC v3 and v4 days. I haven't kept up on the code under the hood for many years and boy has it changed from back then! I am in the middle of development for 3 new data systems and was just trying to get this upgrade off of my plate. Of course it couldn't go smoothly like in the past, that would be just too easy! I will have to wade upstream in the CC code and see what the source of these notices are, and I might actually have to take a look at debugging and reconfiguring the neglected webspaces these things are on so they run the stores properly. Again, thanks for your help.
  3. So, it appears it is specific to some php scripts requirements and CC is one of those. The php session path default is correct at /var/lib/php/session but the open_basedir has to be modified from default to allow the script to use it. This article explains it and offers the fix: So I did that and now I see Smarty needs other directory access and other warnings about missing variables: I find it surprising that CC can't run on a default Centos 7 box with Plesk panel without all of this extended access. So everyone with a default Centos / Plesk setup has to do php access customization to run CC correctly? I have been using CC since V3, I believe, and it has always worked (with the occasional fixable issue). I never even ran a debug on it since I didn't have any reason to. I also have never had to change those settings for any of my scripts or third party scripts such as Wordpress and Joomla. Evidently I have been completely clueless about proper php.ini access setup all these years. It has always been about customizing upload size, timeouts, post max size, etc. So now, with the extended access for sessions and Smarty, I have these warnings left: The top 2 are just making the cart php 7.3 friendly. As far as the missing variables go, I don't know if that is also a problem specific to my setup or bugs in CC. This is becoming quite the CC education for me!
  4. I am my hosting provider (dedicated server from IONOS) and I am a little at a loss. If I understand this correctly, it says that my php config only allows tmp on the root of the domain (open_basedir restriction). I have 35 data systems running on my server that all use php session cookies and don't have any issues like this and none have a literal tmp file in the domain root. My php.ini file is set on default for open_basdir and all seems to work, from custom data systems to Wordpress sites. I am not a linux guru by any means, so I will have to investigate this further to see why only CC has issues. Thanks for your help and guidance with this.
  5. Thanks. I already had my IP in the admin panel for the debug so I know what it is. I will have to wait on the next attempt to upgrade as my client is getting a bit weary of his store being down for hours at a time often, even if it is overnight. I have made multiple attempts to set up a store clone on my Mamp Pro server on my MBP, but I can't seem to get it to work correctly on simulations of upgrades. I use it for all of my data systems programming as my test server and it works great. I just can't get CC to simulate production, or even work when it comes to test upgrading a store. Have to get back on this once a bit of time has passed and this store client will be a bit less chafed about the downtime.
  6. I have had to restore back to 6.1.13 so the client can do business. I obviously can't enable it after the upgrade since I can't ever log in, but I could enable it beforehand and it would be on when I upgrade. I just did a very quick grab on the 6.1.13 page that enables debugging and got a ton of warnings. Not sure if anything would be relevant to the 6.2.8 update, but here they are for 6.1.13 (sanitized) anyway:
  7. Thanks for that. I hadn't seen that post but it is similar although I can't even get into admin because I get the CSRF message when I submit the username and password. All good in 6.1.13 but it just won't work on 6.2.8 no matter what I do. I have wiped the cache, all sessions, the browser cookies and replaced every file in the store with no luck. I think if it were a PHP issue, there would be a lot more people on here with the same problem. I get the tokenization to prevent CSRF attacks but I really wish CC didn't do this thing with the admin file and admin folder being obfuscated. I was taught many years ago that "security by obscurity" was generally bad practice and isn't really very effective, if at all. It just makes maintaining and upgrading CC stores more complicated and error-prone. Anyway, here's an interesting bit that I had happen that I think is a clue, but I am not sure where to go with it. On one of my upgrade attempts, I forgot to modify the obscured admin folder and only did the straightforward admin folder. I don't have any mods in that entire thing so it was just a complete replacement with the one from 6.2.8. But the obscured folder was left as is with the 6.1.13 files. Everything worked, because it used the 6.1.13 obscured folder to upgrade. It appeared that the storefront and database was 6.2.8 but the admin was the old version without the new features in 6.2. The big thing is that both the store and the admin worked. As soon as I realized that the admin was not updated, I dumped the 6.2.8 files into the obscured folder and immediately got the CSRF error and couldn't log in anymore. I have tried so many things in upgrading attempts but nothing works. I always get the CSRF error trying to log into the admin after upgrading. With no mods there and completely wiping the old admin file content in both the obscured folder and the plain admin folder, I am banging my head against the wall trying to figure out why it won't work.
  8. No, it wasn't me. This is on a Centos 7 box with Apache/Nginx server and PHP 7.3x. I looked at all the threads about this I could search but could you link that thread so I can make sure I didn't miss it? Thanks
  9. Any resolution to this? I have the same issue going from 6.1.13 to 6.2.8. I have tried everything in every forum post and done the upgrade a dozen times and I still get the CRSF error when I try to log into admin. This is making me nuts. If I restore from my server backup, all is fine in 6.1.13. I will have to tell my clients that they are stuck with 6.1.13 and can't go any further since I just can't figure it out. I have even deleted all the files before uploading the 6.2.8 to make sure that there wasn't any stray old files from v4 or v5. Any help would be greatly appreciated.
  10. Oh man, I am an idiot. I just realized I was updating everything in the admin/sources directory locally with my web editor and then uploading with it. I completely forgot about that very strange feature of CC to copy and rename the admin folder on the server with a random _xxxxx to obscure the login page from bots. I do see the purpose, but it is kind of an oddity that I have never seen before and still can't get used to it in my workflow. I need to remember to push the modified admin folder back to my local site files after upgrades (or at least rename it the same) so it syncs with the right folder. I fixed THAT one and it is now working. Thanks for your time on this. Sorry it was a wild goose chase.
  11. No edits have been made to this file, but I went back and replaced it from the original CC download and added the edits. Same issue. Chrome developer tools network info shows 200 OK. Putting the xml link directly in the url window returns valid xml. CC is just hanging on something somewhere in this script's process.
  12. Yes, there is a log generated and there are lots of warnings. error_log.txt
  13. Just a blank page either way with me. Might have to wait for the next version with all the fixes and upgrade my client's store to that and see if it fixes it.
  14. Still just the blank page. Where is the second https you mention? There are only 2 actions listed here, one is to change the http to https and the other to add the $request->setSSL(); line. I don't see a second change from http to https in these two steps.
  15. Did this and still won't work for me. Running CC 6.1.13 and PHP 7.2.9. Anywhere else to make modifications besides the two places mentioned in this resolution?
×
×
  • Create New...