Joel Bradbury gave a great talk about add-on development & support, sharing his experience moving to a rapid, iterative development approach. He began by astutely noting that the things we find hardest at work are also those we tend to ignore and put off. Yet this avoidance tends to only compound the difficulty.

His solution is to do the hard stuff first, and often. The theory behind it is sound: the more you do something, the better you get at it. Before you know it, that which was once hard is now easy, perhaps even routine.

Joel applied this philosophy to the release cycle of his add-ons, committing to do at least one release per week. While the first few weeks/months proved challenging, he soon was able to not only achieve a release a week, but sometimes more. Now the anguish of pushing a release has been reduced to an inconsequential step along the way, and the generated momentum has freed his time & attention for bug fixes, feature requests, and new product development.

Joel also addressed the concept of paid/unpaid support. This has been a hot topic among EE’s developer community of late. He decided to approach the problem from the other end: rather than focusing on how to support those finding difficulty in using his software, he now offers paid installations of his add-ons. It's a pre-emptive support model that not only helps his customers, but his bottom line. Everyone wins.

Raise your hand if you knew this one: wrapping a variable in curly brackets will negate an otherwise perfectly legitimate-looking Simple Conditional.

I sure hope I'm not the only one raising my hand.

Yes, Simple Conditionals are more than just about their lack of logical operators (e.g. no AND, OR), lack of control structures (e.g. no ELSE, ELSEIF), or type of variable (e.g. must be a segment, embed, or global variable).  To pass the mustard to be considered a "Simple" conditional, it also must follow a few syntax rules as well.

No writing about EE's Parse Order is complete without a knowledge bomb from @low.

@kristengrote Because of line 3197 of Template.php in EE2.6.1, but I guess that’s not what you want to hear. #eecms

— Lodewijk Schutte (@low) June 6, 2013

It's especially awesome to notice that EE's own docs describing what a Simple Conditional is, actually isn't - "username" is not an early-parsed variable. @low pointed out that one as well.

If you're like me you may be surprised by this, because it is not explicitly mentioned in EE's documentation. But if you read between the lines (as well as through the comments), you'll see the syntax rules emerge, which are:

• the left-hand side of the condition MUST be either a segment, embed, or global variable
• the right-hand side of the condition MUST be a string (at least at the time that the condition is evaluated)
• the left-hand variable MUST NOT have curly brackets and/or quotes around it

So what is a Simple Conditional

First, let's see what is a Simple Conditional. Here, we are comparing a segment variable against a string:

{if segment_1 == "blog"}
	<h1>Blog!</h1>
{/if}

What isn't a Simple Conditional

Wrapping your variable in curly brackets:

{if {segment_2} == "blog"}
	...
{/if}

Wrapping your variable in curly brackets and quotes:

{if "{segment_1}" == "blog"}
	...
{/if}

Flipping the placement of your variable and the string you are comparing:

{if "blog" == segment_1}
	...
{/if}

Ommitting the quotes around the string just because it's an integer:

{if embed:number < 5}
	...
{/if}

Placing an Advanced Conditional within a Simple Conditional:

{if segment_1 != ""}	
	{exp:class:method}
		{if var == "foo"}
			Lorem
		{if:else}
			Ipsum
		{/if}
	{/exp:class:method}
{/if}

Courtesy of @low with a genius solution: https://gist.github.com/low/1391783

Bonus 1: Comparing 2 early-parsed variables (possible)

Have you ever wanted to compare 2 early-parsed variables? It's possible, but again, syntax matters.  Keeping the above rules in mind, the trick is to get EE to parse the right-hand variable into a string prior to the Simple Conditional stage of the parse order. Like so:

{if segment_1 == "{embed:segment}"}
	...
{/if}

Bonus 2: Comparing a non-existent variable (not possible...ish)

Let's say you're using Rob Sanchez's awesome Mo' Variables extension to create an early-parsed variable for a browser cookie named "hometown". If that cookie matches the string value "richmond", you want to run a special query just for those visitors. You'd probably write something like:

{if cookie:hometown == "richmond"}
	{exp:channel:entries channel="howdyneighbor"}
		...
	{/exp:channel:entries}
{/if}

If the cookie "hometown" exists (regardless of value, including an empty string), then this conditional would in fact be Simple. However if the cookie did not yet exist, the above would in fact fail as a Simple Conditional.

So how might we construct a Simple Conditional to successfully run against a non-existent variable? Refer to what we learned above: by "casting" the non-existent variable to a string, and comparing it to an existing variable:

{!-- Where 'lv_hometown_default' is an early parsed Low Variable with a value of "richmond" --}
{if lv_hometown_default == "{cookie:hometown}"}
	...
{/if}

Of course if your code fails as a Simple Conditional, it will be fine as an Advanced Conditional, and there's nothing necessarily wrong with your code!  Sometimes though when you're looking to squeeze out performance gains, the difference matters.  Or, and this is more relevant to recent work of our own, if you're conditionally setting a Preload Replace variable, then it's of vital importance.

Either way, these nuances of EE's parsing engine are important to master. As always I welcome feedback, correction, and illumination.

Nesting an Advanced Conditional inside a module tag parameter. It's been said it can't be done.

{exp:channel:entries
    status="{if '{segment_3}' == 'closed'}closed{if:else}draft{/if}"}
    {title} - {status}<br>
{/exp:channel:entries}

"You are using advanced conditionals in your tag, and in EE, they don't parse soon enough for your tag. Your tag is likely seeing all possible conditions when it processes."
Using conditionals in channel entries parameters

Ultimately at issue here is the ExpressionEngine® Parse Order, which is an obscure yet critical concept that every EE developer will at some point confront (and with the help of fine folks like Low, hopefully overcome).

On most days it sits quietly behind the scenes making things Just Work™ and providing the backbone for the simplicity and beauty of EE's template markup.

Then every so often it is the devil-in-the-details gremlin that riddles your project with exceptions, caveats, and "it depends" workarounds - like when it comes to conditional statements.  See, in the world of the Parse Order, no two conditionals are the same - they're either considered "Simple", or "Advanced", and where they sit amongst the Parse Order matters a great deal - especially for performance, but also when we want to use them as a tag parameter.

Simple Conditionals - unfashionably early:

A conditional is considered "simple" if it is evaluating variables that are already available by the time the template parsing engine reaches the simple conditionals parsing stage (e.g. segment, embed, and user-defined global variables), the expression evaluates a single variable (i.e. contains no logical operators such as OR, AND), and the conditional does not make use of the else or elseif control structures.

In short, a simple conditional will look very much like this:

{if segment_1 == "joe"}
    <h1>Hi Joe!</h1>
{/if}

Advanced Conditionals - fashionably late:

Any conditional that isn't a simple conditional is considered an "advanced" conditional and is evaluated much later in the template parsing order. Advanced Conditionals can use logical operators (ex: OR, AND) to compare multiple variables to multiple values.

{if username == "joe" OR username == "jane"}
    <h1>Hi {username}!</h1>
{if:else}
    <h1>Who goes there?</h1>
{/if}

So when EE serves up each template, the Template Engine makes multiple passes through its contents, as it incrementally steps through each stage of the Parse Order. When it comes to evaluating conditional control structures, you need to know that:

• Simple Conditionals are processed early, before module & plugins tags
• Advanced Conditionals are processed late, after module & plugin tags

The takeaway from this is that you can use a Simple Conditional as part of a tag parameter, since the conditional will be evaluated prior to the outer tag being run. However since Advanced Conditionals are parsed late, the outer tag's parameter will equal the complete, un-evaluated Advanced Conditional string.

So, what else can we pass as a tag parameter?

That is a great question. We now know we can pass simple conditionals, and referencing the Parse Order we know that we can pass early-parsed variables (segments, embeds and early globals) and preload_replace variables. So how about another plugin?

Yes, in fact - you can pass a plugin as a tag parameter. If you add parse="inward" to your outer tag, then the Template engine will check if the content of any parameter value appears to be itself a plugin - and if so, it will be parsed immediately. See:

/* ---------------------------------
/*  Plugin as Parameter
/*
/*  - Example: channel="{exp:some_plugin}"
/*  - A bit of a hidden feature.  Has been tested but not quite
/*  ready to say it is ready for prime time as I might want to 
/*  move it to earlier in processing so that if there are 
/*  multiple plugins being used as parameters it is only called
/*  once instead of for every single parameter. - Paul
/* ---------------------------------*/

if (substr_count($this->tag_data[$i]['tag'], LD.'exp') > 1 &&
    isset($this->tag_data[$i]['params']['parse']) &&
    $this->tag_data[$i]['params']['parse'] == 'inward')
{
....
$this->log_item("Plugin in Parameter, Processing Plugin First");
....
}

That, dear friends, is straight from the Template Engine itself - around line 1054. Hi, Paul! By now, I'm hoping you're with me on this ah-hah moment - because all we need now is a plugin that is specifically designed to evalute Advanced Conditionals. And lo and behold, one already exists.

The ifElse plugin from Mark Croxton

You may already know @croxton from Stash. Or from Switchee. Or other handy add-ons - you should check him out on Github. He's a mighty clever chap.

ifElse: Early parsing of advanced conditionals in EE templates. With ifElse, Mark has once again done the hard work to make our lives easier - he's built a plugin that coaxes EE's Template Engine to parse an advanced conditional as if it were a Simple Conditional - which is to say the conditions are evaluated before evaluating the tags within each control structure. But as an added bonus, ifElse now gives us the ability to pass an Advanced Conditional as a tag parameter.

So if we add parse="inward" to our outer tag, and wrap our Advanced Conditional in the ifElse plugin, this is what we get:

{exp:channel:entries
    limit="3"
    parse="inward"
    status="{exp:ifelse}{if '{segment_3}' == 'closed'}closed{if:else}draft{/if}{/exp:ifelse}"}
    {title} - {status}<br>
{/exp:channel:entries}

Update 2nd April: As has been astutely pointed out a few times now, this is a nonsensical example that is better achieved with a Simple Conditional, since it is operating upon an Early Parsed variable. Keep in mind however that not all variables are parsed early, so there are still going to be times where an Advanced Conditional is unavoidable. My apologies for not choosing a more appropriate example from the outset.

And it Just Works™ once again - exp:ifelse is run, your condition is evaluated, and either 'closed' or 'draft' is returned to the status= parameter. It was everything we'd ever hoped for, and more. Horray!

Horray indeed! But before you go, some parting advice

Nesting tags within tags within tags can be taxing for EE's Template Engine to know where one thing starts and another begins. So adhere to these two rules if you use this approach:

1. Use double & single quote nesting with care

If you're using double quotes for your outer tag parameters, use single quotes for you nested plugin-tag-as-parameter. Using all of one quote type may yield unexpected results.

2. For this technique to work, be sure to wrap early-parsed variables in curly brackets.

Early-parsed variables (as well as preload_replace variables) should be contained in curly brackets (e.g. {variable}) to be sure the Template Engine can evaluate them early.

Note that for Simple Conditionals it is important to NOT wrap early-parsed variables in curly brackets. Thanks Paul for the reminder.

I should also say that I've only just discovered this trick, so I'd appreciate hearing feedback on your experiences, in particular if there are any other important caveats or syntax/parse rules to keep in mind. Happy templating all...

Update 1st April: As Low very correctly pointed out in the comments below, this does rely on an unofficial "hidden" feature, so there is no guarantee that future versions of EE will allow this technique. As always you should choose the solution that best suits the task at hand, and future-proof & maintainability are vital criteria to consider. 

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.