This should explain the new custom panel process.

I did not know what some of the attributes did.

Note:

• content() is gone; it's largely in __init__
• there is now a mixture of attributes and methods that must be overridden. ( such as template )

we use $(function() {}), aka ondomready quite extensively. After enabling debugtoolbar we found out that the global $ object did not contain necessary extensions anymore. This is probably caused by the debug toolbar fragment (https://github.com/Pylons/pyramid_debugtoolbar/blob/master/pyramid_debugtoolbar/templates/toolbar.jinja2#L11) injecting the scripts in separate elements;

Now, we have seen some browsers, e.g. Chrome, parsing the body scripts in order, the onDomReady event is sometimes (quite often actually) fired after the debug toolbar's jQuery has been loaded, but before $.noConflict() is called.

Thus, 2 things should be changed.

1. $.noConflict(true) should be used to remove the jQuery variable too
2. all these scripts should be catenated, and even then they should refer to $ only by closure.

I patched this locally, but can do a PR if others find it useful (I think it is)...

I added a .ini setting of css_override_url. If set, that is injected into the Exception and Toolbar templates after the core css is loaded.

The use case is allowing developers to do a few simple things with css such as making the toolbar fit more information on the screen by:

• Make the font-size smaller • Decrease the padding on the tabs • Decrease the height of the toolbar nav/branding

I ran into some issues when working on an update to my package pyramid_session_multi, and decided to finally tackle #313 and backport some stuff into the standard debugtoolbar.

1. This introduces a new Session Panel to visualize the changes to a session. There is a Session section on the RequestVars panel; either that could be removed or this could go into that panel.

2. One of my tests inserted a float via random.random() into the session. This caused a fatal exception under Python3 due to sorting comparisons between a float and string.

• I updated several sorted methods in pyramid_debugtoolbar to handle this
• When the RequestVars and/or Headers panel(s) failed from the sort, the Headers panel never received a .response attribute and created another fatal Exception, which obfuscated/buried the stack trace about the original exception. I adjusted that panel with a default .response attribute and a conditional check.

Tests are provided, along with an example of the Py3 sorting exception; I figured I would include that with an AssertRaises, in case that behavior changes and the workarounds are no longer needed.

This works as intended, but I am considering it a WIP that needs feedback for two reasons:

• There is some duplication of data between two panels
• The RequestVars panel does a fancy trick to access the session via the wrap_load. I'm not sure if that is compatible or necessary with my attempt at this panel, as the new panel must always access the session.

Because of this, I think the right approach may to be keep RequestVars as-is, introduce the new panel, but have it controlled on a per-request/cookie basis like the profiling panel.

This is a proposed feature to make the panel a little more useful when debugging multi-host applications.

1. The JSON payload about a route is extended to include the hostname
2. A javascript toggle (default inactive) is offered to augment the title attribute of the sidebar elements with the hostname, which appears on mouseovers.

It has made my life a lot easier in a few situations.

The SqlAlchemy panel didn't have tablesorting, so I looked into adding it.

When I looked at the code, saw this pull request: https://github.com/Pylons/pyramid_debugtoolbar/pull/63

Then I noticed that pDebugSortable was still on the table clqass

And finally i noticed that the tablesorter JS is loaded on the debugtoolbar, but this line is commented out at the end of the javascript :

// $(".pDebugSortable").tablesorter();

Is there any reason why this was disabled? I couldn't find anything in the docs.

re-enabling it on the console makes it work, however the table-headers are not decorated with icons ( ie, it works if you know to click the table heads )

Right now we have a good base set of panels but I think it would be nice to also have panels that give better introspection on other services such as:

MongoDB Redis Memcached ElasticSearch HTML Validator

Views having log messages is normal, but having messages with level="error" is not -- it'd be nice if there was some way to tell without having to open the logging tab and manually scan the list every time, eg replace "4 messages" with "4 messages (3 debug, 1 warning)", or "4 messages (3 / 1)" colouring the numbers to show the levels

Here's an approach to a tablesorting fix (https://github.com/Pylons/pyramid_debugtoolbar/issues/148)

• It keeps the existing pDebugSortable css class as the trigger.
• pDebugSortable is documented in the panel writing docs.
• The sorting library is upgraded to the more modern fork, which should be better compatible with the current jquery and also handles additional sorting methods. (http://mottie.github.io/tablesorter/docs/example-widget-bootstrap-theme.html)

I included the entirety of the sortable's 'dist' library, although only 3 files are used. They are documented, along with the version, in a README in that directory. This should make ongoing maintenance much simpler.

This is regarding https://github.com/Pylons/pyramid_debugtoolbar/issues/205

I have a few notes:

1. I did some light housekeeping and alphabetized the imports and some settings in __init__.py; it was starting to get hard to understand what was/wasn't imported.
2. I added a new function to utils -- get_application_registry. An issue I ran into, is that the actual settings are located in two distinct areas, depending on where you access the request.

• The setup routines are called by the "end-user's" application. The settings are in request.registry.settings.
• The view routines are called within a "child" application (i guess due to the toolbar being a separate item via config.make_wsgi_app()). The settings are still located in the "end-user's" application, but this is now in request.registry.parent_registry.settings

The button_style in request_view was broken because of this (now fixed).

1. I enabled ToolbarStorage to have a configurable default too. All current requests to it specify the exact number, but there was a default already so i thought it should be configurable.

  response = self.handle_request(request)
  File "pyramid_debugtoolbar/toolbar.py", line 108, in toolbar_tween
    if ipaddr.IPAddress(remote_addr) in ipaddr.IPNetwork(host):
  File "pyramid_debugtoolbar/ipaddr.py", line 85, in IPAddress
    address)
ValueError: '192.168.117.153, 216.53.134.86' does not appear to be an IPv4 or IPv6 address

pyramid-debugtoolbar==1.0.2

Pyramid debugtoolbar should implicitly support running as a unix domain socket like it does for localhost. Development configuration with a domain socket signifies developer intent.

My development environment runs waitress with unix_socket inside a system (LXC/LXD) container without a network interface. The server is accessed with a socat instance running on the container host that forwards to the guest's socket. The system container runs a virtual network simulating public IPv4 address space and this is the simplest setup I've found that's compatible with the unpredictable IP addressing of the host.

When accessing the reverse proxy or directly ncing the unix domain socket, waitress returns a 500 and produces this backtrace:

2020-05-08 21:38:18,476 INFO  [wanmap.schema][MainThread] Initializing Engine
2020-05-08 21:38:18,477 INFO  [wanmap.schema][MainThread] Established Engine(postgresql://@/wanmap)
2020-05-08 21:38:43,930 ERROR [waitress][waitress] Exception while serving /
Traceback (most recent call last):
  File "/opt/wanmap/lib/python3.8/site-packages/waitress/channel.py", line 356, in service
    task.service()
  File "/opt/wanmap/lib/python3.8/site-packages/waitress/task.py", line 172, in service
    self.execute()
  File "/opt/wanmap/lib/python3.8/site-packages/waitress/task.py", line 440, in execute
    app_iter = self.channel.server.application(environ, start_response)
  File "/opt/wanmap/lib/python3.8/site-packages/paste/deploy/config.py", line 291, in __call__
    return self.app(environ, start_response)
  File "/opt/wanmap/lib/python3.8/site-packages/paste/deploy/config.py", line 291, in __call__
    return self.app(environ, start_response)
  File "/opt/wanmap/lib/python3.8/site-packages/pyramid/router.py", line 270, in __call__
    response = self.execution_policy(environ, self)
  File "/opt/wanmap/lib/python3.8/site-packages/pyramid/router.py", line 279, in default_execution_policy
    return request.invoke_exception_view(reraise=True)
  File "/opt/wanmap/lib/python3.8/site-packages/pyramid/view.py", line 778, in invoke_exception_view
    reraise_(*exc_info)
  File "/opt/wanmap/lib/python3.8/site-packages/pyramid/compat.py", line 179, in reraise
    raise value
  File "/opt/wanmap/lib/python3.8/site-packages/pyramid/router.py", line 277, in default_execution_policy
    return router.invoke_request(request)
  File "/opt/wanmap/lib/python3.8/site-packages/pyramid/router.py", line 249, in invoke_request
    response = handle_request(request)
  File "/opt/wanmap/lib/python3.8/site-packages/pyramid_debugtoolbar/toolbar.py", line 220, in toolbar_tween
    or not addr_in(client_addr, hosts)
  File "/opt/wanmap/lib/python3.8/site-packages/pyramid_debugtoolbar/utils.py", line 200, in addr_in
    if ipaddress.ip_address(u'' + addr) in ipaddress.ip_network(u'' + host):
  File "/usr/lib/python3.8/ipaddress.py", line 53, in ip_address
    raise ValueError('%r does not appear to be an IPv4 or IPv6 address' %
ValueError: 'localhost' does not appear to be an IPv4 or IPv6 address

Before config.add_debugtoolbar_panel, the way to add custom panels was via

config.registry.settings['debugtoolbar.panels'].append(PANEL)

or

config.registry.settings['debugtoolbar.extra_panels'].append(PANEL)

The end behavior of this, was an adjustment to the application config (.ini but now it can by other formats) value of debugtoolbar.panels only affected the ordering/enablement of the default Pyramid panels.

After this api change, everything added via add_debugtoolbar_panel (which happens transparently for 3rd party items via debugtoolbar.includes in the config) goes into the generic panels list. Consequently, utilizing the config value to change the ordering of debugtoolbar.panels will remove any of the panels that were added in debugtoolbar.includes UNLESS they are explicitly named there.

I propose some configuration mechanism that would affect the ordering of panels, so developer can more-easily reorder the panels without having to declare them multiple times.

perhaps something like this...

• debugtoolbar.panels_reorder The list of registered panels is reordered to have these elements, in this order, first. panels that are not listed appear afterwards.
• debugtoolbar.panels_removePanels listed here will be removed.

Under the current toolbar design, if an error occurs in a debug panel or panel rendering, a generic wsgi error is generated.

I propose wrapping the invocations of various panel API methods in a try/except block. If an error is raised it is either tracked on the toolbar or the panel via a new attribute .is_panel_error or similar. it is logged at an log.ERROR level too. the html for broken panels is replaced with a 'error in the panel' message.

thoughts? this would require adding a new panel attribute or some code to track broken panels, so I wanted to discuss before trying a PR.

When doing repetitive testing against a single route, it's become a bit of a chore to determine which request I wished to inspect. The left sidebar shows the same information under "Requests", and the main right content area does not offer anything that can help.

I'd like to address this in the DebugToolbar itself, by assigning a serial number to each request - then displaying it either on the left sidebar or on a panel.

Thoughts? Comments? Preferences?

The issue appears to happen when I raise a pyramid.httpexceptions redirect early during a class-based view handler. (in __init__, not call() ). I haven't been able to pinpoint exactly why this happens (version 4.5). The stacktrace below.

I tweaked the debugtoolbar class to handle not having a response and can easily submit a PR for it - but this doesn't make much sense to me and I wonder if this is an issue with Pyramid's handling.

	2018-12-04 14:01:30,295 ERROR [waitress][waitress] Exception when serving /
	Traceback (most recent call last):
	  File "/Users/jvanasco/webserver/environments/legacy-2.7.13/lib/python2.7/site-packages/waitress/channel.py", line 338, in service
		task.service()
	  File "/Users/jvanasco/webserver/environments/legacy-2.7.13/lib/python2.7/site-packages/waitress/task.py", line 169, in service
		self.execute()
	  File "/Users/jvanasco/webserver/environments/legacy-2.7.13/lib/python2.7/site-packages/waitress/task.py", line 399, in execute
		app_iter = self.channel.server.application(env, start_response)
	  File "/Users/jvanasco/webserver/sites/MyApp/trunk/python-packages/myapp/myapp/pyramid_utils/request.py", line 32, in __call__
		return self.application(environ, start_response)
	  File "/Users/jvanasco/webserver/environments/legacy-2.7.13/lib/python2.7/site-packages/pyramid/router.py", line 270, in __call__
		response = self.execution_policy(environ, self)
	  File "/Users/jvanasco/webserver/environments/legacy-2.7.13/lib/python2.7/site-packages/pyramid/router.py", line 279, in default_execution_policy
		return request.invoke_exception_view(reraise=True)
	  File "/Users/jvanasco/webserver/environments/legacy-2.7.13/lib/python2.7/site-packages/pyramid/view.py", line 768, in invoke_exception_view
		reraise_(*exc_info)
	  File "/Users/jvanasco/webserver/environments/legacy-2.7.13/lib/python2.7/site-packages/pyramid/router.py", line 277, in default_execution_policy
		return router.invoke_request(request)
	  File "/Users/jvanasco/webserver/environments/legacy-2.7.13/lib/python2.7/site-packages/pyramid/router.py", line 260, in invoke_request
		request._process_finished_callbacks()
	  File "/Users/jvanasco/webserver/environments/legacy-2.7.13/lib/python2.7/site-packages/pyramid/request.py", line 138, in _process_finished_callbacks
		callback(self)
	  File "/Users/jvanasco/webserver/environments/legacy-2.7.13/lib/python2.7/site-packages/pyramid_debugtoolbar/panels/headers.py", line 19, in finished_callback
		self.process_response_deferred()
	  File "/Users/jvanasco/webserver/environments/legacy-2.7.13/lib/python2.7/site-packages/pyramid_debugtoolbar/panels/headers.py", line 31, in process_response_deferred
		response = self.response
	AttributeError: 'HeaderDebugPanel' object has no attribute 'response'

Sqa.py code is adding to the DB connection the attribute pdtb_start_timer here

Then it removes this attribute. When accessing the DB with multiple threads this code breaks if both threads are executing and then the first that reaches the after will remove it and the second will fail.

 in _execute_on_connection
    return connection._execute_clauseelement(self, multiparams, params)
  File "/home/meili/.pyenv/versions/3.6.4/envs/radar364/lib/python3.6/site-packages/sqlalchemy/engine/base.py", line 1010, in _execute_clauseelement
    compiled_sql, distilled_params
  File "/home/meili/.pyenv/versions/3.6.4/envs/radar364/lib/python3.6/site-packages/sqlalchemy/engine/base.py", line 1153, in _execute_context
    context.executemany)
  File "/home/meili/.pyenv/versions/3.6.4/envs/radar364/lib/python3.6/site-packages/sqlalchemy/event/attr.py", line 256, in __call__
    fn(*args, **kw)
  File "/home/meili/.pyenv/versions/3.6.4/envs/radar364/lib/python3.6/site-packages/pyramid_debugtoolbar/panels/sqla.py", line 44, in _after_cursor_execute
    delattr(conn, 'pdtb_start_timer')

Using latest version, 4.5

Unfortunately this code will still be executed, even is this panel is not configured. I tried to fix this issue without any luck so far. Maybe one way to start is to isolate this code so it can actually be switched off.