HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


9.0.8 Critical errors

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#99493 (In Topic #19552)
Avatar

Community saint

My members have been reporting "critical error - bailing out" messages since updating to 9.0.8. These have been random as to who gets them and in what forum they happen.

One member reported this one about 2 days ago…
PHP NOTICE [8] unserialize() [<a href='PHP: unserialize - Manual'>function.unserialize.php</a>]: Error at offset 852 of 2683 bytes in sources/tempcode.php(1384) : eval()'d code on line 1 (version: 9.0.8, PHP version: 5.3.3, URL: /forum/index.php?page=forumview&id=general-chat%2Fintroduce-
yourself)
and also provided a link to the forum that gave him the error. I had no problems with that particular forum just a short time before he posted his error, until I clicked on the link he provided, which gave me the error also (sorry, didn't save the error I received).

This one was reported about 12 hours ago by a different member…
PHP NOTICE [8] unserialize() [<a href='PHP: unserialize - Manual'>function.unserialize.php</a>]: Error at offset 2466 of 7836 bytes in sources/tempcode.php(1384) : eval()'d code on line 1 (version: 9.0.8, PHP version: 5.3.3, URL: /forum/index.php?page=forumview&id=raspberry-pi)

Same errors, just random times, forums, and members.

My error log is full of these errors…

Expand:


Steve
Back to the top
 
Posted
Rating:
#99495
Avatar

Community saint

Clearing the caches is a temporary fix so my uneducated guess is something is corrupting the caches.

Steve
Back to the top
 
Posted
Rating:
#99497
Avatar

Hmm. Do you have one site on utf-8 and one not, both accessing a shared forum?


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#99498
Avatar

Community saint

I was just looking at the db for the main site. I noticed 3 tables with a different character set. I haven't updated the satellite sites yet so those db's should still be ok, but will check anyway before doing the update.

The activities addon was reinstalled after the update.
oc_activities     latin1_swedish_ci
oc_ticket_types      latin1_swedish_ci
oc_tickets     latin1_swedish_ci

I had this problem before (on 8.0.x) which required a manual fix.

Steve
Back to the top
 
Posted
Rating:
#99499
Avatar

I would not worry about that so much. The main one is the translate table.

If your satellite sites don't use a consistent character set in global.ini, or define a different database communication character set in info.php, then PHP serialize'd data will store differently.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#99500
Avatar

Community saint

Ok, so if I'm understanding this correctly, if my db is using utf8 for the translate table, the 'charset' string should also be utf8 in global.ini?

They're different, and I just noticed the (main site) translate table is using yet another character set different from what I posted earlier. All the satellite sites are using iso-8859-2 in global.ini and the (main site) translate table is utf8_unicode_ci (which may have been my error). The translate table should have been utf8_general_ci same the satellite db's.

One thing that keeps going through my mind is, what caused those 4 tables to change character sets? If trying to keep everything utf8 is going to be a continual hassle, I might just switch back to the install default of latin1_swedish_ci.

Ah, the joys of administration!  :lol:  :thumbs:

Steve
Back to the top
 
Posted
Rating:
#99501
Avatar

If all the sites are using iso-8859-1 and none have overridden settings for what the database character set is (in info.php), and all run the same version, I'm surprised by this, as it sounds like one is writing in as utf-8 and one is not.

You should try and generally match the database character set to what ocPortal uses. Otherwise, you can get complex errors. Setting it to utf8 while ocPortal is in ISO-8859-1 is likely to result in ocPortal sending ISO-8859-1 and MySQL thinking that is utf-8 and potentially falling over. Doing the opposite is likely to cause a similar problem.

I believe ocPortal installs them to latin1, so if they changed, I don't think that would be something within the scope of ocPortal. We provide some instructions for changing database character sets as we don't have code to do it automatically (for complex reasons).


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
1 guests and 0 members have just viewed this: None
Control functions:

Quick reply   Contract

Your name:
Your message: