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.
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.
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.
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.
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
h3tags 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
bonfiredocs. 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
buildyour 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!