The New Myth family: SprintPHP Bonfire Practical CodeIgniter 3

New Myth Media Blog

Serving the New Myth Media Family.

Practical CodeIgniter 3 Released

My new book about making the most of CodeIgniter 3 is out!

Posts Filed Under “News”

First off, for those of you that haven't heard, work has begun on the next major version of Bonfire, called Bonfire Next. It's a complete, ground-up rewrite that thinks about things quite differently than the previous version. With any luck, though, it will be even easier to use than the current version, and yet much more powerful.

Why Next?

I had gotten where I didn't even use Bonfire as a starting point for the last few projects I did. There were a few little quirks that annoyed me too much - the way Contexts worked being one of the big ones. Plus, I wanted it to be more integrated with Composer and the rest of the PHP world that's going on right now. Instead of writing CodeIgniter applications, I wanted it to be more likely writing applications that just happened to use CodeIgniter as the primary framework. I say primary, because with all of the high-quality code available and easy to install and update through Composer, we're kicking ourselves in the foot by limiting ourselves.

Where Are We Now?

Honestly, we're really just getting started, but here's a quick overview of what's in place, though it all needs more refinement and completion.

CodeIgniter 3 Out of the Box

This is all based on constantly updated version of CodeIgniter 3, which is nearing it's release date, if the issues over at GitHub are any indication. Still with HMVC Modular Extensions, of course. Though it's having to be tweaked slightly to work with CI 3, it seems. No worries - we'll get there!

For those wishing there was a nightly version of the docs: yeah, so was I. So I made one. Head on over to our hosted nightlies of CodeIgniter 3 Documentation.

Template-Engine Interface

I know that everyone has different opinions about what makes a great template engine, so I knew I wanted people to be able to easily integrate their own engines for the frontend. A very simple interface was created and the Plates Template Engine has been integrated. It's working great. It's should be easy enough to create a simple class that implementst the TemplateInterface and you could integrate Dwoo, Twig, or your very own best-of-breed, lighter-than-air template engine.

I'm not going to promise that Plates will stay as the default engine. I have some ideas that may require me to do something different here. More about that below.

Asset Pipeline

After trying out a few of the other solutions out there, I was unable to find anything quite like I wanted. So I built a simple one. This is very similar in nature to Rails' Asset Pipeline though not identical. Basically, it allows you to store your files in any path and then be able to serve them up dynamically or build them out to a static file for faster processing. You can specify exactly which files to combine together into a single file for better front-end performance, and exactly how that type of file should be processed. Should we compress the combined CSS files? Minify it? Fix the URLs? Combine the images into sprites? Resize images on the fly? You get the idea. It's all about front-end performance, here, and usability for the backend dev. Any modules can have their own assets that you can combine with the rest without moving things around.

This is working, but more filters need to be written out and another advanced feature or two put in place.

Updated Docs System

The docs system is getting huge overhaul in both appearance and power. I'm thrilled with how it's going so far.

Bonfire Next Docs

I think it looks 100% better than the old docs, already, and we've added a few bonuses for even better usage.

  • Auto Document Maps - Document Maps will analyze the Markdown file and pull out any h2 and h3 tags to build a list of links to within this document. You see an example on the right-hand side of the page in the image above.
  • TOC Ordering - the Table of Contents is still built from an ini file, but we will now automatically flow the links into columns, keeping them as even as possible without splitting the groups up.
  • Infinite Groups - Before, you had either application docs or bonfire docs. That's been tweaked to allow you to specify any number of groups to organize it however you want. I'm currently working on allowing the ini files to include tags that will be replaced with the correct path from other locations, like modules, etc, so you have even more control over the documentation you present to your users.

What's Down the Road?

Obviously, the big picture is to get us back to the functionality we currently have, or at least something close. I will warn you that not everything is going to make the cut and be part of the core package. They will, however, be simply to install and use if you need it.

Here's some of my big-picture thoughts, though I make no guarantees about what features make it into it.

  • Site Building - This is definitely my big goal with this project. Many pages in our applications don't need to be generated dynamically all of the time, and that's a waste of resources. I'm picturing the ability to tell it to build your site and it will generate static HTML files for you. Of course, you'll have full control over what's static and what's dynamic. You should be able to tell it to make all of page X static, but keep these couple of sections dynamic, and have it convert those to an AJAX call to update that section. This isn't caching, but truly creating HTML files to be served. You can't get an better performance than that. This is also why I might need to do a custom template engine.
  • Customizable Code Generator - I want to expand the current module builder out into something that's standalone and can be used by anyone, anywhere. It will be integrated into Bonfire as needed, of course, to keep it part of the system. This would allow you to customize your own versions of how things your files are built. Customize your Models to be setup just like you want them everytime. Build out forms and views that use the CSS framework of your choice. All with an elegant GUI. I'm hoping this puts our current stuff to shame.
  • Route Filters - Of course, we owe Laravel for this idea. Awesome feature, though.
  • Assets from Anywhere - The Asset Pipeline already makes use Flysystem for it's file-handling. I would love to implement a way to pull assets from anywhere, like an Amazon S3 account, Dropbox, or even an FTP site. These would be pulled together into the final static file.

If you've got ideas of your own, or thoughts on these, please comment below!

As I announced a little while back, some new module code was being tested and some custom Router and Loader classes put in place that would replace the previous HMVC functionality. That code was just pushed to the develop branch and is now officially part of the project.

This also means that a few miscellaneous changes happen throughout the project, including:

  • Separated all Bonfire code from your Application's code.
  • Most bonfire specific code now uses a BF_ prefix instead of the MY_ prefix your application would use.
  • The module_* methods in the application_helper file have been moved to the Modules class. The application_helper methods are still there but are considered deprecated.

I believe those are the biggest things that you'll notice. If I missed anything, feel free to call me on it.

The next two things on my plate are a revised docs system that's a bit more powerful, slightly different theming, and maybe, just maybe, some basic search capabilities. Also coming next is the new menu system that's been hinted at. I'll write another post in the next day or two to explain why the menu system needs to be redone and why Contexts were not quite as great as I originally imagined them to be.

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, 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.