Jump to content

Upgrade from 6.1.5 to 6.2.2 Incomplete


Recommended Posts

Hi, I have upgraded from 6.1.5 to 6.2.2 and everything is working as it should. All features are working but manually. Example once anything changed via admin panel, I would have to manually go to Maintenance and clear cache for changes to show. It's like everything and all new features are working but no new clear cache tab on admin panel, nor order status color and etc.

I thought maybe upgrade failed and reverted to 6.1.5 and tried again. But I have now reverted to 6.1.5 and upgraded back to 6.2.2 about 10 times and all features seems to be working, but I can't get the clear cache tab to show on admin panel. I have to manually clear the cache. Has anyone faced this problem or have a fix? As mentioned I've have tried downgrading and re up grading about 10 times and still no luck in getting the clear cache tab on admin panel. Any feedback would be appreciated.

 

Thank you!

Eddie

 

Link to comment
Share on other sites

Please verify if the following code exists. But first, examine the contents of the file /includes/global.inc.php. For the variable ['adminFolder'], note its value.

Using that value as the name of the folder to start traversing through, then in that folder, traverse through skins, default, templates.

Examine the file common.breadcrumb.php. Lines 7-8 should look like:

      <li id="clear_cache_master"{if $CLEAR_CACHE} class="clear"{/if}><a href="{$SKIN_VARS.clear_cache_link}">{$LANG.maintain.cache_clear}</a></li>
      <li id="help_menu"><i class="fa fa-life-ring" aria-hidden="true"></i> <a href="#">{$LANG.common.help}</a>

If this isn't what the file in your installation looks like, then look for another folder that starts with admin, or is just admin. Traverse that other folder and examine the file found there.

The correct administrative folder will be the one that has the code as shown above.

Edit the global.inc.php file so that the variable ['adminFolder'] has the correct folder name.

 

Link to comment
Share on other sites

Back to soon lol... I guess I spoke to soon as that only worked until I logged out from admin. So I changed the global.inc.php file back to old admin folder and everything working. I then went and in sted of changing the global.inc.php file, I actually uploaded the correct admin files and over rided the old admin files. And everything then went well, had all admin new features and clear cache showing on admin. But I couldn't change anything via admin panel without getting an error ** Security Alert: Possible Cross-Site Request Forgery (CSRF). Please do not use multiple tabs/windows or the browser back button. Learn more.** on anything on admin changes, and also when trying to login to admin panel once signed out. End of story had to re upload the old admin folder and back to none new features on admin panel lol... 

I'm assuming that I will have to wait for another upgrade, and then simply upload the new admin files to the correct admin folder, then proceed and hope for luck because I've tried everything in the books to get this issue fixed and can't get pass for nothing in the world once everything is correct the error of (Security Alert: Possible Cross-Site Request Forgery (CSRF). Please do not use multiple tabs/windows or the browser back button. Learn more.)

Well Thanks again for the help guy's. It did work as I mentioned, but just until I logged out of admin, and couldn't get pass the god dawm (Security Alert: Possible Cross-Site Request Forgery (CSRF). Please do not use multiple tabs/windows or the browser back button. Learn more.)

 
Link to comment
Share on other sites

No luck as well. I just downgraded back to 6.1.5 and re upgraded to 6.2.2. And I can't get into admin panel at all. This error on all browsers even clearing cookies and all on all browsers won't let me in  Security Alert: Possible Cross-Site Request Forgery (CSRF). Please do not use multiple tabs/windows or the browser back button. Learn more.nSecurity Alert: Possible Cross-Site Request Forgery (CSRF). Please do not use multiple tabs/windows or the browser back button. Learn more. more.

Link to comment
Share on other sites

I'm screwed just restored backup again and simply can't get in to admin panel with this error. My god this don't even make sense to me. Does anyone knows how to overide or get around this error: Security Alert: Possible Cross-Site Request Forgery (CSRF). Please do not use multiple tabs/windows or the browser back button. Learn more.

Any feedback would be appreciated..

 

Thank you!

Eddie

 

Link to comment
Share on other sites

Hey bsmither,

That actually worked thanks. I'm able to get in to admin atleast and until I can try to figure out what's causing this issue. Most likely I'll simply leave it along for today since I'm brain burnt from trying so many things in getting this error corrected. It's crazy that I can get it to work using the old admin files even doe it's upgraded to 6.2.2.

I just have to get this figured out, but thanks again for the help always buddy.

 

Thanks!

Eddie

 

Link to comment
Share on other sites

13 hours ago, themixtapechannel said:

I'm screwed just restored backup again and simply can't get in to admin panel with this error. My god this don't even make sense to me. Does anyone knows how to overide or get around this error: Security Alert: Possible Cross-Site Request Forgery (CSRF). Please do not use multiple tabs/windows or the browser back button. Learn more.

That error often occurs when you have the admin.php file (or hopefully it renamed) from a different version of CubeCart to the files in /admin directory (again hopefully renamed) - yet another common error when trying and failing to do an upgrade fully

Link to comment
Share on other sites

Hey Moderator, thanks for the reply and help effort. But the first thing that I always check for correct settings are in the config.inc.php, admin_xxxx and admin.php and etc. There all correct and all match, that is why I simply don't undertand the error. I left it alone yesterday since I followed bsmither info and was able to get in to admin.

I'll have to go back at it when possible and with a fresh mind to see if I can figure it out. I even down graded back to 6.1.5 about 10 times, and back up to 6.2.2 and still was getting error. And in both issues I was using well matched old and new databases to match the downgrade and upgrades, still had no luck as mentioned. Well as mentioned I gave up last night. Will try again with a fresh brain to see if I over looked anything which I dought.

 

Thanks Again always,

Eddie

Link to comment
Share on other sites

  • 1 year later...

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.

Link to comment
Share on other sites

We were investigating this just recently in another forum conversation. (Was that with you?)

That other conversation asked if the server was on a Windows box and if the PHP version was 7.0.x. (I'm not aware if there was a resolution to that person's situation.)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

Quote

PHP:
[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/session.class.php:647 - is_writeable() [function.is-writeable.php]: open_basedir restriction in effect. File(/var/lib/php/session) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxxx.com/:/tmp/)[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/autoloader.class.php:89 - file_exists() [function.file-exists.php]: open_basedir restriction in effect. File(/opt/plesk/php/7.3/share/pear/smarty_internal_data.class.php) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxxx.com/:/tmp/)[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/autoloader.class.php:92 - file_exists() [function.file-exists.php]: open_basedir restriction in effect. File(/opt/plesk/php/7.3/share/pear/Smarty_Internal_Data.php) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxxx.com/:/tmp/)[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/seo.class.php:616 - preg_match() [function.preg-match.php]: The /e modifier is no longer supported, use preg_replace_callback instead[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/seo.class.php:616 - preg_match() [function.preg-match.php]: The /e modifier is no longer supported, use preg_replace_callback instead[Notice] /var/www/vhosts/xxxxxxxxx.com/httpdocs/admin_xxxxx/sources/settings.index.inc.php:323 - Undefined index: email_method_smtp_tls[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/autoloader.class.php:89 - file_exists() [function.file-exists.php]: open_basedir restriction in effect. File(/opt/plesk/php/7.3/share/pear/smarty_internal_resource_file.class.php) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxxx.com/:/tmp/)[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/autoloader.class.php:92 - file_exists() [function.file-exists.php]: open_basedir restriction in effect. File(/opt/plesk/php/7.3/share/pear/Smarty_Internal_Resource_File.php) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxxx.com/:/tmp/)[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/autoloader.class.php:89 - file_exists() [function.file-exists.php]: open_basedir restriction in effect. File(/opt/plesk/php/7.3/share/pear/smarty_template_compiled.class.php) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxxx.com/:/tmp/)[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/autoloader.class.php:92 - file_exists() [function.file-exists.php]: open_basedir restriction in effect. File(/opt/plesk/php/7.3/share/pear/Smarty_Template_Compiled.php) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxxx.com/:/tmp/)[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/autoloader.class.php:89 - file_exists() [function.file-exists.php]: open_basedir restriction in effect. File(/opt/plesk/php/7.3/share/pear/smarty_internal_runtime_foreach.class.php) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxxx.com/:/tmp/)[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/autoloader.class.php:92 - file_exists() [function.file-exists.php]: open_basedir restriction in effect. File(/opt/plesk/php/7.3/share/pear/Smarty_Internal_Runtime_Foreach.php) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxxx.com/:/tmp/)[Notice] /var/www/vhosts/xxxxxxxxx.com/httpdocs/admin_xxxxx/sources/element.navigation.inc.php:41 - Undefined index: title_bulk_prices[Notice] /var/www/vhosts/xxxxxxxxx.com/httpdocs/admin_xxxxx/sources/element.navigation.inc.php:47 - Undefined index: nav_email_log 

 

Link to comment
Share on other sites

If debug is not enabled (and you can't get into admin), do this:

Go to:
http://www.whatismyip.com
to learn what the world sees as your workstation's IP address.


In includes/globals.inc.php, add these lines *above* the last line:


$glob['debug'] = '1';
$glob['debug_ip_addresses'] = 'YOUR_IP_ADDRESS';

Then we can start adding some diagnostic code to the function, the one that ultimately produces the CSRF Error, that will show some results in the debug panel.

The first Warning (and all warnings that follow) is indicative of an incorrect system configuration.

[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/session.class.php:647 - is_writeable()
          [function.is-writeable.php]: open_basedir restriction in effect.
          File(/var/lib/php/session) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxxx.com/:/tmp/)

Please send this to your hosting provider. They should know what to do about it.

Whether that fixes CC628's CSRF problem remains to be seen.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

13 hours ago, bsmither said:

The first Warning (and all warnings that follow) is indicative of an incorrect system configuration.

[Warning] /var/www/vhosts/xxxxxxxxx.com/httpdocs/classes/session.class.php:647 - is_writeable()
          [function.is-writeable.php]: open_basedir restriction in effect.
          File(/var/lib/php/session) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxxx.com/:/tmp/)

Please send this to your hosting provider. They should know what to do about it.

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.

Link to comment
Share on other sites

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:

 

Quote

 

Cause

PHP script is trying to access the folder for which access is not allowed. This restriction is limited by the PHP open_basedir variable for each virtual host separately. By default, open_basedir is set to allow access for PHP files to the tmp and httpdocs directories.

Resolution

Note: If you are a domain owner and the open_basedir setting is not available for you, please contact your service provider for assistance.

Adjust the value of open_basedir in order to include missing path from the error message:

  1. In Plesk, go to Domains > example.com > PHP Settings.

  2. Modify the value of open_basedir:

    • For Linux

      Below is an example of including the directory /var/lib/php/session to open_basedir:

      {WEBSPACEROOT}{/}{:}{TMP}{/}{:}/var/lib/php/session

    • For Windows

      Below is an example of including the directory E:\custom_folder\sessions to open_basedir :

      {WEBSPACEROOT}{/};{TMP};{/};"E:\custom_folder\sessions\"

  3. Apply the changes.

 

So I did that and now I see Smarty needs other directory access and other warnings about missing variables:

Quote

[Warning] /var/www/vhosts/xxxxxxxx.com/httpdocs/classes/autoloader.class.php:92 - file_exists() [function.file-exists.php]: open_basedir restriction in effect. File(/opt/plesk/php/7.3/share/pear/Smarty_Template_Compiled.php) is not within the allowed path(s): (/var/www/vhosts/xxxxxxxx.com/:/tmp/:/var/lib/php/session)

[Warning] /var/www/vhosts/xxxxxx.com/httpdocs/classes/autoloader.class.php:92 - file_exists() [function.file-exists.php]: open_basedir restriction in effect. File(/opt/plesk/php/7.3/share/pear/Smarty_Internal_Runtime_Foreach.php) is not within the allowed path(s): (/var/www/vhosts/xxxxxx.com/:/tmp/:/var/lib/php/session)

[Notice] /var/www/vhosts/xxxxxxx.com/httpdocs/admin_xxxxx/sources/element.navigation.inc.php:41 - Undefined index: title_bulk_prices

[Notice] /var/www/vhosts/xxxxxx.com/httpdocs/admin_xxxxx/sources/element.navigation.inc.php:47 - Undefined index: nav_email_log

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:

Quote

[Warning] /var/www/vhosts/xxxxx.com/httpdocs/classes/seo.class.php:616 - preg_match() [function.preg-match.php]: The /e modifier is no longer supported, use preg_replace_callback instead

[Warning] /var/www/vhosts/xxxxxxx.com/httpdocs/classes/seo.class.php:616 - preg_match() [function.preg-match.php]: The /e modifier is no longer supported, use preg_replace_callback instead

[Notice] /var/www/vhosts/xxxxxxx.com/httpdocs/admin_xxxx/sources/settings.index.inc.php:323 - Undefined index: email_method_smtp_tls

[Notice] /var/www/vhosts/xxxxxxxx.com/httpdocs/admin_xxxx/sources/element.navigation.inc.php:41 - Undefined index: title_bulk_prices

[Notice] /var/www/vhosts/xxxxxxx.com/httpdocs/admin_xxxxx/sources/element.navigation.inc.php:47 - Undefined index: nav_email_log

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!

 

 

Link to comment
Share on other sites

The /e modifier fix was put in place in cc626. (See: https://github.com/cubecart/v6/pull/2220)

PHP will post Notices about undefined variables and indexes. It is a courtesy to the programmer to double-check the spelling of variables. PHP will not crash if a variable is not first defined with a default value before other code asks for its contents. This programming style - not to worry about pre-defining variables - provides fuel for those who flame PHP as not being a real programming language.

I see in the open_basedir errors the file being wanted is in the /pear/ directory. So, you may have a disconnect between CubeCart's implementation of an autoloader (perhaps using an include path), and the paths that open_basedir is configured to allow.

I am not a Linux person at all. Tried it - binned it.

Link to comment
Share on other sites

6 hours ago, bsmither said:

The /e modifier fix was put in place in cc626. (See: https://github.com/cubecart/v6/pull/2220)

I figured since I was so far behind in updates that it was probably fixed in 6.2.x.

6 hours ago, bsmither said:

PHP will post Notices about undefined variables and indexes. It is a courtesy to the programmer to double-check the spelling of variables. PHP will not crash if a variable is not first defined with a default value before other code asks for its contents.

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.

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...