ci-bonfire

This is part 2 of a small tutorial that copies along the TutsPlus Ribbit project in CodeIgniter and Bonfire. Last time we managed to get the front of the site in place and styled, all using a single home controller. The Database I like to start ... [More] projects by getting the data layer in place, and Bonfire makes this step very easy. We will need two additional tables for this application: ribbits - contains the actual ribbits, or posts. follows - a list of who follows who To make sure the data is portable between or development setup and our production server, we'll make use of a Migration. Create a new file at application/db/migrations/001_Initial_tables.php. This will hold all of the code to setup our initial tables and modify the users table. The file should look like this: ``` class Migration_Initial_tables extends Migration { public function up() { $sql = array(); // Ribbits $sql[] = "CREATE TABLE ribbits ( id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT, user_id INT(11) UNSIGNED NOT NULL, ribbit VARCHAR(140), created_at DATETIME, PRIMARY KEY(id, user_id) );"; // Follows $sql[] = "CREATE Table follows ( id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT, user_id INT(11) UNSIGNED NOT NULL, followee_id INT(11) UNSIGNED NOT NULL, PRIMARY KEY(id, user_id) );"; foreach ($sql as $s) { $this->db->query($s); } } //-------------------------------------------------------------------- public function down() { $this->dbforge->drop_table('ribbits'); $this->dbforge->drop_table('follows'); } //-------------------------------------------------------------------- } ``` The migration's up() method is ran to create the database changes. In this case, we're creating the ribbits and follows tables. The down() method reverses those changes by dropping the tables. For this tutorial, we're assuming that the app is using MySQL and so we'll stick with MySQL-specific queries. We could have just as easily used dbforge for this, like we did in the down() method. To apply this migration we could log into the admin area and run them manually. For now, though, let's have them run automatically. Open the file application/config/application.php and scroll down to the bottom of the file. Edit the migrate.auto_app and set it to TRUE so it will check for new migrations on every page load. $config['migrate.auto_app'] = TRUE; Then reload any of the pages and the migration will be ran, creating the new tables in your database. The Models To quickly get up to speed we'll create 2 new models that extend Bonfire's MY_Model class. This provides all of the CRUD functionality, and more, so we just need to create skeleton files and tweak a few settings. Ribbits First, create the new ribbit model at application/models/ribbit_model.php. We will use the bare minimum code here to keep things clear, but the Models has quite a few options you can put to use in your own applications. ``` class Ribbit_model extends MY_Model { protected $table_name = 'ribbits'; protected $date_format = 'datetime'; protected $log_user = true; protected $set_created = true; protected $created_on_field = 'created_at'; protected $created_by_field = 'user_id'; //-------------------------------------------------------------------- } ``` This creates the Ribbit_model class that extends MY_Model to take advantage of our existing functionality. We tell the model which table to use, set our date_format to datetime to match the table structure for created_at. We also tell it which fields to automatically populate with the creation date and who created it (user_id). During any insert() calls, the model will automatically fill in the created_at date and record the current user id in the user_id field for us. Follows The follow_model is pretty much the same, so create a new file, follow_model.php and edit it to reflect the following: ``` class Follow_model extends MY_Model { protected $table_name = 'follows'; //-------------------------------------------------------------------- } ``` This time, the model is much simpler, since we don't need to record any of the creation info. All we need is the table name. The Home Page Now that we have the data layer in place, it's time to move back to our controller layer and start hooking the pieces together. User Registration To kick things off, let's make sure that new users can signup. This functionality already exists in Bonfire, but doesn't match the styling and positioning that our app requires. And it probably includes too much information, to be honest, with user_meta and all, so let's replace the signup for we did last time with this new one below. This is in the application/views/home/index.php file. ``` = Template::message(); ?> New to Ribbit? = form_open(REGISTER_URL); ?> = form_close(); ?> ``` While I prefer my HTML to look like HTML, I always use the form_open and form_close tags since they help provide CSRF protection in the form submission process. So modify the home controller's index method to load the form helper. ``` public function index() { $this->load->helper('form'); Template::render(); } ``` To use Bonfire's existing code, we send users to the users module upon form submittal. Unfortunately, that will take us back to users/register upon failure, so we will have to make some small modifications to the Users module. For real projects, you should copy the entire users module and paste it into application/modules before making changes. For this example, though, we'll simply modify the existing code. Open up bonfire/modules/users/controllers/users.php. Scroll down to the register method, and let's get started. The first thing we want to do is to make sure that we can tell it where we want to redirect to. We're including this in a hidden $_POST var, so add the following line just after the opening braces: $redirect_url = $this->input->post('redirect_url') ? $this->input->post('redirect_url') : REGISTER_URL; Scroll down to around lines 583 and 588, and modify the redirect value to use our new value. Template::redirect($redirect_url); Template::set_message(lang('us_registration_fail'), 'error'); redirect($redirect_url); We also need to catch when validation fails, so add the following code after the closing brace around line 591: if ($this->input->post('redirect_url')) { Template::set_message( validation_errors() , 'error'); redirect($redirect_url); } This sets an error message for us and redirects us back to the home page, since we can't display validation errors like we normally would. Now, validation will always fail since this method requires a few fields that we don't require. So, to fix things up, remove the required validation rules from language, timezone, and display_name on lines 460-462 since we're not collecting those. We'll leave the lines there, though, in case we change our minds in the future. Also, comment out lines 485-487 where we're composing the $data array to send to the user model. If we try to submit an empty form, we see one more error we didn't expect: 'The Country field is required'. That is due to a required flag on a user_meta value. Let's remedy that. Open up application/config/user_meta.php and removed the required flag from the 'country' array's rules. Flash Messages When there are validation errors, this will show a small 'flash message' using the Template library's message features. We do need to style the message, though, since it's built to use Bootstrap for it's CSS. Open up application/config/application.php config file again. This time, scroll down to line 175, where it's setting up the template to use for our flash messages. Let's simplify things a bit here. $config['template.message_template'] =<< {message} EOD; Then, edit our theme's CSS file to make these styles a bit more pleasing. Edit public/themes/ribbit/css/style.less and add the following code at the bottom: .alert { padding: 0.5em; border: 1px solid #ccc; background: #efefef; margin-bottom: 1em; line-height: 1.5; } .alert.error { border-color: #ebccd1; background-color: #f2dede; p { color: #b94a48; margin: 0; } } .alert.success { border-color: #d6e9c6; background-color: #dff0d8; p { color: #468847; margin: 0; } } Ah. Much better. Now, we can register a new user and we still have all of the validation types that Bonfire offers at our disposal (though we might have to style some more pages to get the full complement of functionality, like password resets, etc.) User Login Now that users can sign up, it's time to allow them to log in and start using the site. First, we need to start by modifying the simple form in the page's header. Open up public/themes/ribbit/index.php and replace the existing form with the following code: ``` auth->is_logged_in()) : ?> Logout = form_open(LOGIN_URL, 'class="login"') ?> = form_close(); ?> ``` If the user is not logged in, then a login form is shown. If they are, then a simple Sign Out link is shown. This requires that the Auth library be loaded, which it's not currently. So let's add a constructor to our home controller and load it there. We'll also move our form helper loading to here, since all pages will need it for the login menu. ``` public function __construct() { parent::__construct(); $this->load->library('users/auth'); $this->load->helper('form'); } ``` We need to adjust the CSS a little bit to allow for a submit button. Edit style.less again, adding the following couple of lines: form.login input[type="email"], form.login input[type="password"] { width: 190px; } All on one line again. Whew. Now that things are looking nicer, we need to make a quick tweak to our users controller again, just to allow us to redirect back to the home page on errors. Add the following quick redirect check at line 108, just after the closing brace for the if statement: if ($this->input->post('redirect_url')) { redirect($this->input->post('redirect_url')); } Once a user is logged in, we don't want them to see the front page again, but the login script is going to send them back there anyway. So, let's modify the home controller's index page to check if the user is logged in. If they are, it should redirect them to the 'buddies' page. ``` public function index() { if ($this->auth->is_logged_in()) { redirect('buddies'); } Template::render(); } ``` Until Next Time There we have it. We've gotten our data layer setup and ready to go, and integrated user registration, login and logout into Bonfire. And it's been pretty painless so far. Next time, we'll wrap up and flesh out our buddies, ribbits and profiles pages. [Less]

As part of the in-progress 0.7.1 release, I've rewritten the modular code that we use from the ground up. Let me clear that up. I didn't write most of the code. It's an combination of WireDesignz' HMVC code and jenssegers' HMVC code. Additionally ... [More] , this does include a new Route class that provides very much improved routing for your CodeIgniter apps. Why the Rewrite? The primary reason for the rewrite was to allow for a more complete separation between the core Bonfire code and your application. To do that, required hacking some core files, so I thought it was time to move the routing system into being a core part of the system as a whole, not just an addon. This gives us lots of opportunity for the future to improve things as we need to. Second, though, was the integration of a new, light-weight menu system that is going to be taking care of the admin menus in this next release. This is going to let us revisit the way that we handle Contexts currently, and the new Route class is a core part of that. Basically, it was time. We Need You Before we can make this one official, though, we need to have it tested out. It's working for Bonfire, but it is intended to be a nearly invisible replacement of the Loader and Router. That's where you come in. Give the modules branch a spin and [let us know](https://github.com/ci-bonfire/Bonfire/issues?directi if you run into any errors with it. [Less]

Over at NetTuts, they've put together a series of tutorials that show how to build a simple Twitter clone, called Ribbit in a variety of different languages. Using their concept as an example, lets step through how you might build the exact same ... [More] application with Bonfire acting as the admin area for us to manage users, etal. This is the first of two or three tutorials covering the process. We'll cover the basics they cover, user login and signup, Ribbitting, and friends, etc. and might even delve into some topics they didn't, like the AJAX solution, etc. This tutorial assumes that you already have a clean install of Bonfire up and running, with database, and with the index.php removed from the URL. A repo of the code is being kept at Bonfire's GitHub account if you want to download a save a little time as you follow along. This code will assume it's already been installed, so you will need to edit the database config file and copy over a working table from another stock 0.7 install to use. You've Got The Look They did a good job of describing the benefits of LESS in their intro tutorial, so I won't touch on that here. Instead, we're going to focus on taking their code and design, and converting it to work in Bonfire. Get Your Assets In Line To get started, download their source files and extract them to some place safe on your hard drive. Move their basic assets over to a new theme inside the public/themes folder. We'll call the theme ribbit for simplicity. Next, copy the base assets into place: Move the files from the gfx folder to public/assets/images/. Copy the styles.less file into a new folder at public/themes/ribbit/css Copy the less.js file into a new folder at public/themes/ribbit/js Now, we need to modify the less file to correctly point to the new images location. Open the style.less file in your favorite editor and do a global find/replace for gfx/ to be replaced with /assets/images/. Base Template Next, we need to create a new layout file for the theme. Bonfire will automatically use the index.php file as the base, so create that now at public/themes/ribbit/index.php. Copy and paste the contents of their index.html file into this new file. !DOCTYPE HTML> <html> <head> <link rel="stylesheet/less" href="/themes/ribbit/css/style.less"> script src="/themes/ribbit/js/less.js">[removed] <body> <header> Twitter Clone </header> Ribbit - A Twitter Clone Tutorial </body> </html> Now, to make sure that all public-facing pages are using the new theme, let's edit the Front_Controller to set the theme for us. The Front_Controller is a foundation controller that is used to put common functionality for the front pages in once place. It can be found at application/core/Front_Controller.php. Be sure to edit the tags for the less.js and styles.less paths so they point to the proper location. It only has a single method, the constructor. Edit that method and tell the template library to use the new theme, by inserting the following line anywhere after loading the template library itself. Template::set_theme('ribbit', 'junk'); The first parameter is the name of the theme to set as the active theme. Since Bonfire supports parent/child theme relationships the second parameter would be the name of the parent theme, or the fallback theme. In this case, we don't want to use one, so we simply set it to something random. If you try to reload your frontpage now, you'll see the same 'Welcome to Bonfire' page as before. That's because the default home controller does not extend from the Front_Controller. Let's fix that now by replacing the existing home controller with our own. Erase the contents of the application/controllers/home.php file and replace it with: class Home extends Front_Controller { public function index() { Template::render(); } //-------------------------------------------------------------------- } The Template::render() function tells Bonfire to display the contents of a file found at application/views/home/index.php, within the current theme. Refresh your front page again, and you'll see your new theme, with the logo, background, footer, and a broken image in the bottom right corner. Let's fix that real quick so it doesn't just nag us the entire time. Open up the theme's index.php file again and change the location to point to the proper location. Aaah. Much better. Only problem is that our content isn't showing up within the template file itself. Easy enough to fix. Again in the theme's index file, we need to add a single line between the wrapper div open and close tags. php echo Template::content(); ?> Refresh again, and you'll see your content sitting pretty in it's place. Well, maybe not too pretty, yet, but we'll fix that up next. The Home Page The content for the home page sits at application/views/home/index.php Open up that page now and we'll insert their code for the login boxes and registration form. Remember, during this stage, we're just bringing over the looks. None of the functionality. We'll integrate that in the next tutorial. Insert the following placeholder login form after the in the header, but before the closing tag. <form> <input type="email"> <input type="password"> </form> Now, on to the registration form and frog image. Erase the contents of the home/index file and insert the following code. New to Ribbit? <form> <input name="email" type="text"> <input name="password" type="text"> <input name="password2" type="password"> <input type="submit" value="Create Account"> </form> The Buddies Page In order for a new page to display, we'll need to create a new method to show it. We have a few options here. We could create a new Buddies controller to hold the page. We could create a new module, which might be useful if we thought we could re-use the code on another project, or simply wanted to take advantage of some of the context capabilities in the admin area. For this simple demonstration, though, we'll keep things simple and collect most of our functionality into the home controller. So let's make a new method so that we can navigate to the page. This goes in the home controller we were just in. public function buddies() { Template::render(); } That will try to display a view file based on the controller name (as the folder) and the method name (as the file), so lets give it one. Create a new file at application/views/home/buddies.php buddies. Add the "Ribbit" box and the User Info area. Create a Ribbit <form> <textarea name="text" class="ribbitText"></textarea> <input type="submit" value="Ribbit!"> </form> Your Ribbit Profile Frogger @username 567 Ribbits45 Followers32 Following Cras justo odio, dapibus ac facilisis in, egestas Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. http://net.tutsplus.com/tutorials/php/ ... Your Ribbit Buddies Kermit @username 15m Cras justo odio, dapibus ac facilisis in, egestas Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. http://net.tutsplus.com/tutorials/php/ ... Frogger @username 15m Cras justo odio, dapibus ac facilisis in, egestas Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. http://net.tutsplus.com/tutorials/php/ ... Kermit @username 15m Cras justo odio, dapibus ac facilisis in, egestas Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. http://net.tutsplus.com/tutorials/php/ ... Hypnotoad @username 15m Cras justo odio, dapibus ac facilisis in, egestas Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. http://net.tutsplus.com/tutorials/php/ ... Kermit @username 15m Cras justo odio, dapibus ac facilisis in, egestas Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. http://net.tutsplus.com/tutorials/php/ ... Hypnotoad @username 15m Cras justo odio, dapibus ac facilisis in, egestas Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. http://net.tutsplus.com/tutorials/php/ ... Navigate to /home/buddies and you should see your new page. We'll fix the URL to something nicer later. Public Ribbits Page This page shows the public information and doesn't require a user to be logged in. Again, we need to create a new method to hold the page, so create the ribbits method in our home controller. public function ribbits() { Template::render(); } Then create a copy of the buddies.php view file, and name it ribbits.php. Strip out the div with an id of ribbits from the new file and your new page is ready. You can find it at /home/ribbits. Again, we'll clean up the URLs in a bit. Public Profiles Page This page presents a list of public profiles that users can search through. One last time, create a new method called profiles in the home controller. public function profiles() { Template::render(); } Then a new view at home/profiles.php. Search for profiles <form> <input name="query" type="text"> <input type="submit" value="Ribbit!"> </form> Public Profiles Kermit @username 625 followers follow Cras justo odio, dapibus ac facilisis in, egestas Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. http://net.tutsplus.com/tutorials/php/ ... Frogger @username 329 followers follow Cras justo odio, dapibus ac facilisis in, egestas Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. http://net.tutsplus.com/tutorials/php/ ... Hypnotoad @username 129 followers follow Cras justo odio, dapibus ac facilisis in, egestas Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. http://net.tutsplus.com/tutorials/php/ ... Your new page is now ready at /home/profiles. Cleaning up the URLs Before we're done for today, lets make our site structure a little nicer by editing the routes. Open up application/config/routes.php file and we will setup a few aliases so that the site is nicer to get around in. $route['buddies'] = 'home/buddies'; $route['ribbits'] = 'home/ribbits'; $route['profiles'] = 'home/profiles'; There we go. Now we can access the pages without having the home portion showing in the URL. I should point out here that the URLs can still be accessed at /home/buddies, etc. In this case, that's not a problem, but there might be occassions that you would not want users to access the page at that location. In that case, you would simply provide an empty string on the right side of the statemen and it would block access. Conclusion That's a wrap for this part of the tutorial. We have all of the assets in place and the site is showing us the basic pages. Next time, we'll hook in our existing users' system, restrict access to a few pages, setup our models, and more. [Less]

The cries happen every year or so. CodeIgniter is dead. They've been saying this for quite a while, but I don't believe them. Granted, I'm fond of the framework and have been using it since 2006. It's extremely stable. Fast. Quite flexible. It can do ... [More] everything I've ever needed it to. Sure there are a few annoyances, but that's the same with every other framework I've used, including Rails, Laravel, and Cake. Here at Bonfire, though, we believe in CodeIgniter. However, we also believe it needs to be able to grow and morph a bit to keep up with the demands of modern developers. So I've decided that Bonfire will no longer be a pure CodeIgniter application. What does this mean? Simply that we won't be afraid to tweak core files anymore where we need to. Yeah, I hear the screams of "Blasphemy!" but hear me out. We will strive to keep the changes minimal but there are a few places where some additional tweaks are needed in order to provide a more powerful, flexibile experience. Starting with version 0.7.1 we are overriding a couple of core files. I think you'll be happy with the changes coming down the pike. Code Separation We made huge strides in 0.7 in getting Bonfire's code away from your application's code as much as possible. However, there were a few things that we couldn't separate out and had to be left in the application folder. So we're making a couple tweaks to the Common and CodeIgniter files that allow us to store ALL of Bonfire's specific, do not touch, code in the bonfire folder. This allows us you to upgrade as easily as possible. The only exception here will be the stock controllers that we build on top of. They'll still reside in the application folder, but only because there are likely changes that you'll need to make for most any application within those files so we don't want to overwrite in core upgrades. Routing One of the places that feels the weakest to me, compared to more recent PHP frameworks, is the routing system. So we've made some big additions here. The first is a new Route library class, patterned after Jamie Rumbelow's excellent Pigeon library and Laravel's Router. This new library is already written and provides great new features like: HTTP Verb-based routing, so you can assign routes only to respond if certain HTTP verb is in use. Like specifying a route just for GET request and another (at the same URL) for POST request. This makes building RESTfull routes easy. Resourceful Routes make REST even easier by providing a single method to create all standard REST routes for you, though you can definitely customize the way it works. Prefixing Routes groups routes together under a single URI segment heading, like 'api' or 'banking' or whatever. Context Routes replace the current context system and makes it easy to add new context areas that map from one segment to any controller in your modules. Yes, it still requires modules, but is a little less magic and much more flexible. Named Routes give names to routes so that you can reference the names throughout your application instead of the route. That way you can change the URL in the routes config file and not have to worry about your application breaking. You can grab this library for any of your CI based applications today over at my GitHub account. It's fully tested and has an in-depth readme over there. Modules We've overridden the Loader and Router classes with our own custom versions. These contain the new module code that we'll be using from here on out. It replaces WireDesignz excellent HMVC code that we've been using since day one and will provide all of the same functionality. This is based on Jens Segers HMVC code with some modifications along the way. So, why did we switch if it has the same functionality? We needed a solution that would help us load files from Bonfire directly, and from Bonfire's modules. So it had to be something easy to integrate. Jen's code is built on top of, and takes great advantage of, CodeIgniter's built-in packages. This creates cleaner, more elegant code than WireDesignz'. The other reason I wanted to integrate and replace the core was so that we have the potential for even more advanced routing tricks, like filters, etc. Don't expect those items for 0.7.1, but the possibility is always there. Saying Farewell. And Hello In some ways it feels like this break is us saying "Good bye" to CodeIgniter and starting to fork it ourselves. Please understand, though, that this is not my intention. Instead, it's simply tweaking the core to give your code room, provide easier upgradability, and bring a little more fun back into your coding. Instead, think of this as saying "Hello" to a slightly more mature version of your favorite framework. Coming soon in version 0.7.1. [Less]

At long last - 0.7! After way too long, we're thrilled to bring you the 0.7 version of Bonfire. This one contains some of the largest changes that we've done to date and might prove challenging to upgrade 0.6 sites (and will definitely require some ... [More] time on your part, so be warned). Among the many changes are: New Bootstrap 2.x based theme in the admin area Passwords secured with phppass now for better security Site restructuring for even better security for web apps. Much more flexible and powerful MY_Model, adding Observer methods for easier customization, and moving data validation to the Model, where it belongs. Splitting of the MY_Controller into Base_Controller, Front_Controller and Admin_Controller that area autoloaded, leaving MY_Controller alone for you to customize for your site. Simpler, cleaner, front-end theme based on Bootstrap 2 New docs system in place to help you distribute docs within your application and modules. It's a bit basic at the moment, but that does mean that every download of 0.7 comes with all of the docs that we have and the docs are always up to date in the repo. Lots and lots bugfixes. We apologize that it took so long to get this point. I know that, for a number of you, we've probably caused you to lose a little faith in the project. For that, we are truly sorry. We are here, though, and there are some grand plans for the future that are already in the works. More information on that will be coming soon. Now Collecting Stats Just to make sure this is clear from the start - all installs of Bonfire 0.7 and later will report back some anonymous statistics about the environment you're installing in. We don't collect anything personal and are just collecting stats that help us to know what types of environments it's been installed in so that we can better support it and develop with those targets in mind. Also, there's times when the forums are quiet and you wonder if anyone is actually using this thing anymore. Then you hear about a developer who has built over 80 sites on it over the last 3 years. Or a hosting provider that built their user are on Bonfire. Things like that and you realize that we are making a difference in developer's lives here. And that's the whole reason that we do this anyway. So throw me a line at [email protected] and let me know how you're using Bonfire. I'd love to be able to add to the (single) testimonial that I currently have on the site and hear how it's impacted your lives and careers. What's Next for Bonfire? Now that 0.7 is in the wild, we can take some time to streamline the code and move portions of it that don't really need to be in every install into separate modules that can be easily dropped in through Composer. The goal here is to make Bonfire a simple, streamlined package that can be used for all of your development needs. Tentatively, here's the plans for the next few point releases: 0.7.1 - New, lighter, menu system and driver-based auth library. Work on both of these is already underway. Both will also be easily used in straight CodeIgniter projects. 0.7.2 - Better localization/language support and timezones 0.7.3 - still in the air... :) At some point during these releases we'll likely see Bonfire adopting a new modular code library that provides much enhanced routing support and treats module like the "packages" they are. Work has also begun on that, but it is still too early to say how long that will take. Oh, yeah! A New Website! Since 0.7 was such a huge change, and included the docs system, I had to rebuild the site from the ground up. This seemed like a great time to refresh the look of the site a touch also. There's still more work to be done, but we're getting there. This also gets us ready for some of the more exciting ideas I have in store for the community. Not just the Bonfire community, though definitely that, but the CodeIgniter community at large. And that's all I'm saying on that front for now. Enjoy the new release and, as always, please let us know if you run into any issues by reporting an issue or submitting a pull request with new changes. Thanks for sticking with us, everyone. Happy coding! [Less]

We just pushed a completely revised version of the installer to a new branch over at GitHub. We'd love to have you test the new installer just to help us verify if it works like we hope. Docs still need to be updated, but here's a quick overview: ... [More] From a fresh Bonfire install, you need to manually setup your Database config file (application/config/database.php). Once this is done, simply go to your site root. This brings up the file and folder write check, and compares PHP versions, etc. Click Next. Wait a few seconds while your database is populated. You're done. At this point, Bonfire installs a default admin user and will show you the email and password needed to login. You should change that before you go live. :) So please, download the latest code and give it an install in your typical system. If you run into problems, please let us know. [Less]

Work on the next release of Bonfire is well under way and we have some exciting things in the process. Today I want to highlight 3 of the largest changes that are being made since they will affect anyone who decides to work off of the latest develop ... [More] branch. Note that because of these changes, upgrading from earlier versions is difficult, at best. It is recommended that this version be used on new projects. New Folder Structure To better aid in security and ease of upgrading, we've implemented a completely re-arranged folder structure for Bonfire. It separates out the core Bonfire as much as CodeIgniter will let us, and keeps your application separate from Bonfire. This makes upgrading Bonfire in the future much simpler since it's all contained in its own folder. We've also moved the core, your application and modules out of the webroot for the enhanced security that comes with making your files harder to get to. It's a small thing, but we think it helps keep your apps even more secure in the long run, which is good for everyone. You can find the details over at the wiki. More secure passwords Keeping with the theme of security, we have moved the Auth library and all users to use phpass for the password encryption. This provides a much more difficult to hack password encryption scheme on a number of levels. Note that during an upgrade of a site, all users are set to have their passwords reset on their next login. The guts are in place on this, but we're actively working on the process for the user during the login to actually detect that it needs to be reset and prompts them to reset it. That should be in place shortly. Better Admin Theme While Bonfire has always looked alright, I've never been overly happy with the design. It never held that polish and shine of a pro app. We're getting ready to change all of that. After I made a comment asking if we had any designers in the house, Bogdan Lazar stepped forward and has graciously offered his help to come up with a new look for the Bonfire admin area. The goals are to create something clean and professional that is even more well-suited to putting a professional face on your web applications. We're just in the beginning stages of the design, but I am very excited about the possibilities. Keep an eye out for screen shots in the next few weeks. While you will see changes to the theme in the current develop branch, they are not the final theme. They were what I was working on when I got an offer from Bogdan to work with us so kindly ignore that for now. :) Smaller Things Cronjobs Work is nearly completed on a new Cronjobs module that allows your modules to easily create cronjobs that can be scheduled to run just like a typical Unix-style cronjob. Note that you'll still need to setup the full cronjob to run Bonfire's module, but that single cron will trigger all of your site's cronjobs, when necessary throughout the day. Besides being very flexible, this helps overcome restrictions on the number of cronjobs that can be ran by a number of hosts. More robust installer The installer has had a number of new checks added to it and made a little clearer and more usable. We know there's still more to do there, but we're getting closer. More thorough language support Many loose strings have been hunted down so the site can be even more localized. We also have a French translation in the works, now. Database independence work Much work has been made in removing any MySQL specific code to use CodeIgniter's ActiveRecord for more database independence. We have found some limitations in CodeIgniter's support for other database features. For Example, while the installer supports setting you up with a MySQLi driver, the driver doesn't support creating backups so that feature is now broken when this driver is used. We're looking at ways to get around this or even help CI upgrade their driver, but it's going to take a while. And more... Many bugfixes have been done and are being hunted down. Documentation is still getting written. Work is always continuing on the project, so if you'd like to get involved and help with either of those areas, we'd love to have your help! [Less]

As of today, all documentation for the 0.6 branch on will be hosted on the GitHub Wiki. Why are we doing this? Because we'd love to see more complete, accurate documentation, just like you would! There have been a couple users recently contribute ... [More] to documentation in our "old" repo and that is awesome. But we recognize that forcing you to download another repo, install PieCrust, make the changes, submit a pull request, then wait for us to integrate and push to the live site is... whew! a lot to go through. It is our belief that moving the documentation to the Wiki will allow any of our users to correct out-of-date information, add new pages, etc so that Bonfire's documentation can continue to grow and support the best CodeIgniter-based kickstart to your project around. Don't worry, though, this doesn't mean that we're going to stop contributing to the documentation. Instead, this makes things easier for us to do it, also. Future Releases We've also created a new folder within the wiki called 0.7 that, surprisingly enough, holds the revised documentation for the 0.7 branch, that is just getting started. When you add a feature, or modify an existing feature, and your pull-request has been approved and integrated, please help out by taking the time to update the 0.7 documentation. We are looking into simply providing the files as part of the repo, and would love to hear your thoughts on that. I think it might make getting pull-requests with documentation updates even simpler for everyone involved. What do you think? [Less]

It’s been a long slog to get here, with the team ebbing and flowing between busy jobs and new team members, but the Bonfire Team is thrilled to announce that version 0.6 is ready for the prime time. However, we couldn't have done it without the ... [More] awesome commits that have come in from the community as a whole. This project isn't just ours... it's building a tool we all can use to make our lives easier. And you all have done a fantastic job of helping to make that tool better. Thank you so much for everything. Ch-ch-ch-changes The new release brings a massive truck load of changes, both under the hood and visually. So let’s take a quick look at some of the bright new shinys that you’ll get to start your projects on now. When we started working on this release one theme seemed to keep coming back to us: If it’s going to be changed, let’s change it now and get it set the way we want it so that we have an awesome base to build on. We believe we’ve managed to do this and create a much more flexible, powerful base for your new applications. As we’ve built more apps based on the current code, changes keep getting made to make those projects not only possible, but a delight to work with. We hope you like it. Facelift Whlie the old UI of the admin area had it’s own type of charm, we felt it was time for something new. Something that had taken the development world by storm and was a library that has many of the things you need for a brilliant site already built in. Say Hello to Bootstrap. Twitter’s Bootstrap library has been used in both the default and admin themes, bringing a whole new look and feel to your apps. It’s something a bit more traditional-feeling than what used to be there. Moving to a whole new look does make upgrading your 0.5.x-based sites pretty tough, we realize that. But we think it’s worth it. Settings It used to be that a lot of settings existed in the application.php config file. While that worked for many instances, it was a bit of a pain when it came to securing your application and forcing you to keep the config file writeable. So we removed a number of those and put them into the database where they’re much easier to get to from the user’s view point. That meant that a new way to access your settings were needed. Enter $settings_lib. This new library is modeled after CodeIgniter’s Config library so you should feel right at home. Code Builder In previous versions we had the Module Builder. And it worked great to build a starting point for a new module very quickly. We realized, though, that it’s not enough. It could do more. This release features the first baby steps in expanding the possibilities and introduces a new Context Builder that makes creating a new context a very simple thing indeed. In future releases we plan on modularizing the Code Builder even more so that it’s easy to drop in new ‘Generators’ that plug right into the UI and can be used to build things we can only imagine right now. User Enhancements Users have seen a lot of attention this go around, and get a big boost in two main areas: registration and meta fields. When a new user signs up at your site, you can now require that they activate their account via either email or by having an administrator approve them. You can set the requirements for the strictness of user’s passwords right in the settings page. Built into the user_model, you can now store and retrieve custom fields for users, like address, phone number, shirt size, or whether they think Hans shot first. Translation Utility We know that Bonfire is used around the world and have had a number of users do partial translations in the past. Unfortunately, the rate of change makes that difficult for volunteer translators to keep up with. So, we thought we’d make things a bit easier for you and built a translations UI that makes it simple to translate every string in every module (including your own modules!). You can even export them for other users or just for a backup. But wait, that’s not all! This short list highlights the major changes to the app, but doesn’t come close to telling everything. There’s been many small bug-fixes and improvements, a slew of security enhancements, and little helpful methods scattered throughout the libraries that make them a bit easier to use in your own code. We’re thrilled to be able to release this today and get it in your hands. I can’t wait to see what you are going to create with this! (When you do, drop us a line. We’d love to post an short interview with you about it.) What are you waiting for? Grab your copy today and get building. [Less]

This is the first in a new series of articles showcasing sites that have been built with Bonfire as the base. In this case, Project Simply built the site based on Bonfire 0.5 and did a fabulous job creating a beautiful site. If you have a site that ... [More] you'd like to have showcased, please email Lonnie at [email protected]. Tell us a little bit about the team that built Eposure.com. We're a small, boutique agency in sunny Manchester, UK called Project Simply. As lead developer, I was itching to get stuck in to Bonfire since finding out about it, and was looking for a suitable web application project to use it. I've been using Codeigniter for years, but inevitably drift into open source (Wordpress, Magento) for most of our projects as they suit a more standard site. The core of the application was built in its entirety by just me (phew), which is not ideal, but time frames allowed for this to be the case. We had different front end devs and designers involved, but when building applications it's always better to tag team the back end, at least. Spot each other's mistakes, and the like. Can you describe the application in general? Exposure is a place for photographers to easily present their portfolios and CVs to the world. It's aimed a connecting freelance photographers with creative professionals such as art directors who need to employ someone for a specific task. What are the goals of the site and the main audience? The crux of the site revolves around the search facility, allowing creative professionals to easily find nearby photographers within a specific niche. This way the most ideal person can be found for a specific job, as quickly as possible. The secondary purpose is to create a glitzy portfolio page for the members, with an attractive gallery to view photographs. It also needed to be super simple to use for photographers without a deep knowledge of computers. What made you decide to use Bonfire for this? I've been looking for an HMVC framework that sets me up with an admin area and secure user system for a long time. There's obviously a heap of them out there, but it was also key to find a framework that remained flexible and liberal. I can't stand it when it feels as though the framework is restricting me, and with Bonfire I found a system that would give me everything I needed, but never seemed to get in the way. Well, almost never! What were some of the pleasure-points and pain-points when using Bonfire for this type of site? The module builder is great. I feel almost like I'm cheating, using PHP and having something generated like that! At first I thought this would be restrictive, but once again, after the module builder did its business it was marvellously simple to amend or simply ignore the way it generated code, and do my own thing around it. The extended model class in particular gives me much joy, using find, update & insert functions without having to write anything. Terrific. Pain points? I'd say I have grief with the standard admin layout. I'd much prefer a less awkward, more 'blank canvas' style to the system. Using boiler plate, for example. Something that is plain and doesn't need editing, but can easily be modified, just like the module builder. Any general tips for Bonfire users you learned on this project that you'd like to share? Work out exactly what the module builder is doing. Take a look at the extended classes in the core folder, and see what MY_Model is making for you. I know I didn't quite use everything to its full potential here, as I didn't read through thoroughly until I'd already got going. Most db interactions are covered here, it really leans up your code. Any thing else you'd like to share? Ooh, the activities monitor is great, and so useful for keeping track of users. It's so easy to implement too. The reporting is a bit poor though, and a simpler way to navigate by date, and do a csv export would be on my list of improvements. I know for eposure they already have thousands of pages of activities reported, and an export of this is on my list of improvements for them. Hey, I should probably stop moaning and offer to help you out with this? What lessons did you learn during this project? Going back to my point about tag teaming- single handedly backend devving an application like this is a bad move. Sure, I got there in the end, but the amount of time wasting bug hunting or problem solving is just not good enough, when a fresh pair of eyes tends to spot what's going on straight away. Also, I learnt that they Paypal API docs are the biggest steaming pile of crap I've ever encountered. What's up next for you and your team? We have a heap of sites being developed at the moment, and we're just finishing off an image manager/ repository for a client, built once again with Bonfire. [Less]