We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 3749
    • 24,544 Posts
    I am using PhpED’s debugger, but I don’t know how to use it outside of PhpED. I’ve used it many times to debug standalone PHP code by just loading it into PhpEd and executing it with debug on, but I’d like to debug my own snippets and plugins executed by MODx (and sometimes the MODx core code). Of course the plugins need to execute in the back end.

    I have the whole MODx site in a single project in PhpEd.

    If I load the code of a MODx snippet or plugin into PhpEd and execute it, the $modx and $xPDO objects aren’t available (unless I modify the code to get them and initialize the context), so that’s out.

    As I said, I tried just loading the MODx index.php file or the /manager/index.php file into PhpEd and executing it. That always leads to a 404 error after the current page. Maybe I need to set a path somewhere in PhpEd. Or maybe my whole approach is misguided.

    Can you tell me what you do in more detail?
      Did I help you? Buy me a beer
      Get my Book: MODX:The Official Guide
      MODX info for everyone: http://bobsguides.com/modx.html
      My MODX Extras
      Bob's Guides is now hosted at A2 MODX Hosting
      • 8898
      • 181 Posts
      Quote from: BobRay at Mar 30, 2010, 11:40 PM

      I am using PhpED’s debugger, but I don’t know how to use it outside of PhpED. I’ve used it many times to debug standalone PHP code by just loading it into PhpEd and executing it with debug on, but I’d like to debug my own snippets and plugins executed by MODx (and sometimes the MODx core code).
      Okay, now I understand. Because of your posting #12 I thought that you already do ’remote’ debugging.

      I assume you have a local server that you can use instead of the one PhpED provides (e.g. XAMPP or a comparable environment that you set up yourself).

      In your php.ini you should add these entries if you haven’t already done it:
      [Zend]
      zend_extension="C:\xampp\php\ext\dbg-php-5.3.dll"
      
      [debugger]
      debugger.hosts_allow=127.0.0.1
      debugger.hosts_deny=ALL
      debugger.ports=7869

      Please substitute ’C:\xampp\php\ext\dbg-php-5.3.dll’ with the path to your debugger DLL that you copied from the PhpED installation directory (subdirectory debugger\server\Windows\your_php_version) to your PHP extensions directory. Restart the webserver. If you have the same problem with crashes as described in this thread, maybe it helps to deactivate the custom session handling as suggested in posting #13.

      In your project properties (’Properties’ tab, section ’Mapping’), you should set the run mode to ’HTTP mode (3rd party WEB server)’ and provide the root URL and the remote root directory (’remote’ meaning your local server this time). It’s even easier when you use the Settings Wizard, then there’ll be some checks if everything is set up correctly.

      The method using DebugBreak() I described should work directly now - just call a page in your browser that uses the snippet you’d like to debug.

      Otherwise you’ll have to start the debug session explicitly. In my opinion, the easiest and most convenient way to do this is using the Firefox DBGbar extension (I’m sure I read about something similar to this for IE, please search for it if that’s your preferred browser). Using DBGbar, you can choose what to debug (current page, next page, next form submit, start/end debug session), and you can also profile the current page. You can use breakpoints etc., but as I said, this doesn’t seem to work within snippets.

      I’m sorry if this was too detailed - I’m sure you already set up most of the things I described.

      If you need more information on some details, these links should help you:

      HOWTO: Install debugger module
      NuSphere PHP Debugger Wizard Script
      Debugging PHP, JSON and JavaScripts Application using PHP IDE
      Debugging with PhpED and DBG

      Good luck! wink

      Cheers,
      Jan
        This message has been ROT-13 encrypted twice for higher security.
        • 3749
        • 24,544 Posts
        Great instructions! I look forward to trying them out when I get out from under the load of work I’m in the middle of. wink

        Your MODx karma level just went up by several thousand points. laugh

        Thanks!
          Did I help you? Buy me a beer
          Get my Book: MODX:The Official Guide
          MODX info for everyone: http://bobsguides.com/modx.html
          My MODX Extras
          Bob's Guides is now hosted at A2 MODX Hosting
          • 8898
          • 181 Posts
          Quote from: BobRay at Mar 31, 2010, 01:08 AM

          Your MODx karma level just went up by several thousand points. laugh
          My 50th posting here is still some contributions away! grin

          Cheers,
          Jan
            This message has been ROT-13 encrypted twice for higher security.
            • 3749
            • 24,544 Posts
            Got it working. Thanks. grin grin grin

            I had to use

            debugger.hosts_allow=all


            and comment out all the other Zend lines. The Zend optimizer seems to keep the debugger extension from loading.

            DebugBreak(); works great (though not in plugin code) and I can now execute MODx from within PhpEd.

            Breakpoints I set in the MODx core code seem to be ignored, but DebugBreak() works there too, so I’m way ahead of where I was.

            Thanks again.

            Bob


              Did I help you? Buy me a beer
              Get my Book: MODX:The Official Guide
              MODX info for everyone: http://bobsguides.com/modx.html
              My MODX Extras
              Bob's Guides is now hosted at A2 MODX Hosting
              • 8898
              • 181 Posts
              Quote from: BobRay at Apr 03, 2010, 01:09 AM

              Got it working.
              Great! smiley

              Quote from: BobRay at Apr 03, 2010, 01:09 AM

              I had to use

              debugger.hosts_allow=all

              Does your local server run on a different IP than 127.0.0.1? Did you try filling in that IP there?

              Well, this is just a security setting; I guess on a local server it shouldn’t do too much harm if you leave it at ’all’.

              Quote from: BobRay at Apr 03, 2010, 01:09 AM

              DebugBreak(); works great (though not in plugin code) and I can now execute MODx from within PhpEd.

              Breakpoints I set in the MODx core code seem to be ignored, but DebugBreak() works there too, so I’m way ahead of where I was.
              Breakpoints should work in the MODx core code and in Plugins, too (if they can be found in separate files). I double-checked that right now using a plugin of mine. Did you start a debug session using DBGbar before trying this out? Otherwise it won’t work; just DebugBreak() functions without a previously started debug session.

              Cheers,
              Jan
                This message has been ROT-13 encrypted twice for higher security.
                • 3749
                • 24,544 Posts
                I am on 127.0.0.1. I also tried ’localhost’ there. As you say, it’s not a big deal.

                The plugin I tried was in the DB, not "included and it may have been running from the cache without the added DebugBreak line.

                It works now even in the DB since I cleared the cache.

                RE: breakpoints. Launching PhpED ahead of time loads the debug listener, with I thought would make DBGbar unnecessary, no?
                  Did I help you? Buy me a beer
                  Get my Book: MODX:The Official Guide
                  MODX info for everyone: http://bobsguides.com/modx.html
                  My MODX Extras
                  Bob's Guides is now hosted at A2 MODX Hosting
                  • 8898
                  • 181 Posts
                  Quote from: BobRay at Apr 03, 2010, 09:18 AM

                  It works now even in the DB since I cleared the cache.
                  Fine. smiley

                  Quote from: BobRay at Apr 03, 2010, 09:18 AM

                  RE: breakpoints. Launching PhpED ahead of time loads the debug listener, with I thought would make DBGbar unnecessary, no?
                  No, DBGbar is still necessary. Normally, you’d have to add a debug session ID to the URL you’d like to debug (see http://www.waterproof.fr/products/PHPEdit/manual/en/debug/usage.html below the heading ’From the browser’). DBGbar sets a session cookie with the needed information (debug session ID including the port the DBG Listener is listening on) and makes debugging more comfortable for you.

                  // Edit: If you’d like to learn more about the DBGSESSID, there’s a technical FAQ from NuSphere, too: http://www.nusphere.com/kb/technicalfaq/faq_dbg_related.htm.

                  Cheers,
                  Jan
                    This message has been ROT-13 encrypted twice for higher security.
                    • 3749
                    • 24,544 Posts
                    Got it!

                    Consider me a happy camper.

                    Thanks again. smiley
                      Did I help you? Buy me a beer
                      Get my Book: MODX:The Official Guide
                      MODX info for everyone: http://bobsguides.com/modx.html
                      My MODX Extras
                      Bob's Guides is now hosted at A2 MODX Hosting
                      • 13363
                      • 9 Posts
                      Hey all,
                      Authors of modx’s revolution may want to check this thread
                      http://marc.info/?l=php-internals&m=126659498827675&w=2
                      and in paticular follow what the poster called "a feature documented for several years" and add a session_write_close() function call in the custom session handler:
                      http://marc.info/?l=php-internals&m=126659692130867&w=2
                      Personally I agree with Christian Seiler. This all looks like a big crap in php core because no modules do ever expect any code executed after RSHUTDOWN. Allowing such behavior will cause many troubles anyway even though there a workaround with session_write_close(). It’s just so easy to forget and nothing will warn you.
                      In case of modx, the following modules/functions/methods are executed after RSHUTDOWN:
                      modx-2.0.0-rc-1/core/model/modx/modsessionhandler.class.php (write)
                      modx-2.0.0-rc-1/core/xpdo/xpdo.class.php (getOption, getObject, getObjectLoader, getAncestry, loadClass,
                      getDebug, loadClass, getCriteria, newQuery... in total 123 functions/methods)
                      modx-2.0.0-rc-1/core/xpdo/om/xpdoobject.class.php (load, getSelectColumns, _loadRows, _loadInstance, in total 47 function/methods)
                      and so forth

                      Jan, you may continue leanring how to turn your computer on wink grin

                      -jack