Last month I released “Pope Michael” for free online (you can see it here). It’s a testament to the level of technology that the web has risen to over the past four years for me to embed my entire documentary in HD right here below this paragraph:

It’s on YouTube and Vimeo which makes it available to pretty much any smart TV, smart phone, computer, or internet device around. The technology really is incredible. It’s free because I wanted people to see it with as few barriers to them clicking “play” as possible.

One question I’ve sometimes had is why didn’t “Pope Michael” premiere at any film festivals? The honest answer is that I was rejected from all of them! Embarrassing to admit, yes, but true. It wasn’t for lack of trying either – “Pope Michael” was rejected from 14 different film festivals from Sundance to Full Frame to the West Palm Beach Film Festival – right across the board.

I’m not exactly sure why it never won any favor with the powers that be in the film festival world, but I can’t help but doubt that it was because “Pope Michael” was lacking in originality. It’s never fun getting rejection letters (or emails), but it didn’t play a role in my lessening desire to make documentaries or the decision to put “Pope Michael” up online – those two things would’ve happened either way. Film festivals are competitive and although I wish “Pope Michael” premiered at one, I’d rather let the people who want to see it see it than hold out for a spot.

I learned a lot during the process of making “Pope Michael”. Probably the biggest lesson I figured out is that making documentaries is ultimately not what I’m interested in, although I continue to love watching them.

Even if it’s not what I’m ultimately interested in doing, the journey of making “Pope Michael” was well worth it in the end. I’ll never forget showing up at Bawden’s house one morning in October early enough to get a shot of snow falling on the grounds, or stopping at Cici’s Pizza on the way to the KU presentation, or immediately finding my iPhone after Tiki convened a group prayer to Saint Anthony after I told her I couldn’t find it. I owe a lot to my brother Derek, Doug Klinger, Michelle, and Andy Burd. I also owe a lot to many more people who were incredibly supportive of me taking time away from life to travel deep into the Kansas countryside.

I also owe a lot to my Poppa, who funded a good portion of “Pope Michael” and never got to see a frame of it. I think he’d like it.

Finally, probably the best thing to come out of the “Pope Michael” project has been my brother’s amazing soundtrack. He came up with something really incredible. We put it up on iTunes – I highly recommend you check it out.

- Adam

So, if you happen to develop add-ons for PyroCMS, you’ll need to do a little bit of work to make sure your shit don’t break. Here are some tips to get your stuff working on PyroCMS 2 in no time.

A Word on Standards

With PyroCMS, I’ve thrown my hat into the ring to try and nail down some standards about how UI conventions should be used. You can find the running document here. Some of them are common sense, but I highly recommend following these as much as you can to create a smooth UI experience across modules. If you have any questions, let me know on Twitter.

The New Interface

PyroCMS 0.x used an off the shelf admin interface, and then 1.x used an interface that was apparently designed by Dan Horrigan. I’m not even going to ask how that happened. Anyways, it was fine, but it had a vertical nav system that is so 2004 and took up too much screen real estate.

Luckily, the man behind the design of the PyroCMS and FuelPHP websites, Scott Parry, has undertaken getting an admin interface going. It’s really fantastic. Based off of his Workless framework, the new interface is colorful, flexible, and easy to implement.

Upgrading to the new interface is pretty easy, so let’s start with your view code. Here’s a quick comparison of a typical page:

// PyroCMS 1.3.x and below:

<h3>Your Title</h3>

<table>
// Table Content Here
</table>

// PyroCMS 1.4

<section class="title">
<h4>Your Title</h4>
</section>

<section class="item">
<table>
// Table Content Here
</table>
</section>

If you are not familiar, that is the HTML5 section tag that we are rocking. Yes, it is more markup, but it allows you to easily define a box of content on the backend – header and body.

The new interace is made up of these blocks, and beyond that, almost all of your current view code should work, including tables and other basic markup.

Buttons

We get to have some fun with buttons in PyroCMS 2. Workless comes with some shiny buttons that make the interface a little more fun. They come in two varieties: primary and secondary. Primary buttons take a class of “btn” and can have a color as a class (red, blue, gray, orange, green). So, for example:

<button class="btn blue">Save</button>

Luckily, PyroCMS has a button partial that you can pass data to, and it color codes the buttons by their function. So, if you are using the button partial, your Save, Delete, etc. buttons should already be upgraded. If not, get your head in the game. Secondary buttons are smaller and used for lists and other places where flashy buttons would be a distraction. These take a class of “button” and do not come in colors. If you are using the button partial and it is defaulting to the large ones, simply add a new param to get the secondary buttons:

<?php $this->load->view('admin/partials/buttons', array('button_type'=>'secondary', 'buttons' => array('edit' => array('id' => '../instances/edit/' . $widget->id), 'delete')) ); ?>

It defaults to primary, so don’t worry about it if you want the primary buttons.

Sections and Shortcuts

The interface in PyroCMS 1.3 was made for simple modules, like “Redirects”, which is essentially a GUI crud for a DB table. If you want more functionality for sections of admin content within a module, you needed to roll your own solution. I did that for PyroStreams with a special level of nav that defined a “Fields” and “Streams” section. In PyroCMS 2, you can define “sections” in your details.php file. Here is an example:

<?php defined('BASEPATH') or exit('No direct script access allowed');

class Module_Sample extends Module {

	public $version = '1.0';

	public function info()
	{
		return array(
			'name' => array(
				'en' => 'Sample',
			),
			'description' => array(
				'en' => 'Only the samplest.'
			),
			'frontend'	=> TRUE,
			'backend'	=> TRUE,
			'skip_xss'	=> TRUE,
			'menu'		=> 'content',

			'roles' => array(
				'admin_module'
			),

			'sections' => array(
			    'dogs' => array(
				    'name' => 'sample_dogs',
				    'uri' => 'admin/sample',
				    'shortcuts' => array(
						array(
					 	   'name' => 'sample_new_dog',
						    'uri' => 'admin/sample/create',
						),
					),
				),
			    'cats' => array(
				    'name' => 'sample_cats',
				    'uri' => 'admin/sample/cats',
				    'shortcuts' => array(
						array(
						    'name' => 'cats_new_cat',
						    'uri' => 'admin/sample/cats/create',
						),
				    ),
			    ),
		    ),
		);
	}

}

/* End of file details.php */

This way, you can easily separate your modules into different sections, and the interface will respond in kind:

The best way to integrate this is to separate your module into separate admin controllers. The admin.php controller, and another controller for each section. For the blog module, it would be admin_categories.php for the categories section.

PyroCMS knows what section you are in by reading a class variable in the section controller:

protected $section = 'categories';

Add one to each of your section controllers, and you are on your way.

Shortcuts

You might notice in the example above, that shortcuts are part of this array as well. In PyroCMS 2, shortcuts are no longer a partial – you add them to your details.php file. See the example above for the specifics.

For modules that do not have sections, the shortcuts section of the array is on the same leve with the ‘name’ and ‘description’ nodes.

Filtering Data

Many core PyroCMS modules us data filtering (such as the blog module), and yours may too. In PyroCMS 2, filtering is not handled by a partial – you need to add it to your views. Take the example of the blog filtering:

<fieldset id="filters">
	
	<legend><?php echo lang('global:filters'); ?></legend>
	
	<?php echo form_open(); ?>

	<?php echo form_hidden('f_module', $module_details['slug']); ?>
		<ul>  
			<li>
        		<?php echo lang('blog_status_label', 'f_status'); ?>
        		<?php echo form_dropdown('f_status', array(0 => lang('global:select-all'), 'draft'=>lang('blog_draft_label'), 'live'=>lang('blog_live_label'))); ?>
    		</li>
		
			<li>
        		<?php echo lang('blog_category_label', 'f_category'); ?>
        		<?php echo form_dropdown('f_category', array(0 => lang('global:select-all')) + $categories); ?>
    		</li>
			
			<li><?php echo form_input('f_keywords'); ?></li>
			<li><?php echo anchor(current_url() . '#', lang('buttons.cancel'), 'class="cancel"'); ?></li>
		</ul>
	<?php echo form_close(); ?>
</fieldset>

Simply define a fieldset with the id of “filters” with a legend tag, and you can put a UL of params in there with your filtering options. Filtering should take place at the table-level, meaning that when a filter is applied, the table is changed, not the entire block of content. You can wrap your table (or other element you want filtered) in a div with an id of “filter-stage”:

<div id="filter-stage">

Misc Items

- A new feature in PyroCMS 2allows action buttons on tables (such as a mass “Delete” function) to stay inactive until a user does something that would enable data to be acted upon (ie: checking a box). To enable this, just wrap your buttons in a div with a class of “table_action_buttons”.

- As with PyroCMS 1.3.2, $this->user is deprecated in favor of $this->current_user.

- To float buttons to the right in an action table column, give it a class of “actions”.

Tags

The one piece of the pie not yet in place is the new tag system, which is being rewritten. I’ve leave it to Phil Sturgeon to update the troops on that one, but you can follow the progress on the new tag parser library (called “Lex”) here.

Go Forth and Update

PyroCMS 2 is going to be a huge leap forward. Clients will love it, and it offers a lot more in terms of flexibility and style for Add-on developers. If you have any questions, comment below or ask in the PyroCMS forums.

CICON2011 was last weekend in NYC, and I had a lot of fun. In March, I told Phil Sturgeon I’d love to help out if he needed it, and I ended up getting to be part of the three man crew (me, Phil, and Kenny Katzgrau) who put together the event.

It was the first of it’s kind in the US, and I believe a hugely significant point for the CodeIgniter community as a whole, so I thought I’d get down my thoughts on the whole affair. Here we go!

It signaled a change in community/Ellislab relations

In my opinion, CICON in NYC was a huge milestone for the relationship and communication between the CodeIgniter community and Ellislab. Why? Ellislab was the premiere sponsor of CICON and their logo was all over the place, but right from the start the message was clear: CodeIgniter is driven by us.

The first announcement on Saturday was that CodeIgniter has moved to Github, and Reactor is now CodeIgniter. If you are used to things on Github and yawn at the news, you’re suppressing several years of CodeIgniter memory where sending a pull request was not even possible, let alone so easy and in such a central and visible place. For many, CI in the past was open source, but you couldn’t touch it or contribute to it.

So, having Ellislab fully behind an event where a contest was held over the two day period to see who could make the most/best pull requests to CI is a huge sea change in the way Ellislab and the community interact, and a big leap forward.

(As a side note I think it’s a relationship that worked and felt natural: EllisLab showed their support in a substantial way, but everything else was planned, executed, and set up by the community.)

The line where CI ends is blurry

I realized something a few hours into Saturday at CICON – many presentations, although informative, weren’t just about CodeIgniter. Kenny’s talk about stack optimization, Calvin’s talk about payment gateways, and even John Crepezzi’s talk about writing friendly libraries could conceivably be at home at several development conferences if you made some changes.

I’m not saying these presentations were not great or valuable. Just the opposite, they were great. I’m baffled by payment gateways, for instance, so Calvin’s talk on them was extremely valuable, as well as thorough and original. However, it says something about the way we use CodeIgniter. CI is so flexible and light that we often simply find ourselves talking about something else entirely without realizing it. In the same way CI doesn’t get in the way, we do not generally get bogged down in the constructs that our framework places on us – we build on top of it because CI works with us.

In other words, we were all there because of the tool we use, but we were not all there to figure out how to use it.

Above: Phil giving the opening talk on Saturday.

We walked away with a shared mission

There was a great moment on Saturday where we were running well short of our schedule, and Phil asked Greg Aker to see if he could fill a gap with some group discussion. Greg was willing, and after some warm up time eventually got a huge group discussion going about where CI was going, and what was next. Kenny was taking minutes, and soon we had a really good list going.

If everyone walked away with just one thing, I think group discussions like this one created a shared sense ownership of where CI is headed. That’s something new, and something that will help keep the CI community going.

CICON was a true community effort, and it showed

This may seem self-evident, but developers are not really the same type of people who excel at event planning. That being said, we stepped out of our element to try and provide all the things that a cool conference should have: a great venue, a great location, food, working A/V equipment, lanyards, fun t-shirts, a bar to go to after, etc.

Throughout the process, the community really stepped up to help. Ellislab was our main sponsor and additionally provided the resources to send Greg Aker (who was critical to the success of the conference). PHP Fog, Mindfulware, and Conflux Group generously sponsored. Whooz! (the people behind the very successful EECI conferences) not only sponsored but provided the design elements and web design for the conference. Although we put together the swag and other materials, their work on the design and look/feel saved us a lot of time and energy.

The last piece of the puzzle was the most important: the attendees. Everyone brought their enthusiasm, and as a result, we had a fantastic group of people who allowed us to go with the flow, improvise when we needed to, and hopefully create an environment that led to the important community milestone that CICON was.

CI has a bright future ahead of it.

PS: My offer still stands to pay Greg Aker $20 to merge in my echo helper pull request.

Since I wrote this blog post, there have been some new developments. First of all, the PyroCMS releases after 1.3.2 will fix the bug mentioned below. Secondly, I’ve released an add-on that makes it easier to manage your custom routes, called PyroRoutes. You can download it for free here.

There has been a lot of questions on the PyroStreams forum about one subject in particular – showing dynamic info on its own page – so what follows is a guide on how to do that. Once the new Addict site is up (which has a blog), I’ll cross-post this over there.

One note – I am using PyroStreams 2 beta syntax here with the {entries} tag inside of the cycle plugin. If you are using PyroStreams 1, please adjust accordingly. If you are using 2 beta, please update to the latest version (uploaded today at 6pm EST), as it contains fixes to the single function.

Alright, let’s get started!

Pages in PyroCMS

First a little note on the relationship between pages and streams. When you create a stream, there is nothing created in the page system that tells PyroCMS to do anything but to create that stream and populate it with data. The display is up to you, which means that it is very flexible, but some things require a little bit of elbow grease.

If you’ve used ExpressionEngine before, you know that you can create a URL and EE will show you anything but a 404 (unless you have strict URLs turned on, and they are turned off by default). That means if you have a template group called products and a template inside of it called product, you could do products/product/sample-product or products/product/sample-product/features all you want. EE doesn’t really care about the URL as long as it can find something to show.

PyroCMS cares about your URL. If you give it the URL products/product/4, It is going to look for a page in your page tree called products/product/4 and try and load that page. The trick is you need to tell PyroCMS to ignore certain segments in your URL, so it will load a base page (in this case products/product-page). On that page, we’ll pay attention to what’s in the URL, and display an entry based on that.

If you are confused, don’t worry! It’s easy – below is an example.

Building a Simple Products Directory

So if you are listing products on a page, you pretty much can tell how that goes. You create a “Products” page:

In the page layout (let’s called it “Product Listing”) associated with that page (under the “Design” tab), you run through code that grabs your products:

{pyro:streams:cycle stream="products"}

<a href="products/product/{id}">{name}</a>

{/pyro:streams:cycle}

Easy enough! We are dynamically creating links to products by id. (Keep in mind, this could be a slug or something else you want to use, but for this example we’ll use IDs since every post has them.)

Now, we need to create a Product page as a child page of Products. This page has a URI of products/product-page. We can create a separate page layout for that as well. In this example we’ll call it “Product”.

Now, if we go to our product listing, and click on a product, we get a 404, because PyroCMS is looking for a page called 2 (if the id is 2) that is a child page of Product. That doesn’t exist in our pages tree, so we need to add a route.

If you are not familiar with routes, they are a CodeIgniter thing, and they are located in system/pyrocms/config/routes.php. It is a simple array that has a standard format:

$route['uri to route'] = 'uri to route to';

You can also use :any and :num to signify anything in a URI segment and a number in the URI segment, respectively.

You might ask “what are we routing to”? The answer is the view function in the pages module. So our route is going to look like this:

$route['products/product/:any'] = 'pages/view/products/product-page';

What we are doing is saying that when PyroCMS encounters a URI with products/product/, and anything in the third segment (our id, slug, whatever), it will load up products/product-page. Notice that we don’t use any routing variables like $1 because we don’t want to pass dynamic info to the root value – we just want PyroCMS to ignore some segments.

Bypassing a Bug

I will add a pull request for this ASAP, but doing this throws an error in PyroCMS 1.2 and above. This is because of a bug (what I think is a bug anyways) in the pages module. Luckily, the fix is really easy. Go to system/pyrocms/modules/pages/controllers/pages.php and change line 43 to:

$url_segments = $this->uri->total_rsegments() > 0 ? array_slice($this->uri->rsegment_array(), 2) : null;

That’s it! You should be set to go now.

Displaying Dynamic Data

No you should be able to click on any one of your product links, and you won’t get a 404. Awesome! Now we just need to display some dynamic data.

You can use the cycle plugin if you want but we have a simplified function called single in PyroStreams 2 that you can use. It basically just eliminates the need to use “entries” and limit 1 and all that stuff. So in our Product page layout, we have this code:

{pyro:streams:single stream="products" id="[segment_3]"}

<h1>{name}</h1>

{/pyro:streams:single}

Simple as that – we can tell it to grab the ID using our (PyroStreams 2 only) segment variables. Using the cycle plugin you can do:

{pyro:streams:cycle stream="products" where="id==seg_3" limit="1"}

{entries}

<h1>{name}</h1>

{/entries}

{/pyro:streams:cycle}​

That should cover it! I’ll be posting some more how-to’s here on PyroStreams just as soon as I get the last damn bits of PyroStreams 2 finished!

Good thing Rob caught that because I can’t find any mention of it in the change log or the docs, and this thing is awesome. Why? We finally have direct control over the EE CP menu system.

A Brief Recent History of Messing with the CP Menu

First, a little overview of where we’ve been in recent history of the menu.

In EE2, menus on a bookmarks model. A common example is you’ve got an install of Structure and you want to just have a link to go to the structure area so you don’t have to go through the Add-ons -> Modules menu. You click the little +Add link on the top and you can add it as a custom-named link on the top.

This is great except that you’ll notice the controls for editing the name and order of these bookmarks are in your account section. IE, this bookmark is just for you, so that makes managing the experience for clients a lot harder. Make a new account for a client, and you need to add in these bookmarks if you want them to have that easy access.

If you wanted to extend the menu, you could use the cp_js_end hook and then used JS to add items to the menu using the DOM. This was fine, but messing around with adding/removing items with JS wasn’t an ideal solution. There is already an array with the items in there – just give us access!

The Keys to the … Array

So here comes cp_menu_array and basically EE is saying “here, take the entire menu array and have fun with it. Go nuts, really. Just give it back when you’re done.”

Awe. Some. This is that next level menu customization. Let’s have fun with it.

To play, you are going to need to use an extension. If you aren’t familiar with extensions, check out the EE docs on the matter. They are basically just functions that you can run at predetermined times in EE’s code.

Let’s look at the extension info in the activate_extension function:

public function activate_extension()
	{
		$this->settings = array();

		$data = array(
			'class'	=> __CLASS__,
			'method'	=> 'build_custom_menu',
			'hook'	=> 'cp_menu_array',
			'settings'	=> serialize($this->settings),
			'version'	=> $this->version,
			'enabled'	=> 'y'
		);

		$this->EE->db->insert('extensions', $data);
	}

Nothing surprising here. Just basically creating a regular extension, and we are saying we want to call the build_custom_menu function when EE gets around the to cp_menu_array hook.

Now, the fun part, our build_custom_menu function. This is actually really simple. The function just takes an array and expects you to give an array back. Here’s what a section looks like:

    [content] => Array
        (
            [publish] => Array
                (
                    [Pages] => index.php?S={string}&D=cp&C=content_publish
&M=entry_form&channel_id=2
                    [Schools] => index.php?S={string}&D=cp&C=content_publish
&M=entry_form&channel_id=1
                )

            [edit] => index.php?S={string}&D=cp&C=content_edit
            [files] => Array
                (
                    [file_manager] => index.php?S={string}&D=cp&C=content_files
                    [0] => ----
                    [file_upload_preferences] => index.php?S={string}&D=cp
&C=content_files&M=file_upload_preferences
                    [file_watermark_preferences] => index.php?S={string}&D=cp
&C=content_files&M=watermark_preferences
                )

            [0] => ----
            [overview] => index.php?S={string}&D=cp&C=content
        )

The root key of the array is the content menu item we are all familiar with, with the publish sub-menu item underneath it. Pretty straight forward. Each array item can be a string or array, and the array is another sub menu.

Example: Page Structure Link

Let’s try a simple example. We want to add a link under “Content” that says “Page Structure” and links to our Structure module. Here is our build_custom_menu function:

public function build_custom_menu($menu)
{
	$menu['content']['pages'] = BASE.AMP.'C=addons_modules'.AMP.'M=
show_module_cp'.AMP.'module=structure';

	return $menu;
}

We are simple adding our own item to the ‘content’ array inside of the $menu array and giving it a value of the link to the structure module.

Instead of naming the key “Page Structure” we need to keep than name in a language file and prefix it with ‘nav_’. So, inside language/english/custom_menu_lang.php we’d need this item in the $lang array:

'nav_pages' => 'Page Structure'

Now, we’ve got a sweet custom menu item!

Obeying Member Permissions

Okay so this looks awesome but remember that not everyone can access the Structure module so we shouldn’t tease them and show them what they could have if they were cool enough.

The solution to this is pretty simple: just do some checking for your particular menu item. Here is the user check from our example:

public function build_custom_menu($menu)
{
	$assigned = $this->EE->session->userdata('assigned_modules');

	if(
		$this->EE->cp->allowed_group('can_access_modules') and
		(
			$this->EE->session->userdata('group_id') == 1 or
			(isset($assigned[15]) and $assigned[15] == 'yes')
		 )
	) {

	$menu['content']['pages'] = BASE.AMP.'C=addons_modules'.AMP
.'M=show_module_cp'.AMP.'module=structure';

	}

	return $menu;
}

Above, we are checking that the user can access modules, and at they can access the Structure module. We need to check this by the module ID in the ‘assigned_modules’ userdata item., which kind of sucks because this can change from install to install, so its best to get the module ID by the name and use that.

Other Functions

To remove an item, just unset that part of the array:

unset($menu['content']['overview']);

To add a menu break, add an array value of four dashes (—-).

$menu['content'][] = '----';

Go Nuts!

This gives add-on developers and site developers a really fine grain of control over how menus are structured. Modules can also now add an extension that adds custom menu items. You can control your client experience down to a fine grain, and that’s good for everyone.

Fizl’s main goal is to be simple while still having the ability to create some cool, functional stuff. At its core is the idea to build your site with HTML files in the filesystem. No logins, databases, or anything else needed. You can also embed pieces of content, write your content in markdown or textile, template content, show tweets, easily write navigation menus with a shorthand, list files, write and use configs, and more. It uses a simple tag-based system to allow for plugin functionality. You can also easily extend Fizl with your own plugins.

Fizl is open source, so you can download it and check out all the docs on this mini-site. If you have built something with it, I’d love to check it out!

Aside from some little things here and there for the website and getting to talk to the awesome people at Ellislab, I volunteered to make a video to promote CICON with interviews from other CI developers and CI community members. Check it out below:

First a side note for people into video: if you are going to do interviews via Skype, do some tests first. The video was recorded with iShowU, and when the audio didn’t want to work (which was 90% of the time), the audio was recorded with Audio Hijack Pro (also our jam for the FilmedInsert podcast). Due to my stupidity, I found myself spending hours and hours synching audio and running video through export processes (thank you MPEG Streamclip) to get it all to work. FCP did some things I’ve never seen it do before, but I eventually got it all to work.

Anyways, it was really cool to talk to everyone, and the whole process reminded me why I love being a CodeIgniter developer – CI people are really nice/fun people. I had some experience before from interviewing people during EECI2009 in San Francisco, but it was neat to get people in their natural habitat (at a computer) and get an idea of where they are coming from as developers and why they are a part of the CI community.

The idea of this first video is to get you fired up about CICON. I think it’s really interesting to see that for even the guys at the top of the stack, CI really shaped the way they developed and was an important moment in their development history. I know it was for me, so it was really fun to see how many parallels existed between everyone when editing it together to tell a story. This was actually a relatively easy edit once the technical challenges were dealt with – people even finished each other’s sentences.

If you are a fan of CI, you probably recognize the man who appears first in the video – Rick Ellis. Ellis created CodeIgniter originally, and I thought it was a fitting intro to start with an “origin story” where a few months at the end of the year turned into something much bigger. You can tell when Rick says “and then I released it…” he is trying pretty hard not to say “…and guess how that turned out, BIATCH”.

The bottom line is – if you are a CodeIgniter developer, seriously consider making it out to NYC or London for CICON2011. The talks are going to be fantastic, and if you couldn’t tell from this video, the people that are going to be there are a great group to argue over if CI should have a cart class with.

Watch out for some more videos for CICON coming up soon! There was a lot of video material, so we will release some more videos on different subjects coming up.

I started using CodeIgniter in January 2008, and it was a huge milestone in my development education. It showed me new ways to build, and I’d never be making the things I am today if it wasn’t for CI. I still love it and I still use it – it is getting better every day via Reactor, and it has a bright future.

That being said, PHP has changed a lot since CodeIgniter’s core was developed. A few months ago, some stuff happened and Dan Horrigan decided to create FuelPHP – a framework loosely in the tradition of CodeIgniter, but built to take advantage of the bells and whistles of PHP 5.3+.

I decided to really delve into FuelPHP over the weekend and found a lot of things that I really love and a lot of things that were really different in both syntax and method to what was done with CodeIgniter. So, coming from a tried and true CI guy, here are some observations of what to look out for when using FuelPHP.

Note: This isn’t meant to win people over to FuelPHP or espouse the virtues of switching, but it is meant as an overview of some major changes in thinking/structure for CI developers looking to use FuelPHP.

A Class is a Class

In CodeIgniter you have models, controllers, and libraries. You may notice that these are all regular old PHP classes, they are just treated differently by CI.

In FuelPHP, everything that is a class goes in the ‘classes’ folder. Controllers go in a ‘controller’ sub folder and models go in a ‘model’ sub folder. There are no libraries – they are just all classes and they all hang out in the classes folder. It’s a small change, but it may throw you off if you are used to having your controllers, models, and libraries lead separate lives.

PS: There are no helpers. They were dumb anyways. Which reminds me…

There are no Helpers

Most functionality that you’d find in helpers in CI is in classes in Fuel. You can still find old, completely useless friends like br() in the HTML class. What that’s you say? You use helpers for literally everything, even the simplest of tasks? Well, Fuel has an h tag function. Shit just got real.

Get Ready for Static Methods and Properties

You can use CI for years and never come across the concept of static methods and properties aside from defining parent classes for models/controllers. That’s mainly because in CodeIgniter, you were essentially dealing with a super object instance so everything uses the $this context in one way or another. That’s why if you wanted to “tap into” CI’s functionality in a library you needed to get a copy of it using $CI =& get_instance().

FuelPHP, you can use static classes. Here is a rough example. Instead of:

$this->load->library('Uri');
$this->uri->segment(1);


you use:

Uri::segment(1);

(Yes, CI does load the Uri class by default, but you get the idea.)

A whole thing on PHP static methods is beyond the scope of this article, but basically using classes as static allows you to access properties and methods without having to create an object context.

When you are loading a library in CodeIgniter, you are creating an object instance, and you are dealing with that object when calling properties and methods. In many cases with FuelPHP, you are accessing static methods using the scope resolution operator (::). One thing many CI coders may rejoice in: this means you don’t have to load a lot of classes.

You can, of course, instantiate classes as objects and several FuelPHP native classes require this, such as the validation class. The syntax for that will look a little more familiar:

$val = Validation::factory();
$val->add('username', 'Your username')->add_rule('required');

You’ll also notice if you are creating a class and using it as static, things that need an object context to work (like $this->) won’t work. You’ll need to use self:: instead.

If you have never used double colons before with it being a typo, then this will be a change. However, it’s something to force you do do some PHP self::educating. See what I did there?

Get Your Namespace On

Namespaces don’t come up at all in CI, mainly because they are really new (5.3+), but they play a larger role in FuelPHP. A warning: my knowledge of namespaces is shaky. So here we go.

In CI, you may have gotten an error telling you you cannot redeclare a class if you have a library the same name as a controller, for instance. Then you have to name your library something stupid and it ruins your day. Am I right?

Namespaces solve that problem by allowing you to encapsulate classes under a certain namespace. Want two classes named Chicken? You got it, if they are under different namespaces.

FuelPHP’s core files are all under the namespace Fuel. What do you care? Well, you’ll care because you’ll start using core Fuel classes in your own classes with namespaces and they won’t work. You need to tell PHP that you want the root namespace, but putting a forward slash in front of the method call:

\Auth::check();

There may be more to it, but to start that’s what you need to know.

So Much More

There are a lot more cool things to discover in FuelPHP (HMVC built in, REST built in, command line integration, etc), but those are the biggies if you are a diehard CI guy. Just remember – FuelPHP is still developing, so if you don’t see something laid out in the docs, dive into the code and the forums. For example, there is a form class, but it hasn’t been documented yet, so don’t be a baby and just look at the damn class already.

Happy coding!

My brother, Derek, is crew with people in the Miami music scene since he himself is a musician (and in Miami). One of the people Derek plays/records/travels with a lot is Sam Friend, a singer/songwriter who has an EP and an album under his belt which have some really fantastic songs.

After I did some live videos for Derek, Sam and I got to talking and I pitched the idea of doing a music video for my favorite song of his, “Part of the Show”. Several months later, the video is done and available to check out here.

Shot last December, the video is taken from one of my favorite games (when I lived in a place where I had cable): finding something ridiculous on TV and watching it. I love scrolling through Comcast at any given time and seeing stuff that really has no place being seen by other people. A need for too much niche programming has left a glut of shows that are cheaply made and insanely targeted. Just thinking about how many shows there are about people baking cakes.

Anyways, I wrote out a treatment that ended up being fairly close to the final product. The apartment scenes were done in downtown Miami when my brother and his girlfriend were moving out of their apartment so it was completely bare. “Swagger” was shot down the street in Miami, and the dog dinner scene as well as “Bulb Buddies” was shot at Doug Klinger’s parents house in Pompano Beach. Thanks to Doug’s parent’s awesome rooftop deck and a patient dog (Layla), we were able to get some awesome rooftop shots which we under-lit to give the feeling of a crappy daytime movie.

So since this is my first music video project, what have I learned? Well, for one, doing a music video for a slower song is much harder than doing one for an up-tempo number. Sam has a catalog of some fantastic songs, and out of them I connected with this one, so that’s the one I pitched, but getting the pacing and timing right to create some momentum turned out to be a real challenge.

Other than that, I learned making music videos is a really fun, interesting experience. That, and I probably shouldn’t be my own DP.

Sam (and Derek too) will be making a trek up to New York soon to make Sam’s next album. He’s the real deal, so I encourage you to check out his current catalog (I especially recommend “Toetotoe”), enjoy the video, and look out for more from Sam in the future!

Lately I’ve been doing some work for my brother, Derek. He did an unbelievable amount of work scoring Pope Michael for me, so although I’d do anything for him for free, I feel like I am still in creative debt to him at this point! We recently launched a site for him as well as a standard Twitter/Facebook combo.

A few weeks before I left Florida for Boston, I got the idea to record a little short about Derek and his trio at their usual Friday stomping grounds – Soya e Pomodoro, a cool little restaurant and lounge a few blocks from Derek’s place in downtown Miami. Derek’s trio consists of him on the keyboard, Brian Tate on the bass, and Dag Markhus on the drums. Lately the amazing Troy Roberts has been a fixture on saxophone and was playing the night we shot.

The idea was to create something short as a showpiece for Derek and the guys with interviews and performance footage. Unfortunately I was in a rush shooting Brian and Dag’s interviews so they look like crap, but Derek’s came out nice. We were there on a fantastic night for the group – they played an incredible show for the cameras.

Doug Klinger awesomely came down to Miami the night we shot this and provided his Canon XH-A1 which I’m operating on the right hand side. Doug is operating my little HVR-A1U. The different in the camera quality between the two makes for a really interesting contrast because we shot by lamp light and had the gain up on each. On the HVR-A1U it washes everything out which makes for some really cool tableaus. The XH-A1 handles it really well and we were able to get a nice golden color. The audio was recorded separately by a little doohickey Derek had.

I intentionally threw caution to the wind to create a funky look in terms of frame rates. Doug’s camera is running at 24p and mine at Sony’s fake Cineframe thing. FCP mixed them well on the timeline and then we spread it out to 30fps on the export to shake things up.

Originally Derek’s solo piece was the opener, but luckily we caught him off-guard while filming b-roll outside of Soya before the show. There was practically no one there at 9 when the show started, but two hours later it was standing room only.