This page doesn't document all changes in 2.5, but specifically documents breaking changes that may effect developers migrating to v2.5

What's changed

• Mapping:
  The mapping code for the main page has been refactored and is no longer tied to the timeline. We've consolidated the mapping code into a single JavaScript library; ushahidi.js. This library has an event system which is extensible. The stock events can be triggered for actions such as zoom changes, resizing the map viewport, change of base layer etc. As a by the way, decoupling the timeline from the map effectively means that you can plug in your own timeline. The stock timeline is uses jqplot. This change affects those plugins that hook into the main map such the fullscreen map plugin

• Themes:
  • Views for the front-end have been grouped into directories that are named after the controllers that make use of them; For example, all the views for the reports controller are now in the themes/default/views/reports directory.
    This change will most definitely affect any custom themes (besides the stock ones) that you may have on your deployment. To make them compatible with the upcoming release, rename view files to follow the convention outlined above (and used in the default theme). The following is list of views and their new file names:
    • alert_radius_view.php > alerts/radius.php
    • alerts.php > /alerts/main.php
    • alerts_confirm.php > /alerts/confirm.php
    • alerts_unsubscribe.php > /alerts/unsubscribe.php
    • alerts_verify.php > /alerts/verify.php
    • alert_radius_view.php > /alerts/radius.php
    • contact.php >
    • feed.php >
    • feeds.php > /feed/feeds.php
    • footer.php >
    • header.php >
    • help.php > REMOVED
    • help_view.php > REMOVED
    • konana_error_page.php >
    • login.php > /login/main.php
    • main.php > /main/layout.php
    • main_map.php > /main/map.php
    • main_timeline.php > /map/timeline.php
    • page.php >
    • profile.php > /profile/user.php
    • profile_browse.php > /profile/main.php
    • reports.php > /reports/main.php
    • reports_comments.php > /reports/comments.php
    • reports_comments_form.php > /reports/comments_form.php
    • reports_listing.php > /reports/list.php
    • reports_stats.php > /reports/stats.php
    • reports_submit.php > /reports/submit.php
    • reports_submit_custom_forms.php > /reports/submit_custom_forms.php
    • reports_submit_thanks.php > /reports/submit_thanks.php
    • reports_view.php > /reports/detail.php
    • reports_view_custom_forms.php > /reports/detail_custom_forms.php
    • pagination/front-end-reports.php >
    • blocks/main_news.php >
    • blocks/main_reports.php >
  • ALL the views (including the *_js.php) for the front-end are now under the themes directory.
    View moved from application/views to themes/default/views (and into subfolder as appropriate)
    • feeds_atom.php > /feed/atom.php
    • feeds_rss2.php > /feed/rss2.php
    • reports_js.php > reports/reports_js.php
    • reports_view_js.php > reports/view_js.php
    • reports_submit_edit_js.php > reports/submit_edit_js.php
    • login_js.php > login/login_js.php
    • main_js.php > main/main_js.php
    • alerts_js.php > alerts/alerts_js.php
• Settings Table: The structure for the settings table has been modified so that data are stored as key/value pairs. Previously, this table only had one row and each setting was a column. In the new structure, there are only 3 columns: id, key, value. This now allows plugins to add their own settings. The settings model class (application/models/settings) has the necessary utility methods for retrieving and saving data from/to the restructured table. There is an upgrade script that shall effect this change on your schema.
  • Old schema:
  • New schema:
• Installer:
  The installer has been updated to work with the new settings table structure and we now perform the installation check in index.php. Previously, the installation check was being done via a hook (application/hooks/0_init.php)
• Configuration Files:
  The following config files are no longer in the repository: config.php, auth.php and encryption.php. Instead, we are only maintaining their templates (.template.php) which are the ones that the installer uses to create the config files to be used by the application. This change will affect users who automatically update/upgrade their deployment straight from GitHub - a git pull shall DELETE the mentioned config files (the ones we're no longer tracking) so please BACKUP these config files before engaging in acts of git fu.
• Permission Tables:
  User permissions have been refactored into a separate table form roles. This now allows plugins to add their own permissions. There is an upgrade script that shall affect this change on your schema.
  • Old Schema
  • New Schema
  • Previous methods for checking permissions
    are now deprecated in favor of new extensions to the Auth library:
    The $user parameter is optional and defaults to the logged in user if not passed.
    If you already have a user object you can check permissions directly on the objection like so:
  • Access to member and admin dashboard are now governed by permissions: 'admin_ui' and 'member_ui'
    Existing custom roles will be automatically granted the admin_ui permission but this can now be added or removed as needed.