The main issue I fixed is that in the admin the Markdown textareas were very narrow, and there was no way to fix it from an application (without monkey patching). The issue was due to the fact that MarkdownField explicitly sets its form_class to MarkdownFormField, which clobbers any attempt to override the widget. Based on the comment in the source, this was apparently done in an attempt to prevent django.contrib.admin.ModelAdmin from overriding the default widget. The correct way to do that is what has already been implemented in this project – using formfield_overrides in a subclass of ModelAdmin. So, since the problem is already solved in the correct way, I'm pretty sure I'm more or less just reverting it to an earlier behavior.
The other issue this pull request fixes is an issue when using a Markdown field on the frontend results in a JS error when JS files are included at the bottom of the body (which is a best practice). The closures in editor_init.html explicitly reference the variable jQuery in the global scope, but since jquery isn't included until later, the variable doesn't yet exist. My fix actually simplifies the code quite a bit by identifying the markdown elements using a "widget" custom data attribute, then running markItUp using a selector in jquery.init.js. Since we still need extra_settings I changed it to simply set it as a global variable named extra_markitup_settings, since it'll have the same value for each field.
I also removed the __init__ method from MarkdownWidget, since all it wasn't actually doing anything that wouldn't happen if it didn't exist.
Coverage decreased (-1.92%) to 56.31% when pulling 4692382710a286f0c86b501095066cd726f6622e on rspeed:develop into 0c8081b0610bc73c996c15d27aa62b4602c00aee on klen:develop.
The main issue I fixed is that in the admin the Markdown textareas were very narrow, and there was no way to fix it from an application (without monkey patching). The issue was due to the fact that
MarkdownField
explicitly sets itsform_class
toMarkdownFormField
, which clobbers any attempt to override the widget. Based on the comment in the source, this was apparently done in an attempt to preventdjango.contrib.admin.ModelAdmin
from overriding the default widget. The correct way to do that is what has already been implemented in this project – usingformfield_overrides
in a subclass ofModelAdmin
. So, since the problem is already solved in the correct way, I'm pretty sure I'm more or less just reverting it to an earlier behavior.The other issue this pull request fixes is an issue when using a Markdown field on the frontend results in a JS error when JS files are included at the bottom of the body (which is a best practice). The closures in
editor_init.html
explicitly reference the variablejQuery
in the global scope, but since jquery isn't included until later, the variable doesn't yet exist. My fix actually simplifies the code quite a bit by identifying the markdown elements using a "widget" custom data attribute, then runningmarkItUp
using a selector injquery.init.js
. Since we still needextra_settings
I changed it to simply set it as a global variable namedextra_markitup_settings
, since it'll have the same value for each field.I also removed the
__init__
method fromMarkdownWidget
, since all it wasn't actually doing anything that wouldn't happen if it didn't exist.