Better Pages Debugging

[mayamcdougall]

So, I've got a semi-Pico-3.0 related issue to bring up. ~It could probably be it's own issue if you want to have a discussion on it.~

Yeah, went ahead with that. 😅

In older versions of Pico (below 2.0, not a typo) I could easily inspect pages using the | json_encode filter to help get an idea of what things looked like. You know, sometimes in programming it's helpful to actually inspect your data structure so that you can *facepalm* when you realize you didn't lay things out like you meant to. 🤦🏻‍♀️

Somewhere along the line, I assume with Pico 2.0, next_page and previous_page became actual references to those pages (I assume), causing an Array Recursion error when attempting to print them using | json_encode.

I tend to get around this by doing a "Smiley Slice", lol, by accessing page[:-3] instead of page. 😂

(On a related note, I don't really have a good way to do this for all pages, as Twig doesn't seem to like me stringing together two slices like pages[:][:-3] or something.)

Anyway, with Pico 3.0, I no longer see this Array Recursion error, the | json_encode just silently fails. No idea if this was a change in Twig, a change in its default configuration, or just something different about my test environment specifically. It has been a little annoying though, when trying to poke and prod at the pages data.

I'd originally planned to include a reference to this clever "Smiley Slice" in the Docs rewrite as a "ProTip" kind of thing, but it also feels a bit clunky.

Going forward to Pico 4.0 and the idea of Pages as Objects would probably break this hacky workflow of mine even further. 😉

So, what are your thoughts on, in the future (eg, not Pico 3.0, but maybe a point release, or even 4.0), including some debugging functions, like a way to "Pretty Print" the collection of Page Objects? Something formatted a little nicer than the | json_encode filter.

Idk, maybe it's just me that needs that "facepalm reminder" that I used page.meta.config.option instead of page.meta.option, and that's why nothing's working as expected. 😂

Might also be useful for making sure that pages() returns the data you expected. (I know there's probably a few cases where I've used depth or depthOffset in a manner other than I really intended to)

Any thoughts on this? Any other ideas for debug tools Pico could provide for theme developers?

[PhrozenByte]

I can only assume that json_encode started detecting the recursion and thus bails.

Actually the only real solution to this is to finally implement page objects. With objects we gain full control on what is being encoded to JSON (https://www.php.net/manual/en/jsonserializable.jsonserialize.php), as well as what is being dumped when using the dump() function (https://www.php.net/manual/en/language.oop5.magic.php#object.debuginfo)

[mayamcdougall]

I can only assume that json_encode started detecting the recursion and thus bails.

Well, yeah, I don't think it's smart enough to figure that out. 😂

Point being just that it used to throw an error and now it doesn't (though, again, could just be my setup).

Mostly just wanted to start thinking about what this would look like in the future. I'd rather see a replacement for | json_encode in the form of a filter or function that would make something more readable. JSON is a bit dense for combing through a large amount of data like this anyway.

To take this idea to more of an extreme, maybe it could inject some HTML with inline-styles for a richer breakdown of the data requested (all of pages or just a subset returned by pages()). Maybe some collapsable/expandable sections to deal with sheer amount of data.

In my head, could be kind of like how phpinfo() will kind of "hijack" the page to show it's own table of data, regardless of where you put it (just, maybe a little more gracefully).

Idk, that wasn't even part of my idea before, so I guess the brainstorming is already working. 🤔

Honestly, I just kind of wanted to mention my "Smiley Slice", and the fact that the recursion error had disappeared for me. 😂 😉

[PhrozenByte]

IMO the reason why debugging is hard right now is because of the recursion, not because of the output not being styled :wink: You could write a debug_pages Twig macro though if you really want to (simply skip the recursive keys with https://twig.symfony.com/doc/1.x/filters/filter.html). We will get rid of the recursion with page objects.

[mayamcdougall]

IMO the reason why debugging is hard right now is because of the recursion, not because of the output not being styled 😉

I just like going above and beyond with stuff. 😂

You make a good point about making a Twig macro though. 🤔

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1: