Django Admin and TinyMCE HowTo

Monday, December 22nd, 2008

We’ve just rolled out TinyMCE to use with our Django Admin interface.

As we encountered several gotchas along the way, we felt it would be instructive to the community to illustrate the steps here, in true cookbook (aka “HowTo”) fashion.

Here we go…

The Cookbook

Step 1: Add your js to your Model’s Admin definition:

class MyBoffoModelAdmin (admin.ModelAdmin):
    fieldsets  = (
        ... yada yada yada...
        (None, {'classes': ['edit'], 'fields': ('content',)}),
    )
    class Media:
        js = ['/tiny_mce/tiny_mce.js', '/js/textareas.js']

Note:

  • The classes : [‘edit’] which tells the code below to set the class for the mcEditor
  • That after the standard include of tiny_mce.js, the second javascript reference in the js list, is your custom init code that you will be writing next.
  • The nested “Class Media” tells the Django Admin interface to include the references to these .js files in the header of the Admin page.

Step 2: Write your initializer Javascript code:

This is the contents of /js/textarea.js:

function mce_setup()
{ tinymce.DOM.addClass (tinymce.DOM.select('.edit .vLargeTextField'), 'mcEdit');

  tinyMCE.init({
    mode : "textareas",
    theme : "advanced",
    editor_selector : "mcEdit",  // doesn't support selectors, only classes, despite the name
    height: "480",
    width: "90%",
    element_format : "html",
    plugins : "preview,fullscreen",
    theme_advanced_buttons3_add : "preview,fullscreen",
    theme_advanced_toolbar_location : "top",
    theme_advanced_toolbar_align : "left",
    theme_advanced_statusbar_location : "bottom",
    //theme_advanced_resizing : true,
  });
};

Notes:

  • This Javascript is executed in the header – and it does NOT initialize the editor yet, it merely defines a function to do so, which is called when the user clicks on a link, which we’ll see next.
  • The “addClass” call at the top is necessary to work properly with Django – despite the ‘editor_selector’ setting in the tinyMCE.init paraeters, this does NOT accept a css selector, only a class – so we have to manually set up a new, unique class, using the tinymce.DOM.select call at the top.
  • The selector of  “.edit .vLargeTextField” pinpoints the actual textarea under the fieldset with the “edit” css class.

Step 3: Add your HTML to the model:

We turn it on using the Django Model Fields’ help_text option, thusly:

content = models.TextField (blank=True, help_text='''HTML Content -
    <a href="javascript:mce_setup();">Click Here</a> to edit - see
    <a href="http://wiki.moxiecode.com/index.php/TinyMCE:Configuration">TinyMCE Configuration</a>
    for more options.''')

That’s it!

When you restart and load the page, you should see

“HTML Content – Click Here to edit – see TinyMCE Configuration for more options.”

at the bottom of the textarea in question that you set the ‘edit’ css class on –  and note that the other javascript isn’t loaded until you actually click on it, speeding load time of the page.

Clicking should quickly load the TinyMCE editor and buttons, resize the text area appropriately, render any HTML with WYSIWIG, and follow page resizes.

The Gotchas

  1. Django doesn’t let you get at the actual textarea class, so you have to do the above selector
  2. TinyMCE’s editor_selector parameter doesn’t use, or work with, selectors (!)
  3. You could use the Django form id, but then this whle precedure wouldn’t be generic, you’d need one init js per field.
  4. You would also need to set up the tinyMCE.init parameters to use ids rather than classes, too.
  5. Setting  “theme_advanced_resizing : true” actually takes away functionality if you have setup up height and width as percentages – which accomplish the same thing with no extra js.
  6. If you’re getting gibberish like “<br mce_bogus />” added to your empty text areas, there are a few things you can do – write us for details – you may need to set up an
    editor_deselector : "mcNoEdit"
  7. and use the appropriate code to add the class at the top of the setup function:
    tinymce.DOM.addClass (tinymce.DOM.select('.vLargeTextField'), 'mcNoEdit');

Useful References

Django Admin Media – Using extra js & css with the Django Admin interface

TinyMCE API – Core API, DOM API including how to find elemnts by selector, and add a class

TinyMCE Examples – Examples with source code including click-to-load, dual/partial textareas, plugin activation, fullscreen, etc

Django Model Documentation – including the help_text option which allows HTML!

Honorable Mention

An Honorable Mention goes to the WYMeditor – an up-and-coming WYSIWYM editor – What You See Is What You Mean – and it’s been getting rave reviews.

It uses a class-based approach, which is intriguing and feel right – it just doesn’t have the polish and full feature set that TinyMCE does right now – but we’ll be exploring this further in a future post, as we’ve already implemented it for a client in Django Admin already :-), and it works well –

j

Ubuntu 8.10 Intrepid Ibex now available

Friday, October 31st, 2008

An Intrepid IbexUbuntu 8.10, Intrepid Ibex, just released, is now our recommended OS platform.

It’s available from the OS dropdown when you configure your vMachine instance while adding to cart.

As always, any additional notes or custom configuration requests should be placed in the “Notes” field when you place your order, as well.

We are also working new Rails instances, with lots of new plugins (ActiveMerchant) available preinstalled, as well as vMachines for both Django 1.01 as well as 1.1 instances.

We currently have Adempiere 3.52+ available, as well, running on Postgres 8.3 – we are preparing the list of installed packages for a future blog post!

j

Review of Django Database Migration Tools

Monday, September 1st, 2008

Update 12/1/08 –

South Logo - Django MigrationsSee comments below, and look for a new blog post from us on a new player which we’ve recently discovered – south:

http://south.aeracode.org/

They even have their own review of the other players, here:

http://south.aeracode.org/wiki/Alternatives

We will post a review on this soon.

Preamble

Following is a review I did recently for one of our Django clients, of six or so of the various tools available to handle database migrations – much like the “Migrations” facilities built in to Ruby on Rails.This list is by no means complete; as there are a lot of players our there – too many – so many, in fact, that no clear winner has emerged.  Read on.

The Reviews

The issue is how to handle schema migration and schema version control in a way that integrates well with the usual Django development workflow.

Here is an excellent Django-centric view on the topic, with proposed solutions and some of the projects currently available:

http://code.djangoproject.com/wiki/SchemaEvolution

I have checked all the references in the article, and some further ones I have found –
here are the candidates for use, and my evaluations:

Django Evolutions

http://code.google.com/p/django-evolution/

  • Mature, active, likely candidate for future Django inclusion
  • Postgres support the strongest, MySQL weakest
  • Establishes a baseline, rather than introspects – stable, conservative approach
  • Creates two new tables for the baseline – django_project_version, django_evolution
  • Does not help for our current situation
  • Builds on RoR / ActiveRecord? ideas, takes one step further

Django Schema Evolution

http://code.google.com/p/django-schemaevolution/

  • Based on the above article/link & observations
  • actually does introspections, too
  • MySQL support the strongest
  • Would work well for us, except it faults on current Django SVN release we are using (I filed the issue on Google code for the project).

deseb – Django External Schema Evolution Branch

http://code.google.com/p/deseb/

  • Appears to be a current project, with a very active community
  • this appears to be a fork of the schema_evolution project, and is also based on the article/link above
  • it uses a different approach, doing signatures of the SQL, and
  • it does a virtual ‘diff’ on the Model vs the schema –
  • almost like a db ‘lint’ utility – I will post the output below or next post
  • can optionally generate schema migration scripts to be used in version control and managed deployment scenarios
  • at the very least, this is a very useful utility to compare existing Models/schema with the manage.py sqlevolve command (see output below)

BEGIN;
ALTER TABLE `blog_categories` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `blog_posts` MODIFY COLUMN `id` integer AUTO_INCREMENT;

ALTER TABLE `tagging_tag` MODIFY COLUMN `id` integer AUTO_INCREMENT;
[lots of similar auto-increment mods clipped for brevity]
ALTER TABLE `django_redirect` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `django_session` MODIFY COLUMN `session_key` varchar(40);
ALTER TABLE `django_site` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `robots_url` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `robots_rule` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `wtp_user_profile` MODIFY COLUMN `user_id` integer;
— warning: the following may cause data loss
ALTER TABLE `wtp_user_profile` DROP COLUMN `is_subscribed`;
— end warning
ALTER TABLE `wtp_user_review` MODIFY COLUMN `id` integer AUTO_INCREMENT;
[lots of similar auto-increment mods clipped for brevity]
ALTER TABLE `wtp_product` MODIFY COLUMN `id` integer AUTO_INCREMENT;
UPDATE `wtp_product` SET `is_new_image_url` = ‘t’ WHERE `is_new_image_url` IS NULL;
ALTER TABLE `wtp_product` MODIFY COLUMN `is_new_image_url` bool NOT NULL;
ALTER TABLE `wtp_genre` MODIFY COLUMN `id` integer AUTO_INCREMENT;
[lots of similar auto-increment mods clipped for brevity]
ALTER TABLE `wtp_editorial_review` MODIFY COLUMN `product_id` integer;
UPDATE `wtp_editorial_review` SET `is_published` = ‘f’ WHERE `is_published` IS NULL;
ALTER TABLE `wtp_editorial_review` MODIFY COLUMN `is_published` bool NOT NULL;
ALTER TABLE `wtp_featured_article` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `wtp_user_review_feature` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `wtp_user_review_feature_rate` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `wtp_screenshot_meta` MODIFY COLUMN `product_id` integer;
ALTER TABLE `wtp_screenshot_image` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `wtp_product_video` MODIFY COLUMN `product_id` integer;
[lots of similar auto-increment mods clipped for brevity]
COMMIT;

yadsel – Yet Another Database Schema Evolution Library

(Formerly dbMigrations)

http://code.google.com/p/yadsel/

Reasonably active project, last updated April 2008, some / sparse community participation –

  • Bills itself as an “Active Record Migrations like project”
  • Full and wide db support, and Django support
  • Full schema inspection, ddl/uml support, etc
  • Overkill for what we need
  • Lots of docs, but no ‘Getting Started’ guide, as is customary, unlike (All1) the other candidates
  • Not installed and evaluated

dupdater.py — Django project evolution utility

http://www.methods.co.nz/django/dupdater.html

Basically a version management & deployment tool, to give you the very basics of the RoR ActiveRecord? functionality – versioned back-and-forth scripts.

  • Simple python utility script, no Django installation required
  • Does one thing, and does it well – no introspection, etc
  • Active, last updated Apr 08
  • Immune to the Django 1.0 migration problems
  • We should evaluate this further, it looks good

Great for:

  • Keeping track of your SQL db alterations
  • Keeping them under version control
  • Allowing them to move forward and backward
  • Managing deployment in various environments – Production, Staging, Development, Sandbox.

This is simple and elegant, we may want to use this along with deseb for ‘db lint’ and to help generate the updates.

dbmigration — Simple schema migration for Django

http://www.aswmc.com/dbmigration/

Currently at v0.4, and about a a year old – does not appear to have a lot of traction, although it’s widely quoted and linked to.

  • Also patterns itself after the back-and-forth AR-style scripts
  • Uses a ‘migrations’ directory per app (rather than per project, like AR / RoR)
  • Decries auto-update integrated migration tools like Django-evolution and Django-schemaevolution
  • Supports migrations written in SQL or Python.
  • Not installed or evaluated

Recommendations and Conclusions

  • Use deseb for its ‘DB Lint’ functionality (at the very least, on dev)
  • (Possibly de-fang its update capabilities)
  • Evaluate and likely use dupdater for deployment & SQL version management
  • Install/Leave django-migrations installed, to see how it tracks the baseline
  • Keep a close eye on django-migrations moving forward, to see if we can start using it, and how it tracks the baseline

j


UPDATE 09/02/08 10:03:37 PDT dupdater findings: ¶

  • dupdater is at version 0.6, and feels at least this rough-around-the-edges
  • After using it on sandbox for a while, I can’t recommend it at this time.

However, the workflow that this tries to mimic/achieve, ie, a directory of changes, numbered, which are applied in order, is a good one – We can just do this manually with our /sql/ subdirs.

There is even some support for auto-application of sqls in the app /sql/ subdirs, by the manage.py interface, if we ever choose to use it.

Updated Recommendations and Conclusions ¶

  • Use deseb for its ‘DB Lint’ functionality (at the very least, on dev & sandbox)
  • (Possibly de-fang its update capabilities)
  • Use a /sql/ directory of numbered .sql files for the db updates
  • Install/Leave django-migrations installed (at least on sandbox)
  • Keep a close eye on django-migrations moving forward, to evaluate when to start using it and how it tracks the baseline

j


UPDATE 09/07/08 12:14:24 PDT

FYI, as of 9/7/08, deseb works fine for us in our current environment, but has not yet been updated to Django 1.0.  You will have to remove it if you are migrating to Django 1.0+.

j

Now on Django 1.0b and Satchmo 0.8pre

Monday, August 25th, 2008

django-logo-positiveOK, after some serious work and refactoring, we are now up and running on Django 1.0b and Satchmo 0.8pre, as of today –

The new shop and Django features are quite impressive, and include many things we used to have to do ourselves.

You will see us gradually putting our Satchmo eCommerce ‘shop’ back together over the next few weeks to be back up to full functionality.

As always, you may reach us for sales and support via email.

j

Satchmo Instance Now Available!

Sunday, May 25th, 2008

Go Satchmo!

Libre Hosters,

In addition to our usual Django vMachine instances, We now have a vMachine of Django’s Satchmo eCommerce engine available –

In keeping with our commitment to provide the latest ready-to-roll Django hosting, we now offer this  vm with Satchmo preconfigured.

This therefore includes:

Just indicate your preferred Database and any other packages you’d like installed in the “Custom Notes” field when you place your order.

Note that we run our shop on Satchmo and Django (and the Blog on WordPress).

j