capitaine

Send private message

You must be logged in to send a private message.

Friends

No friends yet.

Activity

  • Hello, I'm facing two different problems but I think they are dependent. 1) A lot of "PHP Fatal error:  spl_autoload(): Class DatabaseException could not be loaded in /home/.../engine/lib/database.php on line 274" in my logs php in use :...
    • The real problem is that you hava a database excepction that the code can not show. In elgg 1.9 and above all the engine/database was fully rewritten, that's why is not happening there. I use 1.8.20 and have this problem, but usually is because the table is corrupt and have to repair it (usually the user sessions table).

  • capitaine replied on the discussion topic Elgg 1.8.3 Fatal error
    Well, this is a rather old discussion but, me also STILL have the same problem, and didn't see any solution neither in elgg nor in googling. Using non-latin characters (or latin accentuated) in usernames doesn't work in elgg 1.8.15. Indeed,... view reply
  • capitaine joined the group Feedback and Planning
  • capitaine replied on the discussion topic 1970 problem again
    @Cash For me it works when I put the Event Calendar before the Profile plugin and not below. This is my plugins order : 1st: Event Calendar - 2nd: Profile - 3rd: Profile Manager So I can use and edit with no problem the date fields inside... view reply
  • capitaine replied on the discussion topic 1970 problem again
    OK, Jan Kirsten's fix works fine for Event calendar, but then date fields inside Profile manager don't work any more, they now show like unix timestamps. So, I think the best way is the one suggested by Tom, but has anyone already done it ? I... view reply
  • capitaine joined the group Event calendar
  • capitaine replied on the discussion topic mysql database... in the group General Discussion
    I'm having some trouble accessing the mysql database. I get the following error message SQL show index from `elggusers_sessions` failed : Table './elgg/elggusers_sessions' is marked as crashed and should be repaired The trouble is I run a cron job...
    • I was just just wondering

      Could you not just empty this table. I thought it was just keeping track of who is logged in. Of course it would log every one out that was in but if you did it at a quite time ????? on the other hand check, with someone who knows a bit more about this, and if this could cause any damage to your site, before even thinking about this solution.

    • Confirmed ;-)

      I just emptied my sessions table => caused no problems

      @JEd

      (1) try phpMyAdin to empty table first

      if not allowed.. delete and recreate table -- you do know how to ?

       

    • I have a similar problem with elgg_users_sessions. Table crashed and I had to repair it with the myisamchk --safe-recover elgg_users_sessions commande, easier methods for reparation failed. It took several hours to do it ! Tehn I discovered that there were more than 2 million records in the table ! Yes, two million and a half sessions recorded...

      So I looked closer to understand why. For an unknown reason, the old sessions aren't been destroyed. Also for an unkonown reason, sessions continue to be created even if there is no "visible" activity in the site. About 900 records per hour. So, after some weeks, the table size becomes enormous, the garbage collector fails to optimize it and all that leads to a crash.

      The other think I noticed, but I am not sure if this is the right way. Should the 'session' field of the 'elgg_users_sessions' table reflect the 'code' field of the 'elgg_users_entity' table ? I think so if I understood well the way the sessions are written in the database in the engine/lib/sessions.php. If this is so, the thing I noticed is that in my installation this doesn't happen. When I look with phpmyadmin and something like :

      SELECT *
      FROM elgg_users_sessions, elgg_users_entity
      WHERE elgg_users_sessions.session = elgg_users_entity.code

      it returns no result.

      If my assumption that these two fields should be identical is right then I suppose that the destroy function doesn't work because it cant find the session to destroy in the elgg_users_sessions table.

      Well, this should explain why this table grows until to explose, but it doen't explain why 1) sessions are written even if there is no "visible" activity and 2) why sessions are not written with the same reference in elgg_users_sessions and in elgg_users_entity

      Any help will be greatly appreciated.

      I have to mention that I am using elgg 1.5 and also I integrated it with two other external applications for a common login (elgg as master and the other applications as slaves). I desactivated the integration links to see if this was causing the problem, but it continues even when Elgg is alone.

  • capitaine joined the group General Discussion