WordPress has ecommerce plugins that allow you to use your WordPress as a shopping cart as well. Occasionally, the ecommerce plugin will not save to the Shopping cart products. When visiting the shopping cart after products are added, the site still says the cart is empty. This is caused by the Sessions save path (session.save_path in the php.ini) not being set to the correct directory.
Known issues with ecommerce plugins
This is a common issue with WordPress ecommerce plugins. The following plugins are known to have this issue:
- WP Ecommerce
- Woo Commerce
Below will show you the steps to fix the sessions path in your cPanel File Manager.
Fixing the sessions problem
This sessions save path is a relatively easy fix. This can be done in the cPanel File Manager. To get the shopping cart to allow the products to add to the cart, you will need to fix the sessions path to the folder location on the server where the sessions ar stored.
- Login into your cPanel.
- Go to the File Manager. Select the Web Root public_html directory and click Go.
- Find your php.ini and edit it.
You will need to change the “Sessions path” in the php.ini for the WordPress Shopping cart.
Update the php.ini save path sits similar to the following.
session.save_path = /tmp
Change the path to the following:
session.save_path = home/username/session foldername
Note! You will need to create a folder in your “Home” directory. You will need to change the name from “foldername” to the name you want the folder to be and the” username” to your cPanel username.
The folder must be writeable with 755 permissions.
Save the changes to your php.ini.
Note! You may need to make the php.ini recursive in the .htaccess to see the changes take effect.
- Test your ecommerce shopping cart again. You should see the cart save the products in the cart now.
Just to be sure of what you are saying…
Right now, when I look at my file structure, it looks like this… (just showing relevant folders)
home
/public-html
/tmp
And when I do things properly, I should end up with…
home
/username
/tmp
/public-html
/tmp
Is this correct? On shared servers?
If I don’t have a php.ini in my /public-html folder, can put “session.save_path = home/username/session foldername” in my site’s .user.ini?
If I have multiple websites in my shared account, like this…
/public-html
/site-2
/site-3
/site-1-index.php
Should each site have it’s own php.ini (or .user.ini) in its root?
Should each site use the same “session.save_path = home/username/session foldername”?
Thank you for any clarification you can provide.
Hi Ken, sorry for the confusion. This article is a bit out of date and refers to the way things worked on cPanel previously. I’ll be updating it now that you’ve brought it to my attention!
The most important difference is that cPanel now uses something called the multiPHP INI editor. Rather than directly editing the files in file manager, simply go to that program in cPanel and make changes there.
A few more things I hope I can clear up: when you open up cPanel’s file manager, you are already in the /home/username folder. That is the default folder you access in a normal shared cPanel account.
That may have been what you meant, but I cannot tell from the way it was typed so I wanted to be sure!
You may be able to resolve everything simply by editing in the multiPHP INI editor, but if you do need to create folders the final result will look something like this:
/home/username/public_html
/home/username/session_foldername_for_public_html_site
/home/username/extra_site_1
/home/username/session_foldername_for_extra_site_1
etc. etc.
I have typed the full path of each directory for the sake of clarity.
You’ll likely want to have a separate session folder for each add on site you have. This is just an educated guess on my part, as we’re getting into custom e-commerce territory and you’d have to ask a specialist developer who knows your plugin for specifics, Unless you have a distinct need to overlap them, I’d keep them separate for now.
You would not want to add any of the above to the user.ini.
Each site will have its own php.ini, yes, though you may not see the file itself now because of the cPanel multiPHP changes I mentioned above!
Lastly, not to throw too many extra details at the issue, but please be aware of php.ini recurision! You usually need to make the php.ini for a site recursive by editing the .htaccess file, but if you have your addon domains inside of public_html, there’s likely going to be some conflict.
To avoid conflicts, make sure you’ve made the php.ini recursive (as per the link above), and the addon domains aren’t inside of public_html. I hope that helps!