ProcessDebugPageFields

[robert]

I often had the need for an overview of all used fields and their contents for a specific page/template while developing new websites without switching to the backend, so I made a small module which lists all the needed information in a readable manner (at least for me):

Debug Page Fields

https://github.com/robertweiss/ProcessDebugPageFields

It adds two new properties to all pages:

• $page->debugFieldValues – returns an object with all (sub-)fields, their labels, fieldtypes and values
• $page->debugFieldTypes – returns an object with all fieldtypes and their corresponding fields

// List all values of a pages
$page->debugFieldValues

// List a specific field
$page->debugFieldValues->fieldname

// List all used fieldtypes of a page
$page->debugFieldTypes

I recommend using it in combination with Tracy Debugger, Ray, Xdebug etc. as it returns an object and is only meant for developing/debugging uses. 

For now, the fieldtype support includes mostly fieldtypes I use in my projects, but can easily be extended by adding a new FieldtypeFIELDNAME method to the module. I use it with five different client installations (all PW 3.0.*), but of course there might be some (or more) field configurations which are not covered correctly yet.

Supported fieldtypes

• Button
• Checkbox
• Color
• Combo
• Datetime
• Email
• FieldsetPage *
• File
• FontIconPicker
• Functional
• Image
• ImageReference
• MapMarker
• Multiplier
• Mystique
• Options
• Page
• PageIDs
• PageTitle
• Radio
• Repeater *
• RepeaterMatrix *
• RockAwesome
• SeoMaestro
• Table
• Text
• Textarea
• Textareas
• Toggle
• URL

* The fields with complete subfield-support also list their corresponding subfields.

Installation

1. Download the zip file at Github or clone the repo into your site/modules directory.
2. If you downloaded the zip file, extract it in your sites/modules directory.
3. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module.

As this is my first ›public‹ module, I hope I did not miss any important things to mention here.

[adrian]

Hi @robert - thanks very much for your work on this. 

I few initial observations for you ?

1) I think it would be useful if it worked in the admin (ie change the autoload to allow this) because Tracy's Console panel sets $page to the object of the page being edited.

2) If you are running recent versions of PHP, you get an error on line 180. A simple fix is to replace count with wireCount

3) On line 185 you need to replace get_class($val) with is_object($val) && get_class($val) to prevent a "on bool" type error. Again, probable related to recent PHP versions.

4) I am not yet sure what extra info this provides over the Page Field List & Values section of Tracy's RequestInfo panel. Is it just a formatting preference or is it the support for fields like Mystique - not sure if Tracy would handle this properly or not - never tried it.

Thanks again!

[robert]

Hi @adrian,

first of all thanks a lot for your fast and nice reply, this community is always so helpful and motivating! 

1) Good idea, I never really used it that way, but I definitely will check it out and change the autoload setting.

2 & 3) Thanks for the hints, I changed the code as you suggested.

4) You are right – in combination with Tracy and usual field configurations, the difference is mostly a formatting preference. As I like using Ray in an external window for debugging, the module helped me to always get identical informations in different environments. Another thing which was important to me is the support for ›subfields‹, so that I can immediately see the content of repeater matrix items inside repeaters inside fieldset page fields etc. etc. (you see the point … ?). The third thing is – as you already mentioned – the support for all kinds of fieldtypes in a more or less consistent and simplified way.

 

[robert]

Hi @adrian,

I changed the autoload to true according to your suggestion, so the properties will be added to the $page in the admin as well. Now I get the following error message from Tracy Debugger every time I open an admin page (no error shows up in the frontend):

Quote

Modules: Failed to init module: TracyDebugger - Tracy\Debugger::dispatch() called after some output has been sent. Try Tracy\OutputDebugger to find where output started.

The weirdest thing is: when I duplicate my module and change the classname to something else (TestModule or similar), uninstall the original module and install the copy instead, the error is gone. And when if I remove all the code from the original class except the getModuleInfo method, the error is still there. I checked the behaviour in two other installations, they show the same error.

Maybe this is some sort of race condition with autoload modules? I tried to understand the OutputDebugger class mentioned in the error, but did not yet figure out what it does or how it can help ?

This issue has no priority at all, but maybe you have an idea where I could look further. Debugging the debugger … ?

[adrian]

@robert - easily fixed by removing the PHP closing tag at the end of your module file. It's best practice to leave this off to prevent scripts unintentionally outputting content.