Alaveteli uses themes to make the site look and run differently from the default. Simple changes like colour and logo are relatively easy, but themes can also control more complex things like how the site behaves.
When you customise your Alaveteli site, there is a lot you can change just by editing the config settings. But if you want to change the way the site looks, or add more specific behaviour, you’ll need to make a theme.
You don’t need to be a programmer in order to make simple changes, but you will need to be confident enough to copy and change some files. If you’re not sure about this, ask for help!
The easiest way to create a new theme is to follow these steps.
Sometimes you may want to change the core templates in a way that would benefit everyone, in which case: great! But please discuss the changes on the mailing list first, make them in a fork of Alaveteli, and then issue a pull request.
Your theme is a separate repo
We use git to manage Alaveteli’s source code, and Alaveteli expects your theme to be in a git repository of its own.
Although you can start customising your site on your
by playing with the
alavetelitheme theme that Alaveteli ships with, we recommend
you make it into your own repo as soon as you can. If you’re seriously customising
— and certainly before you can deploy to a
production server —
you must do this. Make sure you choose a unique name for your theme (and hence its
repo). If your site is
abcexample.com, we suggest you call your theme
themes:install rake task, which installs themes, works by
getting the git repo from the URL specified in the config setting
THEME_URLS. This is
why your theme must be in its own git repo.
The easiest way to create a new theme is to follow these steps.
What you might want to change
The most common requirement is to brand the site: at a minimum, inserting your own logo and colour scheme. You should also add the categories that authorities can appear in (you can see these as groupings on the left-hand side of the View authorities page on WhatDoTheyKnow). You may also want to tweak the different states that a request can go through.
There may also be other things you want to customise – talk to us on the developer’s mailing list to discuss what you need. We’re happy to help work out the best way of doing customisation and it’s even possible that what you want has already been done in someone else’s theme.
The important principle to bear in mind is that the less you override and customise the code, the easier your site will be to maintain in the long term. Any customisation is possible, but for each customisation beyond the simple cases documented here, ask yourself (or your client), “can we possibly live without this?” If the answer is “no”, then always ask on the mailing list about a pluggable way of achieving your goals before you override any of the core code.
We try to encapsulate all site-specific functionality in one of these places:
- site configuration
use the config settings for example, the name of your site, the available languages, and so on. You change these by editing
for example, the public authorities to whom requests should be addressed, and the tags and categories for grouping them. You control all this through the admin interface: see the admin manual.
- a theme
lib/themes. The page you’re reading now is all about what you can do in a theme.
By default, Alaveteli ships with the sample theme (
alavetelitheme), so your
config/general.yml contains this:
You can also install the theme by hand, by running:
bundle exec rake themes:install
This installs whichever theme is specified by the
The sample theme contains examples for nearly everything you might want to customise. We recommend you make a copy, rename it, and use that as the basis for your own theme.
setting allows you to specifiy more than one theme — but
normally you only need one.
Make sure your theme is as lightweight as possible
The more you put in your theme, the harder it will be to upgrade to future versions of Alaveteli.
Everything you place in your theme overrides things in the core theme, so if you make a new “main template”, then new widgets that appear in the core theme won’t appear on your website. If you want them, you’ll need to manually update your version of the template to include them, and potentially you’ll need to do this every time the core theme changes.
Therefore, you should consider how you can brand your website by changing as little in the core theme as possible. An extreme – but not impossible – way to do this is to rebrand the site by only changing the CSS, because this means none of the templates are being overridden.
However, even with minimal customisation, you must also add custom help pages (described below). Alaveteli’s default help pages are deliberately incomplete. We know that every installation is going to be operating in different circumstances, so a generic help text cannot be useful. You must write your own, for your own users.
Branding the site
The core templates define the layout and user interface of an Alaveteli site.
They are in
app/views/ and use
ERB syntax. For example, the template for the home page lives at
app/views/general/frontpage.html.erb, and the template for the “about us”
page is at
As described above, although you could edit those core files directly, this would be a Bad Idea, because you would find it increasingly hard to do upgrades.
Instead, you should override these pages in your own theme, by placing them
at a corresponding location within your theme’s
lib/ directory. For example,
this means that if you put your own copy of the “about us” template
then that will appear instead of the core “about us” file.
Changing the site logo
Alaveteli uses Rails’ asset pipeline
to convert and compress stylesheets written in
into minified concatenated CSS. Assets are stored in core Alaveteli under
app/assets – in
default theme has corresponding asset directories in
Asset files placed in these directories will override those in the core
To add your own logo, you will need to prepare 2 separate logo files - the “standard” one and a double size version that will prevent your logo looking blurry on high resolution screens such as Apple’s Retina displays.
The easiest method is to start with a logo image which is exactly twice
the size you want it to appear on the screen (if you try to create the larger version
from the smaller one, you run the risk of ending up with ending up with your
larger file looking blurry anyway). So if you want your finished logo to be 275
pixels wide and 44 pixels high (as per our current example logos), your
high resolution version should be 550 pixels by 88. Save this as
and copy it to your theme as
email@example.com so that it
will replace the example image.
Now make a copy of your
firstname.lastname@example.org and make it half the size - be careful to
keep the proportions the same or your logo will look squashed! - so in our example
it will be 275 x 44 pixels. Save this as
logo.png and place it in your theme as
A logo for social media sharing
There is a third version of the logo that is used for Facebook’s Open Graph
metadata so that content shared on Facebook will have your logo displayed
alongside it. This logo needs to be square, at a minimum size of
256 x 256 pixels and should be placed in your theme as
Changing the colour scheme
Alaveteli uses a set of basic
modules to define the layout for the site on different device sizes, and some
basic styling. These modules are in
colours and fonts are added in the theme –
alavetelitheme defines them in
used in the theme are defined as variables at the top of this file and you can
edit them in your version of this file in your own theme.
Changing other styling
To change other styling, you can add to or edit the styles in
Styles defined here will override those in the sass modules in
app/assets/stylesheets/responsive as they will be imported last by
app/assets/stylesheets/responsive/all.scss. However, if you want to
substantially change the way a particular part of the site is laid out,
you may want to override one of the core Sass modules. You could override the
layout of the front page, for example, by copying
and editing it.
Adding your own categories for authorities
You should add categories for the authorities on your site – Alaveteli will display the authorities grouped by categories if you have set any up. Alaveteli uses tags to assign authorities to the right categories, but you should add tags anyway because they are also used by the site’s search facility. Together, categories and tags help your users find the right authority for their request.
Customising the request states
As mentioned above, if you can possibly live with the
default Alaveteli request statuses,
it would be good to do so. You can set how many days must pass before
a request is considered “overdue” in the main site config file —
If you can’t live with the states as they are, there’s a very basic way to add
to them (we’re working on this, so it will be improved over time). Currently,
there’s no easy way to remove any. There is an example of how to do this in the
To do add states, create two modules in your theme,
InfoRequestCustomStates must have these methods:
theme_calculate_status: return a tag to identify the current state of the request
theme_extra_states: return a list of tags which identify the extra states you’d like to support
theme_display_status: return human-readable strings corresponding with these tags
RequestControllerCustomStates must have one method:
theme_describe_state: return a notice for the user suitable for displaying after they’ve categorised a request; and redirect them to a suitable next page
When you’ve added your extra states, you also need to create the following files in your theme:
lib/views/general/_custom_state_descriptions.html.erb: Descriptions of your new states, suitable for displaying to end users
lib/views/general/_custom_state_transitions_complete.html.erb: Descriptions for any new states that you might characterise as ‘completion’ states, for displaying on the categorisation form that we ask requestors to fill out
lib/views/general/_custom_state_transitions_pending.html.erb: As above, but for new states you might characterise as pending states.
You can see examples of these customisations in
for the Kosovan version of Alaveteli, Informata Zyrtare (ignore the
_custom_state_transitions.html.erb, which is
Customising the help pages
The help pages are a really important part of an Alaveteli site. If you’re running Alaveteli in another language, you’ll want to show your users localised versions of the help pages. Even if you’re running the site in English, the default help pages in Alaveteli are taken from WhatDoTheyKnow, and are therefore in some places relevant only to the UK. You should take these pages as inspiration, but review their content with a view to your jurisdiction.
The important pages to customise and translate are listed here. We note where Alaveteli links to these pages (sometimes to anchors for particular sections within the pages) or takes users directly to them. You can check whether your theme has all the required pages
and sections by running
bundle exec rake themes:check_help_sections.
alaveteli: about the Alaveteli framework.
api: information about the site’s Application Programming Interface (API).
contact: how to get in touch.
credits: who is involved in the site. Importantly, includes a section on how users can help the project. Users are referred to this section if they categorise all the requests in the categorisation game.
officers: information for the officers who deal with FOI at authorities. They get a link to this page in emails that the site sends them.
requesting: the main help page about making requests. How it works, how to decide who to write to, what they can expect in terms of responses, how to make appeals, etc. Users are referred to the section on how quickly a response to their request should arrive when their request is overdue for a response. They are referred to the section on what to do if the Alaveteli site isn’t showing the authority they want to request information from the page that allows them to list and search authorities.
unhappy: users are taken to this page after a request that has been somehow unsuccessful (e.g. the request has been refused, or the authority is insisting on a postal request). The page should encourage them to keep going, e.g. by starting a new request or addressing it to a different body. In particular users are referred to the section on using other means to get their question answered. If the user has requested an internal review of their request, they are referred to the section on this page that describes the law relating to how long a review should take.
why email: a snippet of information that explains why users should insist on replies by email. This is displayed next to requests that have “gone postal” - where the authority has asked for the user’s physical address so that they can reply with a paper response.
sidebar: a menu for the help pages with a link to each one. You should customise this so that it includes any extra help pages you add, and doesn’t include any you remove.
You can add your own help pages to your site by replacing the default pages in your theme with your own versions, using a locale suffix for each page to indicate what language the page is written in. No locale suffix is needed for pages written for the default locale for the site. For example, alavetelitheme contains help pages for the default ‘en’ locale. If no help page exists in the theme for a particular page in the locale that the site is being viewed in, the default help page in English will be shown.
Adding new pages in the navigation
You can extend the base routes in Alaveteli by modifying
The example in
alavetelitheme adds an extra help page. You can also use this
to override the behaviour of specific pages if necessary.
Adding or overriding models and controllers
If you need to extend the behaviour of Alaveteli at the controller or model
alavetelitheme/lib/model_patches.rb for examples.
Quickly switching between themes
you can use
to set the current theme if you are working with multiple themes. This can be
useful for switching between the default
alavetelitheme and your own fork.
Testing your theme
You can add tests for the changes in functionality that are implemented
in your theme. These use rspec, as does the main Alaveteli test suite.
They should be put in the
spec directory of your theme. They are run
separately from the main Alaveteli tests by executing the following command in the directory in which Alaveteli is installed (substituting your theme directory for
bundle exec rspec lib/themes/alavetelitheme/spec
You can see some example tests in the whatdotheyknow-theme.