Board Game Arena

I searched the forum for anyone requesting this, and I don't see any other posts of this nature, so I'm posting.

Has anyone though of the possibility of installing remote PHP debugging capability to the development server(s)? To be honest, the old school debugging of log writing gets old very quickly. Being able to step through code and see variable values would be a Godsend. There is this project - https://xdebug.org/ which might be helpful.

I hesitate to burden the BGA tech staff with more work, but this would be a dramatic improvement for BGA developers.

Thanks,
Dave

that would indeed help

There is a project to reproduce the BGA framework locally.
Maybe you could work on that to add the debug part

I can definitely get behind this idea. Professionally I do java and debugging there is a pleasure. It pains me everytime I need to place extra debugging longs.

Never mind debugging, how can I even log to a visible place from PHP?

Jeno73 wrote: ↑27 August 2024, 19:43 Never mind debugging, how can I even log to a visible place from PHP?

$myvar = "string to log"
var_dump($myvar)

$myvar will show as an error in your browser (and dev console) when this code triggers

Thank you

This page dedicated to wizdom about debugging https://en.doc.boardgamearena.com/Pract ... r_my_view)

Yes I have read that post and used many of the techniques detailed there for my debugging. But this is distinctly "old school" debugging (though TBH debuggers have been around since compilers. But for web-based back end code, debuggers where you can set breakpoints, step through code, etc. is a more modern thing).

A robust debugger saves boatloads in time and frustration; I'm sure the Javascript debugging tools built into the browser are used constantly by people developing for BGA.

While I am happy to admit that I might be wrong as I am not familiar with the IT infrastructure at BGA, I don't think it would require much effort or complexity to get this up and running on the development server.

For the site admins and framework developers, this would actually offer great benefits when they need to make changes to the framework. It also might cut down on people posting questions to the forum when they could answer things for themselves by inspecting variable values in the debugger. Parts of the framework are not that well documented, and frankly, its understandable because its very hard to cover everything especially in an easily searched way. Data and following the execution path would go a long way to shedding light on these.

Just my two cents.

Thanks for listening.

_Dave