Publify

Making blogging easy

Creating advanced Typo plugins

2 days ago, there was a guy called Fish who joined us while I was idling on #typo. He was asking for a gallery plugin for his Typo blog. As I’m a photographer, having such a plugin had been on my TODO list for like years now, so I told him I would do a quick proof of concept during my daily train commute. A few hours later, when I went back home, the plugin was working. It was very simple, displaying files uploaded on a Typo blog with thumbnail, pagination, medium size and large size displayed in a lightbox. Indeed, it wasn’t enough, and Fish came back asking for multiple albums and picture selection, caption, so I came back to work. As a developper, Fish could probably have done it himself, but I’m more familiar with Typo internals, and even I didn’t know how far I could go with Typo plugin integration.

Tonight, during my daily commute, I extended my gallery plugin with full admin and frontend integration. The gallery is not working yet, but the biggest part is working: integrating a complexe plugin in a Typo blog. I wanted to share this with you as a HOWTO.

Before trying this, please be sure you’re using Typo HEAD as Friday April the 8th, or a Typo version above 6.0.4 (even though it’s not released yet) as you’ll need the route.rb modification I had to do.

Creating the plugin

As Typo plugins are just plain Rails plugins, creation is kinda trivial.

<typo:code> ./script/rails generate plugin typosampleplugin </typo:code>

You’re now going to create some folders to reflect a Rails application tree:

<typo:code> cd vendor/plugins/typosampleplugin mkdir -p app/controllers/admin app/models app/helpers/admin config app/views/admin </typo:code>

Good, you’re now ready to code the main stuff. Edit your new plugin, and let’s go!

Making your code accessible

Now, you’re going to make Typo access your code. Edit your init.rb file and add the following:

<typo:code lang=’ruby’> PLUGINNAME = ‘typosampleplugin’ PLUGINPATH = “#{::Rails.root.tos}/vendor/plugins/#{PLUGINNAME}” PLUGINCONTROLLERPATH = “#{PLUGINPATH}/app/controllers” PLUGINVIEWSPATH = “#{PLUGINPATH}/app/views” PLUGINHELPERPATH = “#{PLUGINPATH}/app/helpers” PLUGINMODELSPATH = “#{PLUGINPATH}/app/models”

config.autoloadpaths += %W(#{TypoSamplePlugin::PLUGINCONTROLLER_PATH} \

                        #{TypoSamplePlugin::PLUGIN_HELPER_PATH}      \
                        #{TypoSamplePlugin::PLUGIN_VIEWS_PATH}       \
                        #{TypoSamplePlugin::PLUGIN_MODELS_PATH}

ActionView::Base.send(:include, TypoSamplePlugin::Helper) </typo:code>

The routing

Unless Rails generators, your plugin won’t be allowed to change routes.rb. We want our end users to remove them if they don’t want them anymore. So we’re going to create our own config/routes.rb. It’s going to look like this:

<typo:code lang=’ruby’> ActionController::Routing::Routes.draw do |map| map.connect ‘sampleplugin/:action’, :controller => ‘typosample’, :action => ‘index’

%w{ sample_plugin }.each do |i|

map.connect "/admin/#{i}", :controller => "admin/#{i}", :action => 'index'
map.connect "/admin/#{i}/:action/:id", :controller => "admin/#{i}", :action => nil, :id => nil

end end </typo:code>

I know, we’re still using Rails 2 routing DSL. It’s bad but Rails 3 can’t handle everything we do.

The first block is for your frontend controllers, the second one for the admin. Easy as pie isn’t it?

The models

She’s a model and she’s looking good. I’d like to take her home that’s understood.

Add your models files in app/models exactly like on any Rails application. You can use any Active Record relations you want and access or extend existing Typo models.

To create your database schema, edit your init.rb file, and add the following code:

<typo:code lang=’ruby’> unless ::TypoSamplePlugin.tableexists? ActiveRecord::Schema.createtable(TypoSamplePlugin.table_name) do |t|

t.column :name,  :string
t.column :description,  :text

end end </typo:code>

Couldn’t be easy heh? Now let’s switch to the front and back office thing.

The front thing

Controllers

To be able to display your content within your Typo blog layout, every front end controller will need the following code:

<typo:code lang=’ruby’> class TypoSamplePluginController < ActionController::Base unloadable layout :themelayout beforefilter :template_root

def template_root

self.class.view_paths = ::ActionController::Base.view_paths.dup.unshift(TypoSamplePlugin::PLUGIN_VIEWS_PATH)

end

def theme_layout

File.join("#{::Rails.root.to_s}/themes/#{Blog.default.theme}/views", Blog.default.current_theme.layout(self.action_name))

end

end </typo:code>

There’s certainly a cleaner way to do it by not repeating the code, but I’ll dig it later.

Views

Nothing special here. Really.

The backend thing

OK, now you want to give your plugin a fancy back office? Let’s go.

Adding your module to the admin

Edit your init.rb. In your model creation block, add the following:

<typo:code lang=’ruby’> admin = Profile.findbylabel(‘admin’) admin.modules << :typosampleplugin admin.save

publisher = Profile.findbylabel(‘publisher’) publisher.modules << :typosampleplugin publisher.save
</typo:code>

This will update both admin and publisher profiles giving them the rights to access your plugin admin.

Now, let’s add them to the access control list (and the menu as well). This is still in init.rb

<typo:code lang=’ruby’> AccessControl.map :require => [ :admin, :publisher, :contributor ] do |map| map.project_module :typosampleplugin, nil do |project|

project.menu    "My plugin meny",  { :controller => "admin/typo_sample_plugin" }
project.submenu "My submenu", {:controller => "admin/typo_sample_plugin_other" }

end end </typo:code>

Edit your lib/typosampleplugin.rb and add the following:

<typo:code lang=’ruby’> module Helper def classtyposampleplugin return classselectedtab if controller.controllername =~ /typosampleplugin/ class_tab
end end </typo:code>

This will allow you to manage the tabs highligh in the admin.

Controllers

Your controllers will go to app/controllers/admin and will all look like this, pretty like normal admin controller:

<typo:code lang=’ruby’> module Admin; end

class Admin::TypoSamplePluginController < Admin::BaseController layout ‘administration’ unloadable

...

end </typo:code>

Views

Typo plugins admin views look like normal admin views. Minimum code is:

<typo:code lang=’ruby’> <% @pageheading = (‘Sample plugin’) %> <% subtabs_for(:typosampleplugin) %> </typo:code>

You can access any admin helper like saveorcancel or linktonew.

Here we are (born to be kings). I’ll release Typo Gallery when I finish it, which could happen very soon as I’m thinking about quiting Flickr to host my photos somewhere like I used to do with Wordpress + Gallery2 in the past, many, many cycles ago.

Published on 08/04/2011 at 17h08 by Frédéric de Villamil, tags , , , ,

Admin plugins integration

Commit 281e6dc6941c0987b75a8777df30b84928f44d6d (as well as 132697c2184a4a89fd3ca16d327bbe47a9644d09) introduced the possibility to dynamically load access to plugins admin section into Typo administration. Links to plugins admin zone are displayed into the admin/themes zone. This is – for now – fairly limited, but we’re working on extending it.

This is important to us since Typo has always been missing a nice plugin API. This is a first step towards something bigger, even thoug we don’t know how big it’s going to be yet.

I’ve released a quick proof of concept using a contact form plugin. It’s really simple, lacks lots of functionnalities one could expect from such a plugin but… it’s a POC and I’ll update it later. To test it, you need to be following our development branch, and update to the latest commit.

Typo plugins admin interface

First, install Typo Contact Form plugin on your Typo instance:

<typo:code lang=’sh’> ./script/plugins install http://github.com/fdv/typoplugincontact_form.git </typo:code>

Then restart your Typo application.

You can now access the contact form using: http://your blog url/contactform Administration: http://your blog url]/admin/contactform

How can I integrate my plugins into Typo administration?

It’s fairly easy.

Typo plugins are just plain Rails plugins.

To have their admin detected, they need to be called typopluginsomename. They should just include a lib/app/controllers/admin/somename_controller.rb

I recommend you to start with Typo Contact Form code, to make your own plugins Typo compliant.

More to come very soon!

Published on 20/04/2010 at 23h43 by Frédéric de Villamil, tags , , ,

Typo plugins: what's next?

If you’re following the trunk, you may have noticed that many plugins have moved from the core to svn:externals. Source have been relocated into the new Typo official plugins repository. As I said a few weeks ago in The futur of Typo sidebar plugins, we’re only going to keep a few plugins in the core. The complete list is:

  • Archives.
  • Amazon.
  • Categories.
  • Static.
  • Tags.
  • XML Syndication.

And now, what’s next? As we now have our official plugins repository, I’ve been thinking about giving Typo a plugin manager. The manager will get a XML file with the official plugins list. Users will install plugins in 1 click.

How will it work? Very simply. The plugin manager will just run script/plugin install myplugin, and here you are.

Published on 17/05/2007 at 20h06 by Frédéric de Villamil, tags , , , ,

The future of Typo sidebar plugins

A French translation is avaliable on my personal blog

Between 4.0 and 4.1, there were lots of changes in Typo sidebar plugins architecture. Plugins have been rewriten to become basic rails plugins one can install with script/plugin install {#PLUGIN_SOURCE_URI}. This is aimed at removing some sidebr plugins from the trunk and create an official Typo plugin repository.

Why should we do this? After all, the more functionality you have in a program, the better it is, isn’t it ?

Well, this is not always true. Here are the 4 main reasons :

  • Typo is somewhat heavy for what it does, and too many plugins is part of the issue.
  • People need to wait for a Typo release every time a service changes its API. This won’t happen anymore. We just fix the plugin and users can update.
  • I don’t think users use both Delicious AND Magnolia. And I wonder how much people really use the xbox card stuff. If code is not used, it doesn’t need to be there.
  • We want to give plugin authors some visibility. The repository and plugin directory will help this.

Here is the plugin list we’re going to keep in the trunk :

  • Archives. This one will be activated in the default install.
  • Amazon. It may seem odd to keep it, but it’s the best example we have of interaction between a Typo text filter and a sidebar plugin.
  • Categories. Activated in the default install.
  • Recent comments
  • Static. A Typo developers blogroll will keep being activated by default.
  • Tags.
  • XML syndication. Activated in the default install.

We’re starting moving the less used plugins tonight, with Audioscrobbler and Xbox Live. The whole change will be done step by step before the next release.

We know that it may break blogs using the trunk, just like this one or my own blog, and some people will complain. Please, before doing so, remember that running off the trunk is always at your own risk.

Published on 15/04/2007 at 19h51 by Frédéric de Villamil, tags , , , , , ,

Powered by Publify – Thème Frédéric de Villamil | Photo Glenn