Fixed relative imports on Python 3.

cms/plugins/file/cms_plugins.py

@@ -1,25 +1,25 @@
 from cms.plugin_pool import plugin_pool
 from cms.plugin_base import CMSPluginBase
 from django.utils.translation import ugettext_lazy as _
-from models import File
+from .models import File
 from django.conf import settings
 
 class FilePlugin(CMSPluginBase):
     model = File
     name = _("File")
     render_template = "cms/plugins/file.html"
     text_enabled = True
-    
-    def render(self, context, instance, placeholder):  
+
+    def render(self, context, instance, placeholder):
         context.update({
-            'object':instance, 
+            'object':instance,
             'placeholder':placeholder
-        })    
+        })
         return context
 
     def icon_src(self, instance):
         file_icon = instance.get_icon_url()
         if file_icon: return file_icon
         return settings.STATIC_URL + u"cms/img/icons/plugins/file.png"
-    
+
 plugin_pool.register_plugin(FilePlugin)

cms/plugins/flash/cms_plugins.py

@@ -1,20 +1,20 @@
 from cms.plugin_pool import plugin_pool
 from cms.plugin_base import CMSPluginBase
 from django.utils.translation import ugettext_lazy as _
-from models import Flash
+from .models import Flash
 from cms.plugins.flash.forms import FlashForm
 
 class FlashPlugin(CMSPluginBase):
     model = Flash
     name = _("Flash")
     form = FlashForm
-    
+
     render_template = "cms/plugins/flash.html"
     def render(self, context, instance, placeholder):
         context.update({
             'object': instance,
             'placeholder':placeholder,
         })
         return context
-    
-plugin_pool.register_plugin(FlashPlugin)
+
+plugin_pool.register_plugin(FlashPlugin)

docs/extending_cms/custom_plugins.rst

@@ -2,43 +2,43 @@
 Custom Plugins
 ##############
 
-CMS Plugins are reusable content publishers that can be inserted into django 
+CMS Plugins are reusable content publishers that can be inserted into django
 CMS pages (or indeed into any content that uses django CMS placeholders). They
 enable the publishing of information automatically, without further intervention.
 
-This means that your published web content, whatever it is, is kept 
+This means that your published web content, whatever it is, is kept
 up-to-date at all times.
 
 It's like magic, but quicker.
 
-Unless you're lucky enough to discover that your needs can be met by the 
-built-in plugins, or by the many available 3rd-party plugins, you'll have 
+Unless you're lucky enough to discover that your needs can be met by the
+built-in plugins, or by the many available 3rd-party plugins, you'll have
 to write your own custom CMS Plugin. Don't worry though -
 writing a CMS Plugin is rather simple.
 
 *************************************
 Why would you need to write a plugin?
 *************************************
 
-A plugin is the most convenient way to integrate content from another Django 
+A plugin is the most convenient way to integrate content from another Django
 app into a django CMS page.
 
-For example, suppose you're developing a site for a record company in django 
+For example, suppose you're developing a site for a record company in django
 CMS. You might like to have a "Latest releases" box on your site's home page.
 
-Of course, you could every so often edit that page and update the information. 
-However, a sensible record company will manage its catalogue in Django too, 
+Of course, you could every so often edit that page and update the information.
+However, a sensible record company will manage its catalogue in Django too,
 which means Django already knows what this week's new releases are.
 
-This is an excellent opportunity to make use of that information to make your 
-life easier - all you need to do is create a django CMS plugin that you can 
-insert into your home page, and leave it to do the work of publishing information 
+This is an excellent opportunity to make use of that information to make your
+life easier - all you need to do is create a django CMS plugin that you can
+insert into your home page, and leave it to do the work of publishing information
 about the latest releases for you.
 
-Plugins are **reusable**. Perhaps your record company is producing a series of 
-reissues of seminal Swiss punk records; on your site's page about the series, 
-you could insert the same plugin, configured a little differently, that will 
-publish information about recent new releases in that series. 
+Plugins are **reusable**. Perhaps your record company is producing a series of
+reissues of seminal Swiss punk records; on your site's page about the series,
+you could insert the same plugin, configured a little differently, that will
+publish information about recent new releases in that series.
 
 ********
 Overview
@@ -56,7 +56,7 @@ These correspond to the familiar Model-View-Template scheme:
 * the plugin **view** that works out what needs to be displayed
 * the plugin **template** to render the information
 
-And so to build your plugin, you'll make it from: 
+And so to build your plugin, you'll make it from:
 
 * a subclass of :class:`cms.models.pluginmodel.CMSPlugin` to
   **store the configuration** for your plugin instances
@@ -78,11 +78,11 @@ The plugin **model**, the subclass of :class:`cms.models.pluginmodel.CMSPlugin`,
 is actually optional.
 
 You could have a plugin that doesn't need to be configured, because it only
-ever does one thing. 
+ever does one thing.
 
-For example, you could have a plugin that only publishes information 
-about the top-selling record of the past seven days. Obviously, this wouldn't 
-be very flexible - you wouldn't be able to use the same plugin for the 
+For example, you could have a plugin that only publishes information
+about the top-selling record of the past seven days. Obviously, this wouldn't
+be very flexible - you wouldn't be able to use the same plugin for the
 best-selling release of the last *month* instead.
 
 Usually, you find that it is useful to be able to configure your plugin, and this
@@ -132,7 +132,7 @@ There are three required attributes on those classes:
   If you do not require any special information, for example configuration, to
   be stored for your plugins, you can simply use
   :class:`cms.models.pluginmodel.CMSPlugin` (we'll look at that model more
-  closely in a bit). In a normal admin class, you don't need to supply this 
+  closely in a bit). In a normal admin class, you don't need to supply this
   information because ``admin.site.register(Model, Admin)`` takes care of it,
   but a plugin is not registered in that way.
 * ``name``: The name of your plugin as displayed in the admin. It is generally
@@ -142,14 +142,14 @@ There are three required attributes on those classes:
 * ``render_template``: The template to render this plugin with.
 
 In addition to those three attributes, you can also define a
-:meth:`render` method on your subclasses. It is specifically this `render` 
+:meth:`render` method on your subclasses. It is specifically this `render`
 method that is the **view** for your plugin.
 
 The `render` method takes three arguments:
 
 * ``context``: The context with which the page is rendered.
 * ``instance``: The instance of your plugin that is rendered.
-* ``placeholder``: The name of the placeholder that is rendered. 
+* ``placeholder``: The name of the placeholder that is rendered.
 
 This method must return a dictionary or an instance of
 :class:`django.template.Context`, which will be used as context to render the
@@ -204,7 +204,7 @@ In our ``models.py`` we add the following::
         guest_name = models.CharField(max_length=50, default='Guest')
 
 
-If you followed the Django tutorial, this shouldn't look too new to you. The 
+If you followed the Django tutorial, this shouldn't look too new to you. The
 only difference to normal models is that you subclass
 :class:`cms.models.pluginmodel.CMSPlugin` rather than
 :class:`django.db.models.base.Model`.
@@ -215,8 +215,8 @@ Now we need to change our plugin definition to use this model, so our new
     from cms.plugin_base import CMSPluginBase
     from cms.plugin_pool import plugin_pool
     from django.utils.translation import ugettext_lazy as _
-    
-    from models import Hello
+
+    from .models import Hello
 
     class HelloPlugin(CMSPluginBase):
         model = Hello
@@ -250,7 +250,7 @@ else clause.
     please use abstract base models.
 
 .. warning::
-    
+
     You cannot name your model fields the same as any installed plugins
     lower-cased model name, due to the implicit one-to-one relation Django uses
     for subclassed models. If you use all core plugins, this includes:
@@ -301,14 +301,14 @@ two models, one for the plugin and one for those items::
 
     class AssociatedItem(models.Model):
         plugin = models.ForeignKey(
-            ArticlePluginModel, 
+            ArticlePluginModel,
             related_name="associated_item"
             )
 
 You'll then need the ``copy_relations()`` method on your plugin model to loop
 over the associated items and copy them, giving the copies foreign keys to the
 new plugin::
-      
+
     class ArticlePluginModel(CMSPlugin):
         title = models.CharField(max_length=50)
 
@@ -393,7 +393,7 @@ Handling media
 If your plugin depends on certain media files, javascript or stylesheets, you
 can include them from your plugin template using `django-sekizai`_. Your CMS
 templates are always enforced to have the ``css`` and ``js`` sekizai namespaces,
-therefore those should be used to include the respective files. For more 
+therefore those should be used to include the respective files. For more
 information about django-sekizai, please refer to the
 `django-sekizai documentation`_.
 
@@ -419,7 +419,7 @@ A **good** example:
 .. code-block:: html+django
 
     {% load sekizai_tags %}
-    
+
     {% addtoblock "js" %}<script type="text/javascript" src="{{ MEDIA_URL }}myplugin/js/myjsfile.js"></script>{% endaddtoblock %}
     {% addtoblock "js" %}<script type="text/javascript" src="{{ MEDIA_URL }}myplugin/js/myotherfile.js"></script>{% endaddtoblock %}
     {% addtoblock "css" %}<link rel="stylesheet" type="text/css" href="{{ MEDIA_URL }}myplugin/css/astylesheet.css"></script>{% endaddtoblock %}
@@ -436,7 +436,7 @@ A **bad** example:
 .. code-block:: html+django
 
     {% load sekizai_tags %}
-    
+
     {% addtoblock "js" %}<script type="text/javascript" src="{{ MEDIA_URL }}myplugin/js/myjsfile.js"></script>
     <script type="text/javascript" src="{{ MEDIA_URL }}myplugin/js/myotherfile.js"></script>{% endaddtoblock %}
     {% addtoblock "css" %}
@@ -555,18 +555,18 @@ change_form_template
 
 The template used to render the form when you edit the plugin.
 
-Default: 
+Default:
 
 `admin/cms/page/plugin_change_form.html`
 
 Example::
 
-	class MyPlugin(CMSPluginBase):
-	    model = MyModel
-	    name = _("My Plugin")
-	    render_template = "cms/plugins/my_plugin.html"
-		change_form_template = "admin/cms/page/plugin_change_form.html"
-	
+    class MyPlugin(CMSPluginBase):
+        model = MyModel
+        name = _("My Plugin")
+        render_template = "cms/plugins/my_plugin.html"
+        change_form_template = "admin/cms/page/plugin_change_form.html"
+
 frontend_edit_template
 ----------------------
 
@@ -575,7 +575,7 @@ The template used for wrapping the plugin in frontend editing.
 Default:
 
 `cms/toolbar/placeholder_wrapper.html`
-	
+
 
 admin_preview
 -------------
@@ -643,7 +643,7 @@ child_classes
 Default: None
 A List of Plugin Class Names. If this is set, only plugins listed here can be added to this plugin.
 
-    
+
 parent_classes
 --------------