Advanced Features
Meta Fields
You can hide some of the 'meta' information fields in the admin if you'd
like by adding the string names of the fields to hide in the configuration
block:
config.hidden_meta_fields << 'keywords'
The supported meta fields that you can hide are:
- keywords
- parent -- Note: A page can't be moved without this
- filter
- preview
Page Caching
Page caching is enabled, by default, for comatose pages. Pages will only expire when you edit/delete them from the comatose admin. To remove all cached pages use the 'Clear Page Cache' command in the admin.
You can override page caching per mount point by sending
:use_cache=>'false'. It can also be overridden globally by using the
config setting:
config.disable_caching = true
Fragment Caching
Versions 0.5+ support fragment caching of inline rendered content.
You can instruct comatose not to use the fragment cache by sending
:use_cache=>false like this:
<%= render :comatose=>'path', :use_cache=>false %>
Oh, and be sure to set ActionController::Base.fragment_cache_store in
your environment.rb file:
ActionController::Base.fragment_cache_store = :file_store, File.join(RAILS_ROOT, 'tmp', 'cache', 'fragments')
Note: Caching will automatically be disabled if you send page
parameters via the :locals hash.
Data Migration
A lot of times you'll create pages in development that you want to transfer to production without having to do the old copy-n-paste dance. To help accommodate this, comatose comes with two rake tasks just for this purpose.
Page Export
By running:
$ rake comatose:data:export
You will get a db/comatose-pages.yml file with all the pages in your
active database.
The FROM environment variable is the page path starting point. It will
only export the pages from the page at path ENV[FROM] down. If you
don't specify FROM, it default to the homepage ''.
$ rake comatose:data:export FROM=faq
You can specify the output file if you don't want to use
db/comatose.yml or you want to export multiple branches by defining the
TO_FILE environment variable:
$ rake comatose:data:export TO_FILE=db/other-pages.yml
You can, of course, mix and match these:
$ rake comatose:data:export FROM=site-help TO_FILE=db/help-pages.yml
Page Import
The import process is just like exporting...
$ rake comatose:data:import
This loads the pages from db/comatose-pages.yml into your active
database.
To import somewhere other than the page tree root, you can specify the
TO environment variable:
$ rake comatose:data:import TO=faq
You can also specify a page.yml file other than the default by setting
the FROM_FILE environment variable:
$ rake comatose:data:import TO=help FROM_FILE=db/help-pages.yml
Keep in mind that task loads environment.rb, so you'll probably want
to specify the RAILS_ENV like this:
$ RAILS_ENV=development rake comatose:data:export
$ RAILS_ENV=production rake comatose:data:import
Or...
$ RAILS_ENV=development rake comatose:data:export FROM=help
$ RAILS_ENV=production rake comatose:data:import TO=help
Multi-User / Limited View
It's possible to limit the view of a user to a certain sub-branch, or sub-
branches, of the page hierarchy. You define the config.admin_get_root_page setting
to return a ComatosePage object, or an Array of ComatosePages.
This example defines both the config.admin_authorization and the config.admin_get_root_page
settings:
Comatose.configure do |config|
# Includes AuthenticationSystem in the ComatoseAdminController
config.admin_includes << :authenticated_system
# Calls :login_required as a before_filter
config.admin_authorization = :login_required
# Returns different 'root paths'
config.admin_get_root_page do
if current_user.role == 'XXXX' # This depends on your system
Comatose::Page.find_by_path( 'site/help' )
elsif current_user.role == 'YYYY'
# Returns multiple 'roots'
[
Comatose::Page.find_by_path( 'site/help' ),
Comatose::Page.find_by_path( 'app/faq' )
]
else
Comatose::Page.root
end
end
end
Using ERB Instead of Liquid
In your configuration block, set the following:
config.default_processor = :erb
Now it will use ERB for text processing instead of Liquid. There are a few minor differences in the context to keep in mind. For example, instead of using page.has_keyword.key, you can use the more ruby-like page.has_keyword? key.

Recent Comments...