We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
MODX Community Forums Archive

How to log in the event log viewer

    • 26083
    • 32 Posts
    samweb Reply #1, 20 years, 2 months ago
    Sorry,

    But how to log in order to debug my code ?
    In Java there is a notion of logger or console. Is there something easy (just printing somewhere) ...
      • 18397
      • 3,250 Posts
      MARKSVIRTUALDESK Reply #2, 20 years, 2 months ago 
      	$modx->logEvent(params);


      That will log whatever you wish in the event log viewer.

      Most developers here choose to use an &debug parameter to toggle debug output.

      The choice of which to use is up to you.
        • 26083
        • 32 Posts
        samweb Reply #3, 20 years, 2 months ago
        Thanks ...

        But precisely what are the parameter. I do not found them on the API documentation ?
          • 18397
          • 3,250 Posts
          MARKSVIRTUALDESK Reply #4, 20 years, 2 months ago
          This is the actual function from document.parser.inc.php 

          // Add an a alert message to the system event log
  function logEvent($evtid,$type,$msg,$source='Parser') {
    $msg = mysql_escape_string($msg);
    $source = mysql_escape_string($source);
    $evtid = intval($evtid);
    if ($type<1) $type = 1; else if($type>3) $type = 3; // Types: 1 = information, 2 = warning, 3 = error
    $sql = "INSERT INTO ".$this->getFullTableName("event_log")."(eventid,type,createdon,source,description,user) ".
      "VALUES($evtid,$type,".time().",'$source','$msg','".$this->getLoginUserID()."')";
    $ds = $this->dbQuery($sql);
    if(!$ds) {
      echo "Error while inserting event log into database.";
      exit;
    }

  }


          The API documentation is far from complete. There are actually alot of other functions that you can access in that file.
            • 22303 MODX Staff
            • 10,725 Posts
            opengeek Reply #5, 20 years, 2 months ago
            This is for logging to the eventLog table, not for debugging purposes. PHP has the notion of standard out, so you can use functions like echo and print_r (along with exit to stop processing) to output debugging information in your snippets, or you can use $modx->messageQuit() (also in the document.parser.class.inc.php) function to have the parser stop at a certain point and return information formatted for HTML display.
              Jason Coward
              Chief Architect @ MODX
              http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek
              • 34162
              • 1 Posts
              Zombie Reply #6, 20 years, 2 months ago
              Without knowing about the mere existence of an event log viewer, I’ve done this type of "home-brewn" debugging from the beginning. Not very comfortable, but works. wink
                • 22303 MODX Staff
                • 10,725 Posts
                opengeek Reply #7, 20 years, 2 months ago
                Quote from: ppaul at Jul 24, 2006, 12:13 PM

                Without knowing about the mere existence of an event log viewer, I’ve done this type of "home-brewn" debugging from the beginning. Not very comfortable, but works. wink
                Agreed...

                Being a long time J2EE developer, I grew accustomed to remote debugging of web requests, and so most of the debugging I do on the core code is via DBG and the PHPEclipse IDE’s debug environment, where I can step through web requests a line at a time. However, in the current MODx architecture, you seemingly can’t step through snippets/plugins because they are eval()’d by the system (somebody correct me if you’ve been able to do this in any remote debugging environment). Upcoming changes to the way MODx components are executed will remedy this and allow you to use traditional remote debugging techniques for components. Until then, and for those that don’t have access to or want to invest the time in getting set-up with such an environment, returning debug output from your snippet is generally your most efficient means of doing this. I even prefer to have my snippets be includes so that I can simply modify the PHP files in the IDE and instantly see changes when working locally (or following a quick FTP upload, remotely).

                Full-featured, customizable logging for auditing, debugging, and other purposes will be introduced in the 1.0 code base, including the ability to write the logs to file, database, screen, or just about anywhere imaginable. So you could write debugging output to a custom debug file, and/or critical run-time error output to the Apache error log, and/or save component-level error details into the session.

                In addition, I believe some other work on more interactive debugging features is also being done, so you can get unobstrusive optional debug data directly within the MODx environment.
                  Jason Coward
                  Chief Architect @ MODX
                  http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek
                  • 34162
                  • 1 Posts
                  Zombie Reply #8, 20 years, 2 months ago
                  Hmm, reading this, I think I could introduce a debug/log document. Together with a function like $modx->debug(*anything, like list of vars*) which appends the output to the content of that document, it might be more convenient than to let the print_r or echo stuff appear somewhere on a real document...
                  But I’m sure the "pros" do so already... lipsrsealed

                  EDIT: Today I tried to set up DBG on a Mac. It was a nightmare and I failed utterly...