dubug or trace for login

[finanalyst]

The login plugin triggers various events - I'm looking at onUserLogin and onUserLoginRegisterData. However, the following line in the relevant function in my plugin generates no output.

$this->grav['debugger']->addMessage('function triggered');

I used a $datafh = File::instance then $datafh->save('OnUserLogin triggered');

The string was saved to disc, so the function triggered, but the debugger line did not generate output.

Is there another way of creating a trace or debug information during the Login process?

Actually, I am trying to work out how to use these login events and there is no documentation about them.

I also would like to understand how the page visibility field works.

[mahagr]

Because of redirect, debugbar message will not be shown. Events are documented in the README.md of the plugin.

[finanalyst]

You are no doubt overworked and overburdened, and perhaps, like me, not paid to develop stuff for GRAV or to answer questions to ignorant idiots like me who don't know the whole of the GRAV system.

However, if it is not possible for you to give a llittle bit more explanation, I really can't understand why you would write something - no matter how technically correct - that is just plain irritating.

To illustrate:

It doesn't help to be told why 'debugging' doesn't work. The whole of GRAV documentation tells developers of two ways to get debug information (addMessage and dump()). Neither of them work with Login. And this absence is NOT mentioned in the Login documentation.

It would be more helpful to suggest a way of doing it - other than the hack I suggested. It might have also been nicer to comment on the hack, perhaps to say it is the only way of getting trace.

The README.md lists the events, it does NOT document them.

Documentation for most people means providing the calling function, the variables that are passed, and some idea about how to use them.

README.md also lists the events as part of what appears to be a Change log, rather than as explanation. It is incredibly confusing to have sections listed by the date of the change, not by some form of content context, eg. Callback Functions.

Furthermore, even in plugin.php, there is no call to onUserLoginRegisterData, which would at least provide some way as to how it is supposed to be used. There is a called registered to onLogin, so I could see there is a variable of type LoginEvent passed. a) I haven't been able to get the onUserLoginRegisterData event to fire at all, b) I do not know enough about RocketTheme Events and/or php to work out how I am supposed to get data back to the plugin. What is the syntax? $this->login->data['myvar'] = 27; ?

I have found how page visibility works, but only by searching this Forum. A FAQ perhaps????.

[Vivalldi]

@finanalyst First off welcome to Grav! We always appreciate new developers. @mahagr explained why you are unable to debug with brevity. However it would seem that in your irritated state you have been unable to extrapolate what was meant by that and how to work around it. The login plugin uses redirects, meaning the server is sent a separate request. This causes any logs (either via dump or through grav debugger) to be lost as the server handles the new request. Now I will tell you a work around that I do not advise, however, I think you will find useful in your current situation. Call a dump with whatever data you are looking for and then immediately afterwards call exit. This will stop ALL further actions and send any existing output to the client.

If you are still irritated and unable to extrapolate from this explanation I ask that you join us on our slack channel. Once again, welcome to Grav!

Cheers! ~@vivalldi

[finanalyst]

@Vivalldi Thank you. I appreciate you getting back to me quickly. I appreciate the trace hack suggestion.

It does seem to me that if a redirect looses debugger/dump messages, then at least something should be documented in the Login plugin.

[Vivalldi]

That's just PHP for ya. We could probably find a way to implement a work around but it's not necessarily worth the writes to memory. If you want to be more efficient I suggest using and IDE where you can pause scripts mid execution and then continue.