Debugger that works with modx?

Hey all --

Im currently finding that the nusphere IDE’s debugger, DBG, specifically dbg-php-5.3.dll, doesnt play nice with modx. Causes a crash of the IIS fastcgi every time I attach it to a modx process.

DBG works by tacking on some extra params directly onto the querystring which, as expected, causes fits when modx tries to decipher them. DBG works fine with pages not using a querystring though...

....Im looking for recommendations on an IDE with a debugger that works well with modx querystrings for stepping through php code. I’m on a windows box currently, but could swap to linux if I had to for modx dev.

Thanks

I use Netbeans with the PHP plugins on both windows and linux, coupled with Xdebug and an Xdebug browser plugin this all works fine.

The Eclipse framework is also a good starting point here.

I use EclipsePDT with Xdebug to debug MODx 1.0.2 snippets

Quote from: coroico at Mar 18, 2010, 11:10 PM

I use EclipsePDT with Xdebug to debug MODx 1.0.2 snippets

I’ve never been able to get any debugger working with MODx 0.9.x/1.x because all the Snippets and Plugins are eval()’d. Do you have it working on eval()’d code?

Revo caches the script files as global functions and includes them rather than eval()’ing on each execution; this makes it possible to step through Snippets and Plugins in MODx 2.x.

Revo caches the script files as global functions and includes them..

I couldn’t find how it includes database resident snippets, I was looking at using modxfs-php to do this a little while ago http://modxcms.com/forums/index.php/topic,46948.0.html. I always seemed to end up at line 104 in modScript, where the code is taken from the cache but still eval’d, have I missed setting somewhere that stops this or something?

I’ve never been able to get any debugger working with MODx 0.9.x/1.x because all the Snippets and Plugins are eval()’d. Do you have it working on eval()’d code?

I debug not eval()’d snippet but $modx->runSnippet()’d snippet with the appropriate MODx API and context.

Without this kind of debuging I couldn’t maintain a snippet like AjaxSearch.

Quote from: shamblett at Mar 19, 2010, 03:10 PM

Revo caches the script files as global functions and includes them..

I couldn’t find how it includes database resident snippets, I was looking at using modxfs-php to do this a little while ago http://modxcms.com/forums/index.php/topic,46948.0.html. I always seemed to end up at line 104 in modScript, where the code is taken from the cache but still eval’d, have I missed setting somewhere that stops this or something?

Once it’s cached, the script is simply included, and my debugger steps through it fine. The eval() is only used for creating the cached script file the first time.

Ok, but the eval() will execute the snippet code will it not? Where does the include happen? I’ve not stepped through this fully admittedly, I stopped at the eval(). Thinking, what if the snippet is not cached and it has to come direct from the DB? How is it ’included’ as such?

Just to add, I also thought that snippets were not eval’d at all in revo and as you say included, so why do we even have an eval() in the code?

Revo is beyond my level of competence, but I do know this much! Since even in Revo snippets come from the database, how can they be included? Their code has to be eval()’ed.

Quote from: shamblett at Mar 19, 2010, 06:56 PM

Ok, but the eval() will execute the snippet code will it not? Where does the include happen? I’ve not stepped through this fully admittedly, I stopped at the eval(). Thinking, what if the snippet is not cached and it has to come direct from the DB? How is it ’included’ as such?

Just to add, I also thought that snippets were not eval’d at all in revo and as you say included, so why do we even have an eval() in the code?

Quote from: sottwell at Mar 20, 2010, 10:43 AM

Since even in Revo snippets come from the database, how can they be included? Their code has to be eval()’ed.

First, thanks for bringing this up folks; I had overlooked this. Let me explain what happened historically here.

Originally when I created Revo, all snippets were simply written to cache files that were included, registering a function into the global namespace. This worked great, eval() was banished, and remote debugging with MODx was possible.

Then I refactored the caching system last spring after using an early alpha of Revo on a huge project that involved traffic approaching 5000 simultaneous users. At this point, I needed to be able to cache the source of Snippet (or Plugin) in configurable cache providers, like one using memcached for instance. But you can’t include source code that is cached in memcached. So eval() found it’s way back into the codebase and remote debugging was crippled once again.

Now, after reviewing the modScript::loadScript() code, I have compromised and once again gotten rid of the eval(). I’m still able to cache the actual script source in any cache provider, but now this source is now written to an include file and included once again as originally intended. I’ll have this committed into branches/2.0, along with some caching optimizations involving Elements this review also sparked, before the end of the weekend.

This means you will be able to remote debug MODx snippets and plugins once again, as well as quickly test code by editing the .include.cache.php files that will now be generated on first execution of a Snippet or Plugin after the cache is cleared.