(Var Dump) Debugging (in Fusion) for Beginners // Neos/Flow

Community Newcomer's Corner
1

It was quite confusing for me when i wanted to get something from the ${request} context object in fusion. I dindt know where my data might lie nor how its called, only that i need “insert your use case”. (in my case, it was the request header)

Get ready for a little noob user story:

First, i tried to debug the ${request} via Neos.Fusion:Debug - which resulted in an error (string conversion) but via this error i had the php class at hand.

Then i looked at the php class and was quite confused. After reading the comments i though that accessing the method getHttpRequest() might be a good idea for more insight … but i had no idea how to access methods specially getters.
After nearly brute forcing myself to access this method (trying out combination with brackets and without and variating the case) i had this silly idea to just leave out the “get” and do only ${request.HttpRequest}.
Now my fusion debug sounded the alarm, i hit another class!

… i looked up this class too and found a promising getter but i dindnt know how to access it - with some help in the slack its all done now: https://neos-project.slack.com/archives/C050C8FEK/p1627322577077200

end of story
-| wenn sie nicht gestorben sind dann leben sie noch heute |-

var_dump for live

But the thing is that it was not an easy experience. I usually like to just print, var_dump or console.log my way through to the goal. Which works mostly fine - given you have this functionality.

Luckily, i found a Flow var_dump implementation for Fusion via eel:

PackageFactory/PackageFactory.Fusion.Debug: Simple methods to debug stuff in Fusion (github.com)

Which allows to dump all contents no matter whether node, string or object. I really like that. While trying that package out and seeing all the possible options of a class some answers in the slack dindt feel magic but where rather logically enforceable :wink:

But one thing is still confusing: Some internal variable naming:

when i fx. do this:

root = ${Debug.var_dump(request)}

image

i get some rootRequest under the request dumped out too:
and say i like content x from the rootRequest the next step would carelessly be to use:

``${Debug.var_dump(request.rootRequest)}`

but this would not work!
Since there is no getter getRootRequest() and no public var named rootRequest ($rootRequest is protected).

For me, it is confusing why the variable is not named httpRequest as this would keep me from headache and writing this post :wink:

some solutions might be:

  • can the variable be renamed?
  • or can there be in the var_dump also some functions listed
  • or can ther be for each object a link to github so you can easily see the source code?

thanks for reading!

1 Like
2

I had to look myself, because that’s indeed very odd. But I think I can shed some light on that: What you see is indeed the protected property and that’s because Flow’s var_dump uses reflection to iterate all properties regardless of their visibility:

Now what you - and I - would expect is that var_dump behaves exactly like all Fluid/Fusion templates where it uses getters before the actual properties (using Flow’s ObjectAccess helper). But in any case I agree that the property should be named like the getter.
The reason that’s not the case is that this code is really really old - goes back to 2012. The rootRequest was just an internal cache for the upper most request, which not necessarily was a HttpRequest (CLI/HTTP requests were still combined in a single abstraction back then). When we refactored that and separated into Action (MVC) and CLI Requests (2 years ago or so), we did not really think about renaming that internal property. I also don’t think renaming should be an issue - the property is protected and encapsulated, so other than in the var_dump you shouldn’t even see it.

1 Like