Cannot modify header

Whenever I checkout with a registered account be it old or new I get the error as per the attachment
Error log says the following:
2016-03-30 7:09:30 - PHP Notice: unserialize(): Error at offset 0 of 10 bytes in /home/maxoraadmin/public_html/catalog/controller/journal2/checkout.php on line 271
2016-03-30 7:09:30 - PHP Warning: Cannot modify header information - headers already sent by (output started at /home/maxoraadmin/public_html/index.php:102) in /home/maxoraadmin/public_html/catalog/controller/journal2/checkout.php on line 489

There is no problem to checkout if using guest

On the basis that the error is with the journal 2 onepage checkout, you might want to ask for support from them.

H glommy.rm,

Perhaps this will be of use in the future:

2016 - Why are there so many Terrible themes?!

I had it fixed and was told it was a session creation problem.
Not sure what that means.

Have them explain it to you... tell you what they did.

They changed your tmp data save location from global to local as i presume you are using a cloud based hosting solution.

they added a line below to your php.ini file or created a .user.ini file with a line of code

adding an local absolute path to your tmp directory, for example

session.save_path= "/var/sites/d/dev.mysite.co.uk/public_html/tmp/"

your host will need to give you the absolute path for your website, or you might be able to see it in your config.php file.

the absolute path is non symbolic meaning its a straight path to the directory locally, rather than

session.save_path= "/tmp/"

which is most likely defined as a symbolic link to there global temp space,
this is highly volatile as they probably use a process killer to kill abandoned sql calls & sessions that run,

For example someone extracts there product database SQL using a html/webpage front end, or phpmyadmin, and closes there browser, halfway thru, the server will still be processing that call for data, there process killer will do a process check and fail and kill that process and cause the session errors like un-serialised, and offset session errors, or your browser session will just sit spinning on processing or freeze on a percent or range, until time ends.

For sessions its cut throat, but in slight different manner as the data as far as im aware is just a session file containing a token that is a static and because is located in global "cloud" tmp space, which kind of don't have a static location it could be stored anywhere in the clouds tmp structure, its process killed because it don't know the origin of the creation,
and a new one is created causing errors.

To my experience is that a session in global tmp will last between 2 seconds and 22 seconds, dependent on the hosts infrastructure load at that particular time. I had this issue around 2014, only October 2015 did I learn how to fix it.

with a local absolute define of the tmp path it does not get deleted , in the same manner. and solves the problems.

This is to the best of my knowledge and I stand to be corrected.

Regards

Andrew Clarke.