FixMyStreet: Platform

Customising FixMyStreet

When you set up your FixMyStreet site, you'll want to tailor the default installation to your own requirements. This includes limiting the geographic area it will accept problem reports for, the language it's presented in, and how it looks.

Your own cobrand

Whatever you change, you’ll almost certainly need to create a cobrand, which is the mechanism FixMyStreet uses to let you deviate from its default appearance and behaviour.

As well as the configuration settings you specify in the conf/general.yml file, a cobrand is made up of a set of templates, CSS, and an optional Cobrand module that contains custom Perl code. There are defaults for all of these, so the cobrand only needs to override things that are specific to it.

We strongly recommend you follow this system – rather than just editing existing files – because it means that you’ll be able to upgrade FixMyStreet without the updates overwriting your unique changes.

It’s a good idea for a cobrand to have the same name as your site. For example, if your site is www.FixMyPark.com then your cobrand could be called FixMyPark (with the “moniker” all lowercase, like this: fixmypark, which is used for things like directory names). The default cobrand is called Default (default).

What you can change

There’s a lot you can customise on your own FixMyStreet site.

We’ve prepared a customisation checklist which covers all the key things you should work through when installing your own site.

But if you just want to see what’s possible, here are some of the aspects of FixMyStreet that you can customise:

Note that none of the above require you to know or write any Perl (the language FixMyStreet is mostly written in).

The Cobrand module

If you need more customistation than the config settings and templates give you, you’ll probably need to make a Cobrand module. This is a Perl module that is automatically loaded according to the current cobrand – you can see existing examples in perllib/FixMyStreet/Cobrand/. There is a default Cobrand (Default.pm) that all Cobrands should inherit from. A Cobrand module can then override any of the methods from the default Cobrand. See more about Cobrand modules.

Feeding back changes

It would be great if the changes you make to the code could be fed back upstream to benefit other users. Obviously if you’ve only customised templates and CSS you may not feel you have to, but it’s likely you’ll have needed to make actual code changes for your particular environment, and feeding these back means it is easier to update the code from upstream in future to gain new features and bugfixes. See more about feeding back changes.