What's New in Radiant 0.6

You may have heard through the grapevine that Radiant 0.6 is to be released this Saturday. If not, here’s your notice!

UPDATE: OK, so we didn’t release yesterday. John and I were up late adding generators for extension models and controllers and trying to fix the fixtures issue. Hopefully we’ll release today (Sunday 4/22).

Since there are a lot of changes since the release of 0.5.2 (250+ commits), I will summarize them for you here. Most of the changes affect developers more than end-users, but there are still some major differences that could slip you up when upgrading or building a new site.

This is pretty long, so be prepared for a big read after the jump.

Changes for End Users and Site Managers

Installation/Upgrade

• script/setup_database is gone. To create a new Radiant site, go to the directory where you created an instance, and run rake production db:bootstrap. This will run the wizard that builds the database for you. Make sure you have edited or created config/database.yml already.
• If you are upgrading from an older version of Radiant, BACKUP YOUR DATABASE and then run rake db:migrate. If you used custom behaviors, try to find and install extension replacements for them before you attempt to upgrade.
• To upgrade an instance with the most current files, run rake radiant:update. This will copy the latest stuff from vendor/radiant or the gem.

Database

• sqlite3 is now better supported; Postgresql and MS SQL Server should work too.

Performance

• Radiant now supports “X-Sendfile” headers on cached pages, which should speed up the page delivery for some web servers in proxy configurations.
• Radiant now supports “304 Not Modified” status codes, which will prevent the client for downloading pages that have not changed from the version in the client-side cache. The client must support this status code, of course.

Radius Tags

• r:children:each, r:children:first, and r:children:last now all accept the same ordering and limit attributes and have the same defaults.
• Snippets are now responsive to global context via the r:page tag. This means that any tags inside r:page will refer to the page currently being rendered, i.e. the page requested, not the local contextual page via tags like r:children:each, etc. This is most relevant to recursive snippets like the sitemapper example.
• r:navigation now uses the pipe character (“|”) to delimit URLs in the urls attribute rather than the semi-colon.
• r:date now accepts a “when” attribute that specifies which attribute of the page to render. Valid values of the attribute are published_at, updated_at, created_at, and now. now renders the current date/time, regardless of which page is being rendered.
• r:cycle is a new tag that creates or continues a global cycle in your page. A cycle basically emits text you define based on the number of times you’ve called it. This is nice for alternating the style of rows in a table, etc.

Admin and Page-editing Interfaces

• Page parts/tabs are now preserved in the order you created them.
• Tag documentation – there’s a popup in the page-editing interface that will show what tags are available for the current page, and some descriptions of how to use them. The popup includes a live-search so you can find a certain tag definition by typing in the box.
• Filter documentation – there’s a popup in the page-editing interface that will show how to format your content for the currently selected filter.
• All items in the administration interface (users, pages, snippets, layouts) have optimistic locking. That is, if someone else saves something while you have it open, you will receive a warning to reload the item you are editing.

Extensions

• Any installed extensions can be en/disabled and de/activated via the administration interface. Click “Extensions” next to “Users” if you’re an administrator.

Changes for Developers

Systemic / Base

• Radiant 0.6 is frozen to, and includes in its distribution, Rails 1.2.3 – you don’t have to have Rails already installed! This has many implications and I suggest you investigate the many articles that detail the differences between Rails 1.2 and 1.1.
• The loading/boot-up process for Rails has been dramatically changed to allow for extensions. Be wary about any changes you might have made to config/environment.rb in the past, or any changes made via plugins. Try to move your changes into extensions instead.
• The Radiant codebase can be run out of the vendor directory as well as from the gem. This means (only in instance mode):
  • To keep up on the latest trunk or branch code, you should checkout into vendor/radiant rather than doing a plain checkout.
  • To freeze to a specific version of Radiant, either checkout the revision you want, or use the rake radiant:freeze command, which comes in two flavors: radiant:freeze:gems and radiant:freeze:edge. radiant:freeze:edge works just like rails:freeze:edge, with support for TAG and REVISION.
  • To return to fluid use of the system gems, run rake radiant:unfreeze.
• To quickly rollback and run all Radiant core migrations, use rake db:remigrate. THIS WILL DESTROY ANY DATA IN YOUR DATABASE! USE WITH CAUTION.
• Radiant::Config (useful in extensions) now supports boolean values. Add a question mark to the end of the key (e.g. Radiant::Config["boolean?"]) if it should return boolean values (true/false).

Performance

• Caching no longer stores the headers and body in the same file. This allows Radiant to support X-SendFile headers.
• Cache files are stored in the /cache directory in your instance, not tmp/cache. (not sure if this was changed or the same, but good to know nonetheless).
• Pages can set a specific cache timeout via response.cache_timeout. This should probably be set in the process method.

Assets

• All images and stylesheets that support the Radiant administration interface have moved to images/admin and stylesheets/admin respectively.

Extensions

This is it! The Big One. If you want to change the way Radiant works, use an extension. I’ve detailed some aspects of extensions in my previous presentation, but here’s the nitty-gritty.

• Extensions can be generated in instance mode. This is important if you want keep your install clean.
• Behaviors are no more. If you want to change the way a page behaves, subclass the Page model. Make sure your new subclass is accessible by naming the file it’s defined in using the Rails naming convention. You should probably also ‘declare’ it in the activate method of your extension to be sure it’s loaded. For example:

# app/models/hello_world_page.rb
  class HelloWorldPage < Page
    def render
      "Hello, world!"
    end
  end

# hello_world_extension.rb 
  def activate
    HelloWorldPage
  end

• Pages no longer have support for the ‘config’ part by default. If you need this functionality in your Page subclass, you must implement it yourself. You can look at MailerPage in the mailer extension for a sample implementation.

• You can add tabs to the administration interface using admin.tabs.add in the activate method of your extension. Here’s some examples:

  admin.tabs.add "Assets", "/admin/assets", :after => "Layouts"
  admin.tabs.add "Welcome", "/admin/help", :before => "Pages"
  admin.tabs.add "LDAP", "/admin/ldap" </code></pre>

• Migrations defined in your extensions can be run via rake db:migrate:extensions to migrate all extensions, or rake radiant:extensions:extension_name:migrate for a specific extension named ‘extension_name’. Extension migrations are managed independently of the main Radiant migrations, having their own version numbers, etc.

• Extensions can define custom Rake tasks in lib/tasks. Some tasks are provided for you when you generate your extension.

• Extensions can override the way SiteController invokes page processing by overriding SiteController#process_page.

Radius Tags

• Global tags are now defined in the Page model (the defaults via inclusion of StandardTags). To define your own global tags, open up the Page model and either define with a ‘tag’ block or include your own module that itself includes Radiant::Taggable. Example:

# app/models/hello_world_tags.rb
module HelloWorldTags
  include Radiant::Taggable

  tag "hello" do |tag|
    "Hello, world!"
  end
end

# hello_world_extension.rb
  def activate
    Page.class_eval { include HelloWorldTags }
  end</code></pre>

• Tags now have their own documentation DSL. Precede the tag definition with desc %{ My tag documentation }. Your documentation will be formatted with Textile. See standard_tags.rb for examples.

Testing

• Exceptions thrown inside Radius tag definitions now bubble up during tests.
• Tests work under sqlite3.
• Test tasks work in instance mode.
• Extensions can define their own “test helpers” in test/helpers. Test helpers are modules that can be easily mixed into your tests - with the test_helper :helper_name command – to add custom assertions, etc. There are a wealth of test helpers included with Radiant.
• Extensions can define their own fixtures in test/fixtures. Use extension_fixtures :model_names to use them in a test case.

Last-minute stuff

The core team has also been given until Saturday to commit any last minute changes. I’ll add them below as they come up. I will not include updates to individual extensions, so you’ll have to follow those yourself. As Gabriel Lamounier always says in his emails to the list, “Be Radiant!”

• r371 (Developers) – You can modify the ‘meta’ (more/less) area and the area just above the buttons on the page-editing interface. The ‘meta’ area can only display fields on the Page model and uses a specialized Hash format, but the buttons area can display any accessible partial. I called this changeset “facets-lite”.
• r372 (End users) – The slug/breadcrumb auto-updating should be responsive to mouse and other events as well as just typing.
• r373 (Bug fix)
• r374 (Bug fix)
• r377 (End users) Make r:date tag use “for” attribute instead of “when”.
• r378, 383 (Developers) Add extension controller generator.
• r379 Updated CONTRIBUTORS.
• r380, 383, 384, 387 – Add extension model generator.
• r381, 382, 385, 386, 393, 394, 395 (Developers) Fixing extension fixtures issues. The generated test_helper.rb should work out-of-the-box, but you may need to update existing extensions.
• r388-392 (End users) Fixed IE6 CSS bugs.
• r393-395 (Developers) Extensions use the standard fixtures command in tests now, rather than extension_fixtures. Generated tests and test helpers are adjusted to reflect this.
• r398 (End users) Denied page saves due to the optimistic locking feature should retain your changes in the interface rather than reloading.
• r400 (Developers) Extension tests can be run in instance mode.
• r403 (Developers) Extension controller and model generators can be run in instance mode.
• r404 (Developers) Extension tests are run in isolation rather than together.

UPDATE 4/25: Those are all the significant changes up to the tagging of the 0.6 release. I’m sure there will be bug fixes in the near future as they are revealed.