in devono essere avviati i vari autodiscover:

admin.autodiscover()  # Not needed for dj > 1.7

in aggiunta devono essere aggiunti i pattern per la localizzazione. jmb kick dovrebbe fare questo in automatico.


jmb.core only looks for 3 variables, no one is required:


determine visibility of Warnings based on module and mesage text


patches that will be applied


patches that won’t be applied


class jmb.core.apps.JmbCoreConfig(app_name, app_module)[source]

An AppConfig that take care to monkey patch django and apply control over DeprecationWarning


Override this method in subclasses to run code when Django starts.


Add filter warnings rules so as to ignore warnings from modules or matching pattern defined in WARNING_RULES

WARNINGS_RULES must be a list of tuples whose first element is a module name (e.g.: ‘jmb’, ‘jmb.core’, ‘django.contrib.auth’, ‘cms’) and the second element is a regexp matching the text of the message. These two values will be passed to warnings.filterwarning as module and message parameters.


WARNING_RULES It’s based on 2 criteria:

  • the module where the warning is issued

  • the regexp of the text of the error

It uses warning.filterwarnings and is fired from within AppConfig in the JmbCoreConfig.__init__ so as to come after django’s configure_logging but before any module import

WARNING_RULES is a list of tuples, each tuple is composed of a module_name and a regexp.

The goal of this settings is to silence warning coming from packages that you don’t want/may change so that you don’t miss important warning that you shoud take care of. The main necessity comes from the fact that in the transition from on django rel to the other some packages may raise warning that flood the console. If I concentrate on porting one package I don’t want other packages to hide these messages in the mess of other ones.

An example of the use can be:

    ('cms', None),
    ('djangocms_googlemap', None),
    ('', '.*(PagePermission|PageUserAdmin|ViewRestriction).*'),

the last tupe is needed becouse in some situation. filterwarning doesn’t understand where the messages was originated (I guess when a metaclass generates the classes)

Monkey Patch

Jumbo relies on some patches to the official django version that can be applied using the function jmb.core.monkey.patch(). Before django 1.7 we used to monkey patch in settings and in In Dj1.7 AppConfig is out preferred place.

There’s no needed settings to make it work apart from putting jmb.core soon enought in the list of INSTALLED_APPS.

If you want to change which patches are applied you can use


a list of all patch names to be applied


a list of all patch names to be excluded

Available patches that you may be willing to disable are:


needed to make package namespace be visible


better time, date, datetime picker for the admin


prevents cms to replace stock jQuery with it’s own


allows to print in console errors of a form


needed for portability between old and new versions.

jmb.core.monkey.patch(include=None, exclude=None)[source]

Apply all patches Jumbo relyes on. Currently management commands, jquery, and timepicker

  • include – a list of strings naming the patches that will be applied (optional).

  • exclude – a list of strings naming the patches that will not be applied. ‘jquery’ patch will only be applied if cms is in INSTALLED_APPS

management commands

Django find_management_module fails at finding modules when namespaces are used.

This version of find_management_module tries a real import when django fails to find the module. The difference is that django only uses:


that doesn’t implement full module search algorithm. We’re going to place this code in settings/, the older way to place it in :file:` doesn’t work as is not found when calling from command line as is not called:

from jmb.core import monkey

At the moment there’s an open ticket

Django and jQuery


MonkeyPatch django-cms not to overwrite jquery.

While django make attention to use djangojQuery and not to overwite standard $(), so different versions can coexist, PageAdmin and PluginEditor overwrite it with django.jQuery. Utilizzata in cosi:

from jmb.core import monkey

if settings.CMS_ENABLED:
    urlpatterns += patterns('',
        url(r'^', include('cms.urls')),

Errors in forms

When running the development server, print in the console which errors have been raised when saveing an object. This in necessary when not all fields are used in a form and Django just says “Fix errors below”

This will work if you have a variable called RUNNING_DEVSERVER that can be initialized as follows:

import sys
   RUNNING_DEVSERVER = (sys.argv[1] == 'runserver')
except KeyError:



Rel 1.6 changed method name Manager.get_query_set to Manager.get_queryset


Datetime and time widgets in Django are pretty poor ones.

Html widgets used by admin are defined in django.contrib.admin.options in a dict named FORMFIELD_FOR_DBFIELD_DEFAULTS.

We overwrite it in jmb.core.admin.options and define a widget that is derived from jQuery.ui’s default one.