Along with Django 1.2.1, Satchmo 0.9.1 was released yesterday as well:

http://www.satchmoproject.com/blog/2010/may/24/satchmo-0-9-1-release/

Just put it in the “Notes” field when you place your order, and we’ll install it for you, along w8ith whatever other custom Django plugins you need.

j

Django 1.2.1 is now available for ordering here at Libre Hosting.

http://www.djangoproject.com/weblog/2010/may/24/121/

Simply select “Django 1.2.1″ from the dropdowns when you place your order -

Your VM will be set up to sync to trunk, to allow you to keep up-to-date – easiest way to keep up on point releases and bugfixes.

As always, Satchmo, and any other Django plugins you prefer, are available on request – just put your preferences in the “Notes” field when you place your order.

j

The upcoming Django 1.2 Beta is now available for ordering here at Libre Hosting.

http://www.djangoproject.com/weblog/2010/feb/06/12-beta-1/

Simply ask for “Django12″ in the “Notes” field when you place your order -

Your VM will be set up to sync to trunk, to allow you to keep up-to-date – all the way through to the release of 1.2 and beyond!

As always, the actual 1.2 release itself will be put into our usual dropdown menus when the final release occurs. In the meantime, just use the “Notes” field.

j

Development Version

We are proud to announce that we now support and can install the latest trunk-version (0.9) of Satchmo, installed from Mercurial (aka “hg” - get it?!).

Since it’s installed directly from the VCS, and symlinked into the python path, this allows for updates to the source tree anytime – in other words, instant upgrades (and downgrade, if a problem is encountered!) anytime (depending on your VCS).

Django, and other plugins, are installed this same way, as always – we have done it this way since 2007.

Here is a quick intro on how it’s done – just indicate you want us to install Satchmo in the “notes” field when you place your order, and we’ll get it done for you.

j

Apache Redux

In keeping with the new, recommended Django deployment method of mod_wsgi with Apache , we have migrated our internal processes as well as deployed multiple  new systems this way – and from this point forward, this is how Django (current, 1.1+) will be deployed by default.

We also still fully support the mod_python deployment method, and will be happy to work with you to set up your custom environment, whatever it may be.

Please note that nginx, Lighttpd, and of course Apache with mod_python are also all still available on request.

Just put your request in the “Notes” field when you place your order and we’ll get it done for you.

j

Libre hosters,

We are proud to announce that the Django-based social-network-enabling Pinax project, is now one of our standard instances, and can be hosted here at Libre hosting, with the usual full root access.

Pinax version (as of this writing), is v0.7.0dev, and is installed with svn to be updatable with svn up, as always (and as our Django instances are, by default). Other versions available on request.

All plugins are preinstalled, and enabled, along with the usual list of example Pinax projects:

drwxr-xr-x  7 root root 4096 2009-03-29 05:18 basic_project
drwxr-xr-x 10 root root 4096 2009-03-30 15:38 complete_project
drwxr-xr-x  7 root root 4096 2009-03-29 05:18 intranet_project
drwxr-xr-x  7 root root 4096 2009-03-29 05:18 private_beta_project
drwxr-xr-x  7 root root 4096 2009-03-29 05:18 temp_content_project
drwxr-xr-x  7 root root 4096 2009-03-29 05:18 temp_group_project
drwxr-xr-x  8 root root 4096 2009-03-29 05:18 temp_schedule_project

Apache with mod_python is the default webserver installed, but we will be happy to install Lighttpd on request (or nginx by prearrangement – contact us for details) with mod_wsgi instead.

Our default Pinax installation includes Django svn trunk (~1.1 as of this writing) with all plugins preinstalled by the Pinax installation scripts. We do not install into a Python virtualenv, because this is intended to be a dedicated Pinax / Django installation.  We can make changes accordingly as desired, upon your request.

Pinax really turbocharges the Django framework, and includes (at least) these pluggables:

• django-email-confirmation
• django-timezones
• django-threadedcomments
• django-ajax-validation
• django-flags
• django-pagination
• django-oembed
• django-notification
• django-mailer
• django-dbtemplates
• django-robots
• django-announcements

Here are a few example Pinax sites to show a portion of what it can do:

• foodsel
• Trailmapping
• tuttivisti

Let us know what you think,
j

We are pleased to announce that we now have three Django versions available for hosting in any of our plans -

• Django 1.1 trunk – the prerelease, currently targeted for March 2009.
• Django 1.02 – the current “stable” release
• Django 0.96.3 – the legacy “Pre-1.0″ release, which is still supported

Notes:

1. Although 1.1 is not yet officially released, trunk is always pretty stable – as projects go, the Django team can be relied upon to keep the trunk tree extremely reliable – we run trunk in production, for example.  For new projects, we recommend this option.
2. Legacy 0.96.3 is the last release before the 1.0 release which broke backward compatibility – it includes the older admin interface (with nested Admin classes), and the older Signals implementation – which provide a migration hurdle for many production environments – we have several customers and friends still running 0.96.3 until they address these migration issues.  We can also help with this, if you need us.
3. The official released version, 1.02, is stable, and well-tested.  We recommend this option for those conservative production environments that have full-blown separated test/staging and developent envoironments as well.

As always, if you need a specific legacy version (or a specific trunk svn release for that matter, or release-by-date) we will be happy to install it from svn on request, just plce your request in the “notes” field when you place your order.

We will also happily install any Django packages you desire, as well, on request – try the lists at Django Pluggables and Django Search. Google Code also has a good number of Django-related projects hosted there.

And remember, if you need design, development, or site setup assistance, we are always here to help.

j

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, 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

Update 12/1/08 -

See 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