Symphony.

I loved last changes of Debug DevKit extension and I really appreciate your work. But there are few things that could be improved.

• It should provides someway to view database queries.
• Have a separate column for Data Sources on Profile > Memory Usage.

Leave your opinion! Thanks!

I agree about viewing DB queries. At the moment I have to trigger an error in the PHP to view the errors in the error handler page! I have added this as a view to the Profile Devkit and sent a pull request — I hope Rowan agrees with my change.

In 2.0.7 DSs are shown in the Memory Usage list, although they aren’t very obvious. I have sent a pull request suggesting they be prefixed Datasource: ... and Event: ....

Slight hijax, but does anyone else think it’s a bit concerning that the DB queries are viewable by the public when an error occurs?

A generic error template would be nice for ‘non-logged-in’ users.

Best practice would suggest a generic error page for non logged-in users, definitely. I remember there being mention of adding 500 as another Page Type so developers can define the page to use,

However, in my experience having users send me their error messages is useful. Is it just the query list that concerns you? Perhaps the error and backtrace could be shown but no query log?

It’s a double edged sword really.

As a developer, knowing as much as you can is excellent for debugging, but then as a user, you don’t really care about the technical details (especially if you aren’t web/software savvy). Users you just want to get to where they wanted to go (or thereabouts aka. helpful error pages).

Omitting the query log could work for non logged-in users, but as you mentioned, you lose a bit of the trail.

I know it’s a bit convoluted, and possibly could be done with an extension already, but what if each error was ‘saved’ inside manifest and was available to developers through the backend?

The frontend user could then see a nice 404/error page and get back on track quickly. To extend it further, this page could have a ‘notify webmaster’ button that sends an email to the Authors who are Developers with the error’s system-id in email to help filter through the error log.

This would be pretty much transparent to us regular Symphony users/devs (because we would be logged in so get the error page as it is now), but would hide the errors from the users.

Thoughts?

what if each error was ‘saved’ inside manifest and was available to developers through the backend?

All errors, both shown through the error page and those that are silent, are logged into /manifest/logs. While they aren’t saved with an ID, their exact time is logged. If a custom error page for frontend users is offered (using a 500 Page Type or similar) then an “Alert Webmaster” link could just print the date/time of the error:

"An error occurred. Please contact the website owner quoting "2010/01/07 09:56:14"

You can then look in your logs for the specific time.

That might be the least complicated way of implementing this.

The /manifest/log used to be available for viewing in the backend through an undocumented URL but searching the codebase I can’t find it any more. Perhaps Rowan’s logsdevkit should be an official bundled devkit as this seems to provide a UI for logs. I’ll try it now…

symphony/system/log works IIRC.

I agree with your first paragraph too, quickest and easiest way for sure :)

symphony/system/log works IIRC.

Bingo! Thanks.

I just installed Rowan’s Logs Devkit which worked like a dream.

In 2.0.7 DSs are shown in the Memory Usage list, although they aren’t very obvious. I have sent a pull request suggesting they be prefixed Datasource: … and Event: ….

That’s great. What do you think of showing Data Source name instead of the handle value?

The profiler only logs the handle (for the Datasource Execution page). It’s possible to look up the full name but I think it’s an unnecessary complication.

If a custom error page for frontend users is offered (using a 500 Page Type or similar) then an “Alert Webmaster” link could just print the date/time of the error

Or even better: automatically email the webmaster when any serious errors occur. In my experience, no visitor ever mails the webmaster when a bug occurs, and when they mail, they don’t give enough information to really track the problem.

Nick, what would be the easiest way to automate the mailing process? Would hacking into the core (extending the error class) be the best way?

I think this would be a great addition to the core (if it can be turned off in the prefs panel, ofcourse!)

Have you seen how long your error logs can get?! It would always be the first option I would disable on each new build…

Yes, but most of those are warnings or other non-essential (non-serious) errors.

Ofcourse I would only want to be emailed when a visitor gets an error page because of the error, not for every warning..

I think what nick was alluding to is that in 2.0.7 it doesn’t matter whether it’s a warning or an error, it will still halt and display the error page.

This means that every entry in your log is a ‘serious error’ as it’s breaking your site.

I think what nick was alluding to is that in 2.0.7 it doesn’t matter whether it’s a warning or an error, it will still halt and display the error page.

Is it? I don’t have 2.07 installed anywhere, but if it does I would consider it a bug. And I would still like to be notified in this case, as a user has gotten the error page aswell (so it is urgent, and requires fixing)

But still, halting for warnings? I mean, that’s like shutting down all traffic on an airport if a cashier makes a mistake in a shop in the tax free zone..

Haha. Yeah, I believe this is the major reason why alot of extensions are breaking with 2.0.7.

If you have time, try installing 2.0.7 in a local environment and test for bugs/fixes. I’m sure the team would appreciate it!