Jump to content
FrancisChung

Trouble Debugging ProcessWire using XDebug + PHPStorm

Recommended Posts

Hi there,

I'm a newbie and I'm trying to learn more about Processwire so I've setup XDebug + PHPStorm to get some real time debugging happening. 

I've noticed that no matter where i put a breakpoint in any of my php modules, it seems to return the following error.

Error: __debuginfo() must return an array (line 55 of /Users/FrancisChung/site/Test/templates/head.inc) 
This error message was shown because you are logged in as a Superuser. Error has been logged.

I was wondering if fellow Processwire users have a similar setup, and was successful in getting debugging going.

I've also read this forum post:

https://processwire.com/talk/topic/1611-yes-debugging-templates-and-core-code-works/

I'm also aware there's an issue with XDebug and Processwire:

https://github.com/ryancramerdesign/ProcessWire/issues/1316

  • Like 1

Share this post


Link to post
Share on other sites

Update : XDebug seems to work with Processwire & PHP 5.5 but not PHP 5.6 or above.

I think PHP 5.6 introduced a new magic method for __DebugInfo() and it's problematic when it tries to debug Processwire.

Not sure if Processwire objects are using var_dump().

Share this post


Link to post
Share on other sites

I am currently still experiencing this with PW 2.7.2 on any version of PHP 5.6+

Has this not been fixed yet, is there a patch I can manually apply. I'd rather not have to downgrade my dev environments just to be able to use xdebug. Heck, XAMPP ships with 5.6 by default now.

Share this post


Link to post
Share on other sites

I am currently still experiencing this with PW 2.7.2 on any version of PHP 5.6+

Has this not been fixed yet, is there a patch I can manually apply. I'd rather not have to downgrade my dev environments just to be able to use xdebug. Heck, XAMPP ships with 5.6 by default now.

I seem to recall this could fix in the next release, but don't quote me on that as my recollection is rather hazy at the moment.

Share this post


Link to post
Share on other sites

Update : Just tried to revisit this and it's an issue with PHP v7.0.10

Will try and upgrade to PW3 and see if that fixes it ....

Share this post


Link to post
Share on other sites

So I've managed to get XDebug working partially with PHP7.

It seems that XDebug throws the __debugInfo must return an array error on any breakpoints where the php code is not a class definition. If I put breakpoints in any classes, debugging works fine. 

Also, I don't know whether it's a different issue but I had to set break on first line in PHPStorm to get the debugger start up properly. Perhaps there's some bootstrapping going on with this option that isn't happening elsewhere.

I've used the same config for PHP 5.5 and everything works as previously.

 

So until they fix this issue (which was allegedly fixed in Xdebug 2.4.1), best to put breakpoints only in classes.

 

P/S If anyone needs setup instructions, here's some helpful guides.

http://www.codechewing.com/library/debug-php-with-phpstorm-xdebug-mamp/

http://manovotny.com/setup-phpstorm-xdebug-mamp-debugging/

P/P/S

More info on __debugInfo

Quote

__debugInfo() 

array __debugInfo ( void )

This method is called by var_dump() when dumping an object to get the properties that should be shown. If the method isn't defined on an object, then all public, protected and private properties will be shown.

This feature was added in PHP 5.6.0.

 

Share this post


Link to post
Share on other sites

Any luck getting xdebug and processwire working. I'm in phpstorm as well. I can successfully break anywhere before the Wire class has been instantiated. When breaking, xdebug failed silently or I get the following error.

Warning: Uncaught Error: Class 'ProcessWire\WireDebugInfo' not found in C:\dev\www\pw\vkauai\wire\core\Wire.php:1695 Stack trace: #0 C:\dev\www\pw\vkauai\wire\core\Fuel.php(91): ProcessWire\Wire->__debugInfo() #1 C:\dev\www\pw\vkauai\wire\core\ProcessWire.php(200): ProcessWire\Fuel->set('wire', Object(ProcessWire\ProcessWire), true) #2 C:\dev\www\pw\vkauai\index.php(52): ProcessWire\ProcessWire->__construct(Object(ProcessWire\Config)) #3 {main} thrown in C:\dev\www\pw\vkauai\wire\core\Wire.php on line 1695 

Fatal error: __debuginfo() must return an array in C:\dev\www\pw\vkauai\wire\core\Fuel.php on line 91 

UPDATE:

Setting a breakpoint on the Wire.php constructor returns the above error

public function __construct() {}

But great news, breakpoints in my templates are actually working. I was unaware that my template were being compiled into the cache directory - setting breakpoints on the cached versions of my template will cause xdebug to properly break.

I am using php 7.0.13 and xdebug 2.5

 

Share this post


Link to post
Share on other sites

I am running into the same issue. Unfortunately I wasn't able to reproduce it isolated, but it happens constantly in my current setup during debugging. Has this issue been solved for you @FrancisChung or is it still happening for you as well? 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Robin S
      This module is inspired by and similar to the Template Stubs module. The author of that module has not been active in the PW community for several years now and parts of the code for that module didn't make sense to me, so I decided to create my own module. Auto Template Stubs has only been tested with PhpStorm because that is the IDE that I use.
      Auto Template Stubs
      Automatically creates stub files for templates when fields or fieldgroups are saved.
      Stub files are useful if you are using an IDE (e.g. PhpStorm) that provides code assistance - the stub files let the IDE know what fields exist in each template and what data type each field returns. Depending on your IDE's features you get benefits such as code completion for field names as you type, type inference, inspection, documentation, etc.
      Installation
      Install the Auto Template Stubs module.
      Configuration
      You can change the class name prefix setting in the module config if you like. It's good to use a class name prefix because it reduces the chance that the class name will clash with an existing class name.
      The directory path used to store the stub files is configurable.
      There is a checkbox to manually trigger the regeneration of all stub files if needed.
      Usage
      Add a line near the top of each of your template files to tell your IDE what stub class name to associate with the $page variable within the template file. For example, with the default class name prefix you would add the following line at the top of the home.php template file:
      /** @var tpl_home $page */ Now enjoy code completion, etc, in your IDE.

      Adding data types for non-core Fieldtype modules
      The module includes the data types returned by all the core Fieldtype modules. If you want to add data types returned by one or more non-core Fieldtype modules then you can hook the AutoTemplateStubs::getReturnTypes() method. For example, in /site/ready.php:
      // Add data types for some non-core Fieldtype modules $wire->addHookAfter('AutoTemplateStubs::getReturnTypes', function(HookEvent $event) { $extra_types = [ 'FieldtypeDecimal' => 'string', 'FieldtypeLeafletMapMarker' => 'LeafletMapMarker', 'FieldtypeRepeaterMatrix' => 'RepeaterMatrixPageArray', 'FieldtypeTable' => 'TableRows', ]; $event->return = $event->return + $extra_types; }); Credits
      Inspired by and much credit to the Template Stubs module by mindplay.dk.
       
      https://github.com/Toutouwai/AutoTemplateStubs
      https://modules.processwire.com/modules/auto-template-stubs/
    • By Jarden Black
      Hi everyone,
      [edit: do not loose your time reading this post, I solved it by disabling cache in the Pages2Pdf module... sorry 😓]
       
      I do not know if I should post on the Pages2Pdf thread or here. Mods, feel free to move the post.
       
      Since three days I am scratching my head  to understand a weird thing happening with $session and $config->debug used in conjunction with Pages2Pdf module. For information, I tested it on a fresh install of ProcessWire 3.0.96 with PHP-7.0.28 and Pages2Pdf-1.1.7 (domain: http://session.sites.sek/). I will try to explain what is going on.
       
      What I am trying to achieve :
      In a template, I need to set some sessions variables which are then echo'd in the PDF document.
      (on the test installation, the basic-page template (page /about/?pages2pdf) serve the PDF, the home and sitemap template set the session variable.)
       
      The problem :
      From the template sitemap, I set a variable: $session->setFor('pdf', 'myvar', 'Session set from Sitemap template');
      From the template home, I set a variable: $session->setFor('pdf', 'myvar', 'Session set from Home template');
      Then in the PDF default template, I echo the session variable: <p>Session: <?= $session->getFor('pdf', 'myvar'); ?></p>
       
      Now I turn ON debug mode ($config->debug = true) :
      Then I navigate to  "http://session.sites.sek/home/" and the session variable "myvar" is set to "Session set from Home template". Then I navigate to  "http://session.sites.sek/sitemap/" and the session variable "myvar" is set to "Session set from Sitemap template". Now I want my PDF document, so I navigate to "http://session.sites.sek/about/?pages2pdf=1" and I get my PDF document with the right session var : "Session set from Sitemap template" For the moment, nothing special happen. Everything work great. We are in debug mode.
       
      Now I turn OFF debug mode ($config->debug = false) :
      Then I navigate to  "http://session.sites.sek/home/" and the session variable "myvar" is set to "Session set from Home template". Then I navigate to  "http://session.sites.sek/sitemap/" and the session variable "myvar" is set to "Session set from Sitemap template". Then I navigate back to "http://session.sites.sek/home/" and the session variable "myvar" is set back to "Session set from Home template". Now I want my PDF document - as expected, the "myvar" should be set to "Session set from Home template" - so I navigate to "http://session.sites.sek/about/?pages2pdf=1" and here the problem happen. Instead of echoing  "Session set from Home template" in the PDF document, the phrase "Session set from sitemap" is echo'd (the last value recorded before switching from debug ON).  
       
      I made two small screencasts to show the issue :
      DEBUG ON (Everything is OK)
       
      DEBUG OFF
       
       
      I am missing something ? EDIT: YES, you are dumb!
       
       
    • By flydev 👊🏻
      Hi everyone,
      [edit: do not loose your time reading this post, I solved it by disabling cache in the Pages2Pdf module... sorry 😓]
       
      I do not know if I should post on the Pages2Pdf thread or here. Mods, feel free to move the post.
       
      Since three days I am scratching my head to understand a weird thing happening with $session and $config->debug used in conjunction with Pages2Pdf module. For information, I tested it on a fresh install of ProcessWire 3.0.96 with PHP-7.0.28 and Pages2Pdf-1.1.7 (domain: http://session.sites.sek/). I will try to explain what is going on.
       
      What I am trying to achieve :
      In a template, I need to set some sessions variables which are then echo'd in the PDF document.
      (on the test installation, the basic-page template (page /about/?pages2pdf) serve the PDF, the home and sitemap template set the session variable.)
       
      The problem :
      From the template sitemap, I set a variable: $session->setFor('pdf', 'myvar', 'Session set from Sitemap template');
      From the template home, I set a variable: $session->setFor('pdf', 'myvar', 'Session set from Home template');
      Then in the PDF default template, I echo the session variable: <p>Session: <?= $session->getFor('pdf', 'myvar'); ?></p>
       
      Now I turn ON debug mode ($config->debug = true) :
      Then I navigate to  "http://session.sites.sek/home/" and the session variable "myvar" is set to "Session set from Home template". Then I navigate to  "http://session.sites.sek/sitemap/" and the session variable "myvar" is set to "Session set from Sitemap template". Now I want my PDF document, so I navigate to "http://session.sites.sek/about/?pages2pdf=1" and I get my PDF document with the right session var : "Session set from Sitemap template" For the moment, nothing special happen. Everything work great. We are in debug mode.
       
      Now I turn OFF debug mode ($config->debug = false) :
      Then I navigate to  "http://session.sites.sek/home/" and the session variable "myvar" is set to "Session set from Home template". Then I navigate to  "http://session.sites.sek/sitemap/" and the session variable "myvar" is set to "Session set from Sitemap template". Then I navigate back to "http://session.sites.sek/home/" and the session variable "myvar" is set back to "Session set from Home template". Now I want my PDF document - as expected, the "myvar" should be set to "Session set from Home template" - so I navigate to "http://session.sites.sek/about/?pages2pdf=1" and here the problem happen. Instead of echoing  "Session set from Home template" in the PDF document, the phrase "Session set from sitemap" is echo'd (the last value recorded before switching from debug ON).  
       
      I made two small screencasts to show the issue :
      DEBUG ON (Everything is OK)
       
      DEBUG OFF
       
       
      I am missing something ? EDIT: YES, you are dumb!
      Why it is working with debug mode ON and not vice-versa ?
      Is there someone who already spotted this strange behavior ?
      Is there a PHP settings which should be modified ?
       
      ====================================================
      Edit:
      I needed to post just to figure myself that Pages2Pdf cache the document when $config->debug is false.
      😬😬😬
       
    • By chrizz
      Usually I write modules just for me and my projects because they are more or less individual. Mail Debugger is the first module which might be interested for someone else as well. 
      https://modules.processwire.com/modules/mail-debugger/
      Basically it covers two use cases: 
      1) Log outgoing emails
      2) In debug mode mails are send to a specified email address instead of the original recipient(s)
      I checked the compatibility for PW 3+ because unfortunately I don't have any other version for testing currently. Feel free to drop me a comment if the module works also for older PW versions. 
    • By FrancisChung
      PHPStorm for PW Devs
      This thread is a place for ProcessWire developers who use PHPStorm to share their experience, tips, frustrations, solutions, code snippets and generally discuss all things PHPStorm.
      From Wikipedia:
       
      Thanks @kongondo for the Visual Studio Code post earlier.
×
×
  • Create New...