Configuring the platform

This chapter provides you with a first look at the system that you have just installed. The administrative interface is gone, and the new Views interface requires a little getting used to. Whenever one makes a cumbersome but familiar process easier, some will ask for the old way back. Trust us: after a year of working in the new interface on the development server, it is much easier to have everything in one place.

Accessing the new installation

Depending on how you configured the baseurl (see installation), go to the index.php page for the installation.

  • Mac
  • Linux
  • Win

This is now the only url you need to remember; the index.php file is the controller within the new architecture; all pages are accessed via the index.php file, including any static pages (we may want to explain how to set up aliases for various static pages, especially for migrations). See the developer’s annex for a deeper explanation.

First look

The installation will open to the initial map view with several default reports. You can see that there are different view options above the map. These views give you different ways to view posts in your deployment. You can change the default view for any deployment, saved search, or collection.

In the menu you can also see: Saved Searches and Collections. Each of these will show you a pre defined group of posts. Saved searches - as one expects - show posts based on some collection of filters or search terms; Collections show a manually curated set of posts. Will dig into both of these features later on in the guide.

Users may have one or more roles, such as an admin or participant.

Users might also be Contacts who are sending messages via social media or email (or via an API?).

Technology preparation

When you installed your server, you may have installed the software on a temporary server to allow you to play with the tools. The deployment requires a different setup. In some remote places, you may be running Ushahidi using a Nokia 1100 to connect the platform to the cellular network. In cities, you may need to find an elastic server that can quickly deal with spikes in traffic not only of inbound data, but views from the public. If you are setting up a small network of sensors around a river bed, your loads will not be the same as an election monitoring effort that hits the national TV reports or is announced as a trending hashtag on the Twitter homepage.

You should sit down with a technologist and plan out the potential scenarios that could happen with data collection. The question you will need to ask is if you need to hire a technologist to be part of your team. Simple installations may need someone to get you started and be on call for occasional glitches and gremlins. More complex or sensitive deployments may need someone to be watching over the server, managing the inevitable string of questions and data queries from analysts, and monitoring and protecting the system from cyberattack.

Configuring Mobile Support

In order to use your new deployment with the Ushahidi Mobile App for Android or iOs, you will need to complete two steps.

First, make sure that the config.json file is present and that the appropriate variables have been set.

The file should have the following structure

    "client_id": "ushahidiui",
    "client_secret": "35e7f0bca957836d05ca0492211b0ac707671261",
    "backend_domain": "",
    "backend_url": "",
    "google_analytics_id": "",
    "intercom_app_id": "",
    "mapbox_api_key": ""

There are two forms of configuration for Ushahidi Platform, single or multisite. The single site is the most common, for this you will need to set 

    "backend_url": "",

to the fully qualified url where your api instance is hosted.

If you are hosting multiple sites using a single API then the value for backend_domain should be the address of the Platform API instance. For example, if your Platform API is hosted at, then you would set the variable as:

    "backend_domain": "",

The google_analytics_id, intercom_app_id and map_box_api_key are not required. They should be set to your own values if you are using any of these three elements.

Second, ensure that your webserver is correctly serving the config.json file as application/json and that your server allows this file to be accessed through CORS. To do this you can add the following to your nginx config

# CORS support for mobile client
location /config.json {
     if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS';
        # Custom headers and headers various browsers *should* be OK with but aren't
        add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
        # Tell client that this pre-flight info is valid for 20 days
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain charset=UTF-8';
        add_header 'Content-Length' 0;
        return 204;
     if ($request_method = 'GET') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
        add_header 'Access-Control-Expose-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';