Hard to use in development environment

I just used django-analytical to integrate Piwik analytics into a site, using the Piwik-specific template tag as documented here. It works great in production, but unfortunately it causes problems for our development environment.

Obviously we don’t want to track visits to the site when it’s running on a local development server. It seems like it would be best to simply not embed the tracking code in the templates when we’re running in development. Furthermore, it would nice to not be required to set PIWIK_DOMAIN_PATH or PIWIK_SITE_ID in the development settings, since they are unnecessary.

The documentation on PIWIK_SITE_ID says:

If you do not set the site ID the tracking code will not be rendered.

This implies that the {% piwik %} template tag won’t render the tracking code if PIWIK_SITE_ID is not set, which would be very desirable behavior for the use case of the development environment. In that case, you would only have to set PIWIK_SITE_ID in settings/production.py to get the Piwik code to render in production, and it would not be rendered in the development environment.

Unfortunately, this part of the documentation appears to be incorrect. Failing to set PIWIK_DOMAIN_PATH or PIWIK_SITE_ID raises an AnalyticalException, which breaks template rendering in the development environment.

For our project, this necessitated an annoying workaround: we set PIWIK_SITE_ID to 0 (an invalid value) in settings/development.py, pass that setting to the template context via a context processor, and conditionally render the Piwik template tag based on the value of PIWIK_SITE_ID. We can’t even set the PIWIK_* values to None, which would be more explicit and therefore preferable, because of the validation in get_required_setting.

It would be better for the documented behavior to be implemented, because that would make django-analytical work simply in both production and development environments, and would not require the aforementioned workaround. Another option is to simply correct the documentation, although that would leave the annoying behavior in place and still necessitate a workaround.

Am I missing anything here? Are there best practices for using django-analytical in a development environment that I am unaware of?

[garrettr]

I just discovered that the generic tags ({% analytical_head_top %}, etc.) work differently than the specific tags (e.g. {% piwik %}). Unlike the specific tags, which fail with an error if the corresponding configuration is unavailable or invalid, the generic tags fail silently if there are no analytics services configured in the settings. I think the generic tags’ behavior is better, and makes it easy to use django-analytical in development, staging, and production environments.

[bittner]

BTW, as I suspected, the reason why the generic template tag works and the single one throws an exception is such that the generic tag ignores exceptions that happen in the single implementations. Exceptions that occur in the contribute_to_analytical function pass silently (for a valid reason) this way.

When you do things “the manual way” you also have to make sure yourself that either the exception is silenced or, better, all preconditions for the code being successfully executed (or not being executed at all!) must be met. As I pointed out earlier you probably had a {% load google_analytics %} in your template that was not covered by any {% if not debug %} clause, and according to the exception you don’t seem to set the GOOGLE_ANALYTICS_PROPERTY_ID in your Django settings when debug is True.

If this is all true then there’s little to document. Then the implementation behaves as we should expect.