This is a topic I've been chewing on for a while - biting my tongue at times - struggling to formulate my thoughts into something constructive. In the two years since becoming part of the amazing EE community, a lot has changed. One particularly significant change is a swift and steady move towards commercial add-on development - a move that is starting to feel more like a greed-fueled money-grab, than an indication of higher quality software.

Don't get me wrong: I am all for commercial add-ons. At our studio we lobby every day to convince clients that our time and expertise is worth the money we charge. Developers of quality software are equally deserving of fair compensation. So what I am not saying is that I will not pay for your add-on.

I will happily pay for your add-on. But as a paying customer, I will expect a certain level of product and service. I will expect to get my money's worth.

If you plan to develop commercial add-ons for ExpressionEngine, understand what you are agreeing to - understand that you are becoming part of the EE Community, and as such are expected to uphold the spirit of that community: generosity, transparency, responsibility, and professionalism. We are an incredibly eager group of talented professionals that wish to see each other succeed as much as ourselves.

In that spirit, here are 10 "DOs" and "DON'Ts" of commercial add-on development that I think we all should live by:

1. I will... Put my name on it

Take for example just a few pillars of greatness: Brandon Kelly, Leevi Graham, Ryan Masuga, Brian Litzinger (I could go on)... I inherently trust and am willing to invest in their add-ons, not simply because from experience I know them to be excellent, but because they put their name on it. They have placed their personal reputation on the line, alongside the reputation of the software they build, which demonstrates a long-term commitment to keeping their products up-to-date and feature-rich. It's also peace of mind that if something goes wrong, I will know who to turn to for help.

"I smile favorably upon you."

Marketing yourself under a clever name is totally fine, just be sure to let us know who's behind it.  Lobster War Machine is an excellent (and hilarious) example - it takes just a few seconds on the website to know that Jack McDade is the LWM developer - yes, the same Jack behind the indespensible Structure (also brought to you by Travis Schmeisser).

See how much you suddenly trust that gnarly-looking crustacean?

2. I will... Register my add-on with devot:ee

I shouldn't need to mention this one, but better safe than sorry. Even if you decide to sell your add-on elsewhere, it's immensely helpful to have your add-on registered on devot:ee. And when you do put your add-on up on devot:ee, give as much information as possible: compatibility with other add-ons, hooks used, documentation links, image previews, etc.

3. I will... Provide publically-accessible support

Prior to the launch of EE2, probably 99% of all EE Community activity took place in the forums, and for many of us this remains a natural format for seeking & offering help when things go wrong.  EllisLab no longer hosts 3rd party add-on support on their forums, but that's where devot:ee has once again stepped in - with every add-on submitted, a specific forum is instantly made available (whether you like it or not, which I think is brilliant).

If for some reason you don't want to use devot:ee's forums, then consider Get Satisfaction or Tender Support.  But please, offer more than an email address to send to. To me that either says:

• You don't want to broadcast to the world when someone encounters a problem with your product, or
• You will probably not respond in a timely manner to my support request, but do not want evidence of your slow response time, or
• You're just lazy

4. I will... Maintain comprehensive and up-to-date documentation

This is critical, and if you do not take documentation seriously, then I will not take your product seriously. Document everything that relates to:

• pre-sales questions, such as features, screenshots, video demos, software requirements, 3rd party compatibilities
• installation, upgrades, release notes, general usage guidelines
• FAQs, common pitfalls, what to do when something goes wrong

5. I will... Charge an appropriate pricetag

At times I've considered building open-source alternatives to commercial add-ons that I didn't think were worth paying for... Clearly I'm not the only one.

Yeah, this is a tough one. With every product there is a sweet spot for pricing, and the EE market is perhaps still too fresh to know exactly how to calculate this number.  And in theory yes, if your client wants the capability your add-on provides, then your client should be willing to pay for it.

Still I think it's only reasonable to be sure the pricing of your add-on fits appropriately alongside the baseline cost of EE - $300 USD. Second, consider that sometimes your add-on is as much for the person building the site, as it is for the client requesting a particular feature (Low Variables is a good example). In which case a lower price point might gain a higher sales volume, making you more money in the long run.

I can't help but feel some #eecms commercial addons are just taking the piss charging.

@leevigraham via twitter, about 30 seconds ago

If your add-on adds considerable capability to a site, such as e-commerce options BrilliantRetail and CartThrob, then you are more justified in charging a higher amount. Again, look to EE for a guide - the Discussion Module for EE is $100 USD.

However if your add-on simply scratches an itch or does something very specific, I'd price it very carefully - personally anything above $25 USD and I will start to seriously hold your feet to the fire on this entire list.

6. I will not... Build it once and never update it again

Strangely, when I see a commercial add-on staying at or near a "version 1.0" release for ages, it tells me the developer has checked out.  Either that, or it was such a simple add-on to begin with that there's nothing else to do to make it better. Perhaps then I can just build it myself in a day or two (or an hour or two).

7. I will not... Release something utterly broken

Sounds absurd, right? You'd be surprised - just last week I purchased an add-on that straight out-of-the-box didn't work. It was missing an important file, which is a simple mistake but potentially costly - and more importantly not professional. The developer behind the add-on was extremely swift in resolving the issue (and even went so far as to give me a free preview to another of their commercial add-ons), but it still stung.  It will take a lot to regain my trust in that developer.

8. I will not... Charge you for an add-on that I developed for a client

Update: community feedback has challenged this one quite a bit. The general consensus agrees that if the client is aware of your plans to release a commercial product off the back of a job, then fair is fair. Again, the overall message of this is about ensuring the spirit of the commercial venture is pure. Jump to the comments for more.

I realise this is possibly contentious, but it plain seems a bit cheeky to be paid by a client to develop a bespoke plugin, and then turn around and charge us as well. It reminds me of the Costanza's double dip fiasco:

You dipped the chip, you took a bite, and you dipped again... that's like putting your whole mouth in the dip!!

Here's the thing: when you were paid by your client to build that bespoke plugin, I'm 100% certain that at some point, you got help from the community at large - either by pulling apart someone else's add-on, sending out a tweet, or getting help in a forum.  With that help, you delivered a product to your client and were paid (handsomely I hope) for it. And as thanks to us, you turn around and charge us money to use it? Come on.

The possible exception to this is if you promise to obey the #6 I will not... rule and commit to making the add-on better and better over time.

9. I will not... Encrypt my software with IonCube or similar

Not everyone will agree with me on this one either, but encrypting PHP code that I paid for sucks. It seems to go completely against the spirit of PHP in general, but certainly against the spirit of the EE community. If nothing else, it ties my hands to investigate potential bugs or issues with the purchased software - I am out of luck to help myself, at the mercy of the developer to (hopefully) provide me with an update.

10. And if you won't...

Well, I don't think you should be selling your add-on. Look, I'm not trying to shut the door on anyone, but I worry about our collective future successes.  Change is afoot in the EE universe, and I think it's only prudent that we do what we can to ensure we are changing in the right direction, and for the right reasons.  Pure, unadulterated profit should not be one of them.  And in fairness, the above should apply to any commercial software product, and shouldn't be unique to ExpressionEngine.

What are you waiting for?
Get Flickr for EE2 now on Github.

First of all, this is a big shout out to Brett DeWoody and the clever chaps at EE Hive / Digital Wax Works. Not only have they built an already brilliant add-on, not only have they released it for free, but they've invited other EE developers (like me) to get involved and help make Flickr even better.

I've really taken this open source opportunity to heart, and have begun (perhaps over-enthusiastically) contributing to the project.  First order of business was to restore Matrix2 compatibility, which was completed just prior to its release on Github. This week I've been busy with another feature...

Flickr button for Wygwam

I could go on and on (and on) about how awesome Wygwam is - which is also a heavy endorsement for CKEditor as a whole - but I'll leave that for another time. But as I was first setting up Flickr as a custom fieldtype for a current project, I just knew that my client was going to eventually ask how he could embed a Flickr image into his Wygwam field. I imagined the conversation going something like:

Open Flickr in a 2nd browser tab, and find the image you want. Click Actions > View all sizes, and then click on your image. Click on 'Share This', select 'Grab the HTML/BBCode' and...
Awe, fuck it, nevermind. I'll get back to you.

I had little choice. It took a bit of wrestling, a bit of late night sweat and tears. It's still rough around the edges and needs refining, but here's what's soon to come...

What's this, a Flickr button? Hmm, I wonder what this does...

Neat, a CKEditor overlay! So let's click on a thumbnail then...

Oooh, I get to choose which size image I embed into my Wygwam field!

Clicking "Insert" drops the selected image size straight into your Wygwam field, and it's there just as a normal image; you can edit it's properties, alignment etc by using the CKEditor's native image button.

But wait, there's more

Lot's more is in the works for Flickr. We'll be moving the authentication settings away from the fieldtype setup and into an extension. All of the documentation could use a good refresh. I hope to investigate the possibility of handling videos coming from Flickr. We also might reconsider how Flickr saves image info in the custom field, and maybe even look at some caching down the road.  See, lots to do - stay tuned, or get involved!

I'm smack in the middle of a monumental MSM build. It's my second MSM site, and I am once again reminded how I am not in Kansas anymore.  It's still EE, and it's still awesome, but "gotchas" seem a frustratingly common occurrence.

One such "gotcha" is this: as much as EE's docs claim it's easy to mix content across sites, this is in fact much easier said than done. In particular, many 3rd party add-ons, while claiming to be MSM-compatible, are "hard-coded" to use the current site being visited.

Take for example, the glorious Structure addon. It's very MSM-capable, allowing you to build tree structures for each of your sites. However none of its tags allow for you to specify which site you'd like to pull navigation from; it always assumes you want to pull navigation from the currently loaded site.

For this particular MSM project, that's exactly the roadblock I encountered last week, and needed to find a workaround. So I set about digging. Here's what I came up with.

Step 1: Set up your plugin

This article falls under my "Build Your Own Plugin" mantra that I, and others, have written about before. EE plugins are awesomely fun and simple to write, and put you on the fast track to becoming an EE guru.

We're going to build ourselves a simple plugin that :

• saves site-specific config settings for the current site into EE's session object;
• accepts site_name as a parameter, and replaces our site-specific config settings with this requested site;
• when prompted, reverts back to the current site-specific config settings

To start off with we need to set up our plugin. In our __construct() method, let's get an instance of EE, and then set up a session cache array to use later:

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

$plugin_info = array(
	'pi_name'			=> 'MSM Switch Site,
	'pi_version'			=> '1.0.0',
	'pi_author'			=> 'Your Name Here',
	'pi_author_url'		=> 'http://yournamehere.com',
	'pi_description'		=> 'Switch MSM sites mid-rendering of template'
);

class Msm_switch_site {

	var $EE;
	var $cache;

	function __construct()
	{
		$this->EE =& get_instance();

		// set up sess cache if not yet exist
		if( ! array_key_exists('msm_switch_site', $this->EE->session->cache))
		{
			$this->EE->session->cache['msm_switch_site'] = array();
		}
		
		// pass cache object as reference
		$this->cache =& $this->EE->session->cache['msm_switch_site'];
	}
}

Step 2: making the switch()

And here's where the magic happens: first, our switch() method places our current site's config array into our session.  It needs to remember two things:

1. the current site_name
2. the current site's config object

Next, we check for a provided site_name parameter; if passed, then we need to tell EE to load the site's prefs into the config object (check out lines 27-28). If no site_name is passed, then we will switch back to the current site.

function switch()
{
	// capture the orig site config info
	if( ! array_key_exists('msm_switch_site', $this->cache))
	{
		$this->cache['msm_switch_site_orig_short_name'] = $this->EE->config->item('site_short_name');
		$this->cache['msm_switch_site'] = array(
			$this->cache['msm_switch_site_orig_short_name'] => $this->EE->config->config
		);
	}
	
	// if no site_name param was passed, assume we'd like to switch back to orig site
	if( ! $site_name = $this->EE->TMPL->fetch_param('site_name'))
	{
		$this->EE->config->config = $this->cache['msm_switch_site'][$this->cache['msm_switch_site_orig_short_name']];
	}
	else
	{
		// do we already have it in the cache?
		if(array_key_exists($site_name, $this->cache['msm_switch_site']))
		{
			$this->EE->config->config = $this->cache['msm_switch_site'][$site_name];
		}
		else
		{
			// here's the single magical line that switches our site config
			$this->EE->config->site_prefs($site_name);
			$this->cache['msm_switch_site'][$site_name] = $this->EE->config->config;
		}
	}
}

Check out those last couple lines of code again: All we need to do is call $this->EE->config->site_prefs($site_name); to have EE look up our settings, and re-set all the necessary config items.  Then we just have to set this new config object into our cache (in case we need to switch to this site again and again, we can avoid subsequent DB calls).

Step 3: How to use

Let's again use Structure as an example.  Say we want to be guaranteed to show the main navigation of our default site, no matter what site is currently being displayed.  It will look like this:

{exp:msm_switch_site:switch site_name='default_site'}
	{exp:structure:nav_main}
{exp:msm_switch_site:switch}

Line 1 tells EE to switch to the default_site; line 2 calls Structure's nav_main as usual; line 3 tells EE to switch back to whichever site was currently being displayed.

Groovy, eh?

Is all of this really necessary?
Not entirely: You can set the Control Panel Session Type to 'Cookies Only' and avoid all of this - plus gain the "keep me logged in" checkbox on login screens.

Update 2: NEVERMIND ALL OF THIS MALARKEY. As of EE 2.2.somethingorother, there are two new hidden configuration variables that allow you to control the session length of both CP users and front-end visitors. See User Session Length and Control Panel Session Length for more.

Update 1: Initial tests, with the help of some in the community, find that "forever" might only be 4 hours. The reason behind is mentioned in the "Potential Pitfalls" section below, and further discussed in the Comments section. Still, I'd appreciate more input & feedback.

As this EE Wiki entry explains, it is not considered possible to increase EE's session time limit without hacking the core. That's no good of course, so until now I've always considered this task to be off limits.

Then this past weekend I began researching possibilities of overriding/extending EE's core libraries. It's a somewhat controversial topic, and I'll save my musings for another day. But the upshot of all that tinkering was that I discovered it's actually quite simple to modify the hard-coded session time limits, by way of the ever-popular sessions_start hook.

I don’t like it when people tell me I can’t do something I want to do.

- Isaac Raways, author of the Wallace extension

When sessions_start hook is called, it's passed a reference to the EE_Session object; and at least until EllisLab starts protecting class properties (a distinct possibility now that PHP4 support has been dropped), this means it's a piece of cake to overwrite what's in place:

// called by EE's sessions_start hook
function sessions_start($sess)
{
	$sess->cpan_session_len = 12345; // default is 3600, or 1 hour
	$sess->user_session_len = 67891; // default is 7200, or 2 hours
	$sess->session_length = (REQ == 'CP') ? $sess->cpan_session_len : $sess->user_session_len;
	return $sess;
}

Could it really be that easy? From my initial tests, yes, yes it is that easy. So I've turned it into an add-on: Stay Up Forever.

Right now, I'm considering this an early beta release; it's the sort of thing that could, if misused or broken, permanently lock you out of the CP and wreak general havoc.  So I'm hoping there will be some clever/brave souls out there willing to give this a spin.  I'm also hoping anyone from EE's Core team might be able to highlight any potential pitfalls this add-on might raise.

Possible Pitfalls

For example: I'm aware of EE's XID hash, for use with secure forms, and these too have a hard-coded shelf-life: 14400 seconds or 4 hours.  Initially this had me worried that a CP session set to expire beyond 4 hours might result in lost form submissions, but I found that the XID hash is periodically updated via javascript (read line 13 of themes/javascript/compressed/cp/global.js).  However I don't know if this interval is effected by sleeping/waking your computer, so this is a possible gotcha.  I'm keen to hear what others think.

Current Features

Right now, Stay Up Forever is about as simple as it gets: install the extension, go to the settings page, and enter how many seconds you wish the CP and non-CP sessions to last. If you leave either value blank, the defaults will be used.

Default values will also be used if the configured time limit is set below 60 seconds; it's a safety measure to ensure you always have a minimum amount of time to log in, should anything go totally haywire.

It is NSM Add-on Updater compatible, so you'll be notified of updates (why on earth is this not already part of core?).

Potential Features

So far I can think of a few features/improvements:

1. EE1x support
2. Human-readable settings (e.g. '3 hours', '1 day', etc)
3. Settings per member group, as suggested here
4. Better Settings form, instructions etc

Join the Party

That's all for now: drop a comment below if you have feedback or ideas.  And head over to the downloads area to get your copy now.

SIDE NOTE: If you'd rather not hack together your own plugin, there are a number of 3rd party add-ons that can help you achieve the same approach outlined in this article; I've provided links to these alternatives at the bottom of the page.

Generally speaking, a “partial” is a template that can be passed, as a variable, to another template for output. Their purpose is to provide a convenient way to include common content across multiple templates.  Most frameworks (RoR, CodeIgniter, FuelPHP etc) all have their own flavour of template partials, and ExpressionEngine’s embeds & snippets more or less the job - but not without a few downsides.

I'm going to discuss a technique that attempts to remedy these downsides. It will involve getting your hands dirty rolling our own EE plugin.  It will be simple, limited, but hopefully demonstrate the potential at our fingertips.

What We Have Now

I’m willing to bet that if you were to open up any one of your templates in EE, it might look something like this:

{embed="embeds/_html_head"}
<body class="blog">
	<div id="wrapper">
		{embed="embeds/_main_navigation" nav_active="blog"}
		<div id="content">
			{exp:channel:entries ...}
				...
			{/exp:channel:entries}
		</div>
		{snippet_sidebar}
		{embed="embeds/_footer"}
	</div>
	{embed="embeds/_html_foot"}
</body>
</html>

It’s a fairly standard setup, especially if you’ve crossed over from the world of Wordpress and are accustomed to functions like get_header() & get_footer() sprinkled throughout your theme files.  And at a glance, it’s a super convenience, allowing you to include common content across your site.  EE’s embeds and snippets are great.

But the downsides? I see three:

1. Passing content into your embeds is cumbersome at best
2. Each EE embed adds significant overhead to the parsing engine
3. You still have to repeat that general markup structure for every template file that’s directly responsible for outputting content to the browser.

Now, downside #1 can be remedied somewhat by simply wrapping more of your template with your {exp:channel:entries} tag, but it does little if you want to pass more than simple strings into an embed.  Even so, downsides #2 and #3 remain, and these two are of greater concern. So let’s see if we can fix them all.

What We Need

We need a solution that solves our 3 problems above, plus meets an additional requirement I'd like to add:

1. Reduced quantity of embeds
2. DRY template pattern with a single "wrapper" template
3. Chunks of content can easily be passed to that wrapper template
4. Lightweight and bespoke plugin that meets our needs, our flavour of development, and frees us from relying on a 3rd party developer

Let me pause on the last point: I'm a huge proponent of self-reliance; of becoming familiar and comfortable with the core code base that you work on; and of tools that do one job and do that job well.  EE plugins are surprisingly easy to build yourself, open up a whoop-ass can of power, and can even speed up your templates.  You would do yourself a great service to learn how to roll your own EE plugins.

What It Will Look Like

So, we are going to build a "Partials" plugin that allows us to assign chunks of content to variables that are saved and then rendered later on by a single template.  This "wrapper" template will contain our entire page structure, as well as markup that had previously been distributed across our earlier embeds (in our examples, those were _html_head, _main_navigation, _footer and _html_foot).

That's right, we are going to go from 4 template embeds down to 1.

Here's what our calling template will look like:

{embed="embeds/_wrapper" body_class="blog" nav_active="blog"}
{exp:channel:entries ...}
	{exp:partials:set name="page_title"}{title}{/exp:partials:set}
	{exp:partials:set name="content"}
		{channel_body}
	{/exp:partials:set}
{/exp:channel:entries}

You may notice we call our wrapper template first, but then "set" content later. Don't worry though, as the wrapper template will be embeded last, because of EE's parse order. However if you prefer, you're welcome to place the {embed} call at the end of your template. It will work all the same.

Lines 3-6 are where the magic happens: we set two new partials and fill them with content. Our first partial is a simple string; our second contains our entire body content from our channel.

Let's look at our wrapper template now:

<!DOCTYPE html> 
<html>
<head> 
	<title>{exp:partials:get name="page_title"} | {site_name}</title>
</head>
<body class="{embed:body_class}">
	<div id="wrapper">
		<ul id="main_navigation" class="{embed:nav_active}">
			...
		</ul>
		<div id="content">
			{exp:partials:get name="content"}
		</div>
		{snippet_sidebar}
		<div id="footer">
			...
		</div>
		{snippet_analytics}
	</div>
</body>
</html>

Look, no more embeds! What's more, this reads as a complete template; everything is in one place, and any changes to the foundation of your markup structure only needs to be made here. At line 4 we can see where we get one of our template partials, 'page_title'; then at line 12 we get our second, 'content'.

The Plugin, Finally

If you're wholly unfamiliar with EE plugins, head over to the User Guide and have a quick scan to get the basic idea.

And now, to the main event. Copy-and-paste this code into /system/expressionengine/third_party/partials/pi.partials.php, and modify the first few lines to suit; that's right, put your name in there! After all this is going to be your plugin, not mine.

<?php
if ( ! defined('BASEPATH')) exit('No direct script access allowed');
$plugin_info = array(
  'pi_name' => 'Homegrown Partials',
  'pi_version' =>'1.0.0',
  'pi_author' =>'Your Name Here',
  'pi_author_url' => 'http://yoursite.com',
  'pi_description' => 'Homegrown Partials - Template partials plugin for EE'
  );

class Partials {

	public $EE;

	/*
	 * PHP5 constructor
	 * get instance of EE, and set up our session cache
	 */
	public function __construct()
	{
		$this->EE = get_instance();
		if ( ! array_key_exists('partials', $this->EE->session->cache))
		{
			$this->EE->session->cache['partials'] = array();
		}
	}
	// END

	/*
	 * Set content in session
	 */
	public function set()
	{
		$name = strtolower($this->EE->TMPL->fetch_param('name'));
		$this->EE->session->cache['partials'][$name] = $this->EE->TMPL->tagdata;
	}
	// END
	
	/*
	 * Get content from session
	 */
	public function get()
	{
		$name = strtolower($this->EE->TMPL->fetch_param('name'));
		if (array_key_exists($name, $this->EE->session->cache['partials'])
		{
			return $this->EE->session->cache['partials'][$name];
		}
	}
	// END
}
/* End of file pi.partials.php */
/* Location: ./system/expressionengine/third_party/partials/pi.partials.php */

So the first half of our plugin is standard boilerplate stuff; set up our info array (EE needs this), and get an instance of the $EE object. Things get interesting around line 22, when we add an array to EE's session cache. All cache data is only available for this page request, and is wiped as soon as the request is over.

After that, we create two basic methods; one for {exp:partials:set} and one for {exp:partials:get}. Partials::set() retrieves our name parameter and passes all tagdata (everything between {exp:partials:set} ... {/exp:partials:set} into our cache array, where $name is the key.  Then {exp:partials:get} simply retrieves that cached tagdata based on the same $name value.

And since this is ours, and not something we're releasing to the community, we don't need to be super safe - forgo the tedious checks if $name is a valid value, or if you might be overwriting the array value with something previously saved. So simple.

And if you are so inclined, improve upon it; build in a second parameter that flags whether you should overwrite or append your saved data.  Add another parameter that will allow you to append or prepend strings to what is being printed. You could even build multiple variations of the Partials::get() method to output variables differently, depending on your needs.

The possibilities are endless, and again since this is For Your Site Only, there's nothing to stop you!

3rd Party Solutions

This approach is in fact not new, but definitely not well-promoted; a few community developers have built fantastic and feature-rich add-ons that will help you achieve this technique if you'd rather not build your own plugin.  A few of these are:

• MX Jumper - By max Lazar, for EE2, free
• REEposition - By Studo625, for EE1, free
• NSM Transplant - By Leevi Graham, for EE2, $AUD 34.95
• String Plugin - By eMarketSouth, for EE1.6x and EE2, $9.95

Over the xmas holidays I tweeted a call for help to debug some work I'd recently done on Minimee. A few dedicated souls (@leepowell, @GWcode) were kind enough to jump in and kick its tires. Thanks to their fantastic input, I'm proud to announce Minimee's 1.1.0 release!

You can download the latest copy of Minimee now.

Highlights of the release

I've bumped the version number from 1.0.2 to 1.1.0 due to significant changes under the hood - a slew of improvements that makes Minimee easier and more stable to use.

cURL support

Previously, Minimee relied on file_get_contents() to retrieve external files (which yes, includes {stylesheet=}). Due to an occasional shared hosting glitch, as well as the welcomed PHP5 requirement as of EE 2.1.2, it seemed necessary to add cURL support.  While cURL is now the default, I've given users the option to specify which method to use if they so desire.

Support for global variables

Support for Global Variables became a request I could no longer ignore: but to keep performance up, Minimee will only trigger EE's global parsing routine if it detects any existing EE tags.

Yummy PHP5 support

Seeing as EE2.1.2 has dropped PHP4 support, so has Minimee - You might not notice anything different, but it has greatly improved the clarity and structure of the code.

'Intelligent' templating

Previously, Minimee's output of <link ..> and <script ...> tags were hard-coded; the only thing you could customise was the media parameter for the link tag. Now though, Minimee uses the first HTML tag it encounters as a "template" for output. As long as your first tag is formatted as you so desire, MInimee's final output will be, too.

Of course because of this change, the "media=" parameter is now obsolete.

New 'debug' mode

There's a new configuration option to turn on "debugging", which will output HTML comments for any error encountered. Should you encounter difficulty getting Minimee up and running, this should help you quickly nail down the problem.

Note: Error and debug messages will always be sent to EE's logging mechanism (available in /system/codeigniter/system/logs/log-yyyy-mm-dd.php) - as long as you've turned on your debug threshold.  More on that in Minimee's User Guide.

'Strict' mode removed

By default, Minimee used to silently ignore any missing file(s), thereby creating a cached file based on whatever was available at the time. This behaviour could be turned off by setting the mode "strict" to TRUE (via config or param), but frankly all this feature did was cause problems & confusion.  Hence I've completely removed this feature: now MInimee will only work if all files are found.

From true/false to yes/no

Any configuration settings or parameters that were once boolean (TRUE/FALSE or the string 'true'/'false') should now be set with 'yes' or 'no', as appropriate.  This was to simplify the normalising of settings.  The details behind this deserve a brief article that I'll publish in a few week's time.

Jeez, anything else?

Actually yes. A few bug fixes, and a few other tweaks here and there, makes this a very exciting release. As usual if anyone has any problems, you're encouraged to use the support forums on devot-ee.com.  I keep a close eye on this and do my absolute best to respond in a timely manner.

For me, the ah-hah moment came as I read one of Brandon Kelly's posts over on his Pixel & Tonic blog. He was kindly reviewing some of his work done to launch the new P&T website. In it he described how he'd written a custom plugin function to replace all instances of "http://" with "https://" for any templates that were going to be operating under SSL. To me, it was a hack, plain and simple: an elegant demonstration how to bend EE to your will, to harness EE's sometimes peculiar parsing order to your advantage.

Since then, I begin every project with an empty plugin. As you can see from EE's developer documentation, the barebones of a plugin are incredibly simple:

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

$plugin_info = array(
	'pi_name' => 'SiteName',
	'pi_version' =>'1.0.0',
	'pi_author' =>'Your Name',
	'pi_author_url' => 'http://sitename.com',
	'pi_description' => 'SiteName - A few hacker functions for this theme/site'
);

class SiteName {

	var $EE;

	function __construct()
	{
		$this->EE =& get_instance();
	}
}
/* End of file pi.sitename.php */
/* Location: ./system/expressionengine/third_party/sitename/pi.sitename.php */

Once you get into the swing of rolling your own plugins, you might be surprised at what you come up with; in circumstances where you could both simplify and speed up your templates by relying on a hacked up plugin to do some outputting for you. Consider it part of your template arsenal, just like CSS files and Javascripts.

A Real World Hack

I'm currently working on a project that relies heavily on Flickr.  I'm using DataGrab to periodically query the Flickr API for new or modified photos from our client account, and to import their information into a channel. I store all information about the photos such as Farm ID, Server ID, etc, but never the images themselves. I need to create <img> tags based on Flickr's formula, which, if you've worked with before, is not the easiest to remember. So I wrote this plugin:

/*
 * Assembles a valid URL to flickr image
 */
function flickr()
{
	$size = strtolower($this->EE->TMPL->fetch_param('size'));
	$size = ($size) ? $size : 'square'; // default is square
	
	$id = strtolower($this->EE->TMPL->fetch_param('id')); // UID of photo
	$server = strtolower($this->EE->TMPL->fetch_param('server')); // server ID
	$secret = strtolower($this->EE->TMPL->fetch_param('secret')); // secret
	$farm = strtolower($this->EE->TMPL->fetch_param('farm')); // farm ID
	
	switch ($size) // determine prefix based on size
	{
		case('square') :
			$prefix = '_s';
		break;
		case('thumb') :
			$prefix = '_t';
		break;
		case('small') :
			$prefix = '_m';
		break;
		case('large') :
			$prefix = '_b';
		break;
		case('medium') :
		default :
			$prefix = '';
		break;
	}
	
	return "http://farm{$farm}.static.flickr.com/{$server}/{$id}_{$secret}{$prefix}.jpg";
}

As you'll notice, it's incredibly simple; it retrieves my parameters, defines a prefix string based on the requested size, and returns the compiled src string. If I need a large version of my image, this is all I need to do:

{exp:sitename:flickr size="large" id="{f_id}" server="{f_server}" secret="{f_secret}" farm="{f_farm}"}

If I'd rather output a square thumbnail, I only need change the first parameter to size="square". As the Meerkat for CompareTheMarket.com would declare, "Simples! Chk-chk."

Hack vs 3rd Party Addon

Why do I consider the above example a hack and not a 3rd party add-on? To my mind, what makes a hack is this: it's a (sometimes hasty) snippet of code that exists to solve one problem and one problem only. It is built under very specific circumstances, to be used by a very specific audience: Just Me. Notice that my function performs no checks; it does not sanitise data, it doesn't abort if not given enough data to return a valid URL.

It's simple and effective. If I port it over to another project, it very well may need to change. And that's a good thing: I am free to change it at will.  I don't worry about legacy support.  Who cares if it might bork on IIS. I don't need to file a feature request with the developer to ask for some new piece of functionality.

Plugins are the perfect place for you to "hack" because they too are simple and effective.  Modules & Extensions require touching the database, they require install and uninstall methods, you must activate them via the Control Panel.  But a plugin? Just drop it in your third_party folder and go.

Resources To Get Started

If I've convinced you to build some simple plugins of your own, then keep these links on hand, print out some cheat sheets, and start hacking away:

• ExpressionEngine's Developer Guide
• CodeIgniter's User Guide
• EE2 Quick Reference Chart
• EE2 Constants Reference
• EE2 Cheat Sheet

Parting thought: if you really want to have some fun, then spend some time under the hood: EE's source code is well commented and logically organised.  A few hours perusing the source, along with learning EE's general DB structure, will make you a pro hacker in no time.