I'm no expert on anything but I can tell you that this "ini_set" thing seems to be the biggest issue with v1.10, so I recommend you go back to the version you were using. I hope you also have your files backed up because obviously you will need them.

If you were using 1.9.1 I would also highly recommend you upgrade to 1.9.3, which is the best available version in the 1.9 generation.

Hi,

Got it fixed on my blog (I didn't reply on my thread similar to this...)

I am not sure with this but b2e v1.10 is "now" using ini_set(), but prior to that, b2e is not using it. I came to this conclusion when I found out that my php.ini setting had ini_set() turned off.

When I tested the other php apps I know to be using ini_set(), I found out that these apps don't actually use it if it isn't available.

So, in other words, your php.ini setting has the ini_set() turned off. If you don't have access to it, or your provider don't allow you to use a local php.ini, it is best to ask them to turn on ini_set() for your account.

Again, I may be wrong with this, and I don't know why b2e have to use it now when it doesn't have to before :p Or maybe, the alternative way hasn't been coded yet, so b2e's only option is to use the ini_set();

Regards

(Feel free to correct me if I got it wrong)

b2evo was using ini_set() before that, it was just supressing the error ;)

¥

Yabba, is there a way we can suppress the error now?

¥åßßå wrote:

b2evo was using ini_set() before that, it was just supressing the error ;)

¥

Ahh, so that's why I don't see the messages on the top that says "your comment has been posted... lorem ipsum yadda yadda..." on b2e1.9, yet I'm not getting any errors.

-----------------------------------------
OT:
Try to ask your host if there's something you or they can do so you can use ini_set();

tejaaa wrote:

Yabba, is there a way we can suppress the error now?

This is the code from 2.0, you can try using that instead :-

						// Unserialize session data (using an own callback that should provide class definitions):
						$old_callback = ini_set( 'unserialize_callback_func', 'session_unserialize_callback' );
						if( $old_callback === false )
						{ // this can fail, if "ini_set" has been disabled for security reasons.. :/
							// fp> yes and that's the case at OVH, France's largest shared hosting company.
							// fp> There is no way we're gonna just die here.
							// debug_die('ini_set() is disabled! b2evo cannot adjust "unserialize_callback_func" for Session restoring!');

							// Brutally load add classes that we might need:
 							session_unserialize_load_all_classes();
						}
						// TODO: dh> This can fail, if there are special chars in sess_data:
						//       It will be encoded in $evo_charset _after_ "SET NAMES", but
						//       get retrieved here, _before_ any "SET NAMES" (if $db_config['connection_charset'] is not set (default))!
						$this->_data = @unserialize($row->sess_data);

						if( $old_callback !== false )
						{	// Restore the old callback if we changed it:
							ini_set( 'unserialize_callback_func', $old_callback );
						}

It replaces this section of code in your current 1.10 :

						// Unserialize session data (using an own callback that should provide class definitions):
						$old_callback = ini_set( 'unserialize_callback_func', 'session_unserialize_callback' );
						if( $old_callback === false )
						{ // this can fail, if "ini_set" has been disabled for security reasons.. :/
							// TODO: dh> add this to "System check page"?
							debug_die('ini_set() is disabled! b2evo cannot adjust "unserialize_callback_func" for Session restoring!');
						}
						// TODO: dh> This can fail, if there are special chars in sess_data:
						//       It will be encoded in $evo_charset _after_ "SET NAMES", but
						//       get retrieved here, _before_ any "SET NAMES" (if $db_config['connection_charset'] is not set (default))!
						$this->_data = @unserialize($row->sess_data);
						ini_set( 'unserialize_callback_func', $old_callback );

¥

Thanks Yabbba.

Now I get this error.

Fatal error: Call to undefined function: session_unserialize_load_all_classes() in /home/xyzabc/public_html/inc/MODEL/sessions/_session.class.php on line 165

Thanks again.

Tejaaa

:P that must be just a 2.0 function. Remove this section of code from what I posted.

                        if( $old_callback === false )
                        { // this can fail, if "ini_set" has been disabled for security reasons.. :/
                            // fp> yes and that's the case at OVH, France's largest shared hosting company.
                            // fp> There is no way we're gonna just die here.
                            // debug_die('ini_set() is disabled! b2evo cannot adjust "unserialize_callback_func" for Session restoring!');

                            // Brutally load add classes that we might need:
                             session_unserialize_load_all_classes();
                        } 

¥

Great, we are getting there.

Yabba, this is what I did. I removed the code

 // Unserialize session data (using an own callback that should provide class definitions):
                        $old_callback = ini_set( 'unserialize_callback_func', 'session_unserialize_callback' );
                        if( $old_callback === false )
                        { // this can fail, if "ini_set" has been disabled for security reasons.. :/
                            // TODO: dh> add this to "System check page"?
                            debug_die('ini_set() is disabled! b2evo cannot adjust "unserialize_callback_func" for Session restoring!');
                        }
                        // TODO: dh> This can fail, if there are special chars in sess_data:
                        //       It will be encoded in $evo_charset _after_ "SET NAMES", but
                        //       get retrieved here, _before_ any "SET NAMES" (if $db_config['connection_charset'] is not set (default))!
                        $this->_data = @unserialize($row->sess_data);
                        ini_set( 'unserialize_callback_func', $old_callback ); 

and I replaced it with this code.

  // TODO: dh> This can fail, if there are special chars in sess_data:
                        //       It will be encoded in $evo_charset _after_ "SET NAMES", but
                        //       get retrieved here, _before_ any "SET NAMES" (if $db_config['connection_charset'] is not set (default))!
                        $this->_data = @unserialize($row->sess_data);

                        if( $old_callback !== false )
                        {    // Restore the old callback if we changed it:
                            ini_set( 'unserialize_callback_func', $old_callback );
                        } 

The solution is now when I put comments, I can post the comments and still get onto the blog front page. I still though get the following error message on the top of the page (The blog skin and all loads).

Notice: Undefined variable: old_callback in /home/xyz/public_html/inc/MODEL/sessions/_session.class.php on line 162

Notice: Undefined variable: old_callback in /home/xyz/public_html/inc/MODEL/sessions/_session.class.php on line 164

Warning: Cannot modify header information - headers already sent by (output started at /home/xyz/public_html/inc/MODEL/sessions/_session.class.php:162) in /home/xyz/public_html/inc/MODEL/skins/_skin.funcs.php on line 71

Any furhter light into this will be appreciated. I am attaching a screenshot of the error now.

Tejaaa[/code]

                        // Unserialize session data (using an own callback that should provide class definitions):
                        $old_callback = ini_set( 'unserialize_callback_func', 'session_unserialize_callback' );
                        // TODO: dh> This can fail, if there are special chars in sess_data:
                        //       It will be encoded in $evo_charset _after_ "SET NAMES", but
                        //       get retrieved here, _before_ any "SET NAMES" (if $db_config['connection_charset'] is not set (default))!
                        $this->_data = @unserialize($row->sess_data);

                        if( $old_callback !== false )
                        {    // Restore the old callback if we changed it:
                            ini_set( 'unserialize_callback_func', $old_callback );
                        } 

¥

Yabba, you are the ONE.

It did it. I have tried it briefly. Early tomorrow I will play with it extensively trialing out most of the things.

Can you let me know if this will have any negative impact?

Thanks a ton again.

Tejaaa

I know that you'll have some problems with your session data ( previews, "thanks for your comment" messages etc ), but other than that I'm clueless.

¥

Hey Guys, just for information, Lunarpages got a solution to this problem as well. This is what they wrote back to me.

 	Hello Tejaaa,

We were able to resolve your issue by adding unserialize_callback_func='session_unserialize_callback'; to your php.ini

You can see the same problem here: http://forums.b2evolution.net/viewtopic.php?t=11630

You are using Beta version of b2evolition. Beta versions are not fully tested and may be unstable. This is not production version, new features will appear in this version first.

Please, let us know if you have any further questions and we will gladly assist you.

Have a great day.

Tejaaa

The solution to the problem would have been for them to allow ini_set() ;)

¥

Here's the fix, backported from CVS HEAD (pre-2.0) for 1.10.x:
http://evocms.cvs.sourceforge.net/evocms/b2evolution/blogs/inc/MODEL/sessions/_session.class.php?r1=1.20.2.4.2.3&r2=1.20.2.4.2.5&pathrev=v-1-10

It will be included in 1.10.1. You could replace the whole file for 1.10.x: http://evocms.cvs.sourceforge.net/evocms/b2evolution/blogs/inc/MODEL/sessions/_session.class.php?view=markup&pathrev=v-1-10

Hi,

I have the same problem with the french provider "club-Internet".
What I don't understand is that blueyed said that the fiw has been included in 1.10.1 and I have the problem with 1.10.2

:( :(

totof, check your file and see if the fix is included, according to the patch/diff linked above.

Yes, the fix is included (my file is the same than the revision 1.20.2.4.2.5)

When the fix is included I cannot see why "ini_set() is disabled! b2evo cannot adjust "unserialize_callback_func" for Session restoring!" should get displayed, because it's commented out.

here is the content of _session.class.php on my blog :

Lines 156-183

// Unserialize session data (using an own callback that should provide class definitions):
						$old_callback = @ini_set( 'unserialize_callback_func', 'session_unserialize_callback' );
						if( $old_callback === false )
						{ // this can fail, if "ini_set" has been disabled for security reasons.. :/
							// fp> yes and that's the case at OVH, France's largest shared hosting company.
							// fp> There is no way we're gonna just die here.
							// debug_die('ini_set() is disabled! b2evo cannot adjust "unserialize_callback_func" for Session restoring!');

							// Brutally load all classes that we might need:
 							session_unserialize_load_all_classes();
						}
						// TODO: dh> This can fail, if there are special chars in sess_data:
						//       It will be encoded in $evo_charset _after_ "SET NAMES", but
						//       get retrieved here, _before_ any "SET NAMES" (if $db_config['connection_charset'] is not set (default))!
						$this->_data = @unserialize($row->sess_data);

						if( $old_callback !== false )
						{	// Restore the old callback if we changed it:
							ini_set( 'unserialize_callback_func', $old_callback );
						}

						if( ! is_array($this->_data) )
						{
							$Debuglog->add( 'Session data corrupted!<br />
								connection_charset: '.var_export($DB->connection_charset, true).'<br />
								Serialized data was: --['.var_export($row->sess_data, true).']--', array('session','error') );
							$this->_data = array();
						}

and lines 507-524

/**
 * When session_unserialize_callback() cannot be registered to do some smart loading,
 * then we fall back to this function and load everything with brute force...
 *
 * IMPORTANT: when modifying this, modify the following also:
 * @see session_unserialize_callback()
 */
function session_unserialize_load_all_classes()
{
	global $model_path, $object_def /* dh> used e.g. in Item constructor */;

	require_once $model_path.'collections/_blog.class.php';
	require_once $model_path.'collections/_collsettings.class.php';
	require_once $model_path.'comments/_comment.class.php';
	require_once $model_path.'items/_item.class.php';
	require_once $model_path.'users/_group.class.php';
	require_once $model_path.'users/_user.class.php';
}

And what's the error then you're getting?

Sorry, I couldn't acces Internet since 3 days.

The error I get is :

Warning: ini_set() est inactive pour des raisons de sécurité. Pour plus d'informations, veuillez consulter : http://www.club-internet.fr/pagespersos/clubphp/ in /blogs/inc/MODEL/sessions/_session.class.php on line 174

Warning: Cannot modify header information - headers already sent by (output started at /blogs/inc/MODEL/sessions/_session.class.php:174) in /blogs/inc/MODEL/skins/_skin.funcs.php on line 71

Thanks for your help

totof. please add
var_dump( $old_callback );
in the "if( $old_callback !== false )"-block (should be line 174 in /blogs/inc/MODEL/sessions/_session.class.php, before the ini_set there).

What does it output?

blueyed,

With this modification I can use my blog for about 5 minutes, and then the error appears again.

My _session.class.php file is now :

if( $old_callback !== false )
{ // Restore the old callback if we changed it:
   var_dump( $old_callback );
   ini_set( 'unserialize_callback_func', $old_callback );
}

totof, var_dump() is there to output anything. What's that output?
The problem on your setup is, that ini_set() seems to fail, but does not return false as expected and therefor another ini_set() call gets issued.
You might just want to add a "@" to the second call, too.
So that it looks like

if( $old_callback !== false ) 
{ // Restore the old callback if we changed it: 
  @ini_set( 'unserialize_callback_func', $old_callback ); 
} 

But, saying it again, there's a strange problem here anyway (the output from var_dump() might help!!).
And using "@" is kind of dirty, as it suppressed any errors.