Change Log

Under development

0.8.0

New Features:

Closes Issues:

Additional Changes:

Known Issues:

Released versions

0.7.4

New Features:

Closes Issues:

Additional Changes:

Known Issues:

0.7.3

New Features:

Closes Issues:

Additional Changes:

Known Issues:

0.7.2

New Features:

Closes Issues:

Additional Changes:

Known Issues:

0.7.1

New Features:

Closes Issues:

Additional Changes:

Known Issues:

0.7.0

New Features:

Closes named issues:

Additional changes:

Upgrade notes

Migrations should be set to auto-run in the application config file so that the new password hash is enforced before you try to login the first time after updating. The migrations force all users to create new passwords so that the newer encryption methods are used.

The “ban” button in the users page is working now, and the permission Site.Signin.Allow has been removed. If you created a custom role which banned logins by excluding this permission, they will now be able to log in.

If you attempt to downgrade to 0.6.*, Bonfire will at best restore Site.Signin.Allow to the Administrator role. No other role will be able to log in. This was written with developers in mind, not downgrading a production system. (But it would be interesting to hear any feedback).

The comment recommending IS_AJAX as a security check has been removed. IS_AJAX is not effective as a security check. It may have happened to prevent CSRF on AJAX methods, but Bonfire now supports CodeIgniter CSRF protection (see upgrade notes for 0.6.1). For other purposes, you may prefer to avoid the Bonfire-specific constant in favour of the standard CodeIgniter method $this->input->is_ajax_request().

Because the MY_Controller file no longer ships with Bonfire, you should make a backup of your current MY_Controller file, if you have made any changes. This file will be renamed to Base_Controller.php. Any changes you made should then be redistributed over the new Controller files in application/core.

If you use the $table class var within any of your module’s model files, you will need to change that reference to $table_name.

If your module calls the activity_model for logging purposes, you will need to either switch the code to the new log_activity() helper method or load the activity_model explicitly.

All templates that use the current Template::yield() function must be updated to Template::content() due to the addition of generators in PHP 5.5.

0.6.1

Regression fixes

Upgrade Notes:

Version 0.6 prevented CSRF attacks using a standard CodeIgniter option. This should protect against clicking a malicious link (e.g. in an email or forum post), which attempts to perform actions on Bonfire. E.g. deleting modules or changing user access rights.

When upgrading to Bonfire 0.6.1, you should make sure to update config.php in the application/config folder. This is necessary in order to enable and configure CSRF protection.

As a result, any AJAX POST request you have will need to include the CSRF token. If you don’t already know how to do this, Bonfire 0.6.1 includes a simple solution. You just need two extra lines.

In the controller for the page which launches the AJAX request:

Assets::add_js('codeigniter-csrf.js')

In the AJAX request, an extra data field:

// assuming your data is not passed as a string
$.ajax({ ..., type: "POST", data:
               { ... 'ci_csrf_token' : ci_csrf_token() } } );
// or
$.post(url,
               { ... 'ci_csrf_token' : ci_csrf_token() }, ... );
// or
$(elt).load(url,
               { ... 'ci_csrf_token' : ci_csrf_token() } );

Version 0.6

Additions:

Version 0.5.2

Additions:

Version 0.5.1

Additions:

Version 0.5

Additions:

Bugs:

Version 0.2

Additions:

Enhancements:

Bugs:

Version 0.2-RC1

Released: August 11, 2011

Additions:

Enhancements:

Bugs:

Version 0.1 - Initial Release

Released: March 30, 2011