John D Wells

Earlier this morning a friend of mine shouted from their Facebook status:

“HELP AND ADVICE! I need recommendations for stand alone chat and possibly appointment thingy….for use in EE…I need simple easy to implement solutions….any ideas ppl?” (emphasis mine)

I’d read this from my Tweetdeck app. The column beside “Facebook” is a search column, which searches for “#ee OR #expressionengine OR #ellislab”. Randomly, sitting right there beside was this tweet:

“brettdewoody: @litzinger I’m looking for a chat system that integrates with EE. Saw your work on the EE blog and sounds like you might have a lead?” (emphasis mine)

So, I jumped online to read tweets between @litzinger and @brettdewoody, and found this reply from @litzinger:

“The chat system does not integrate with EE (it’s not EE code). It’s completely stand-a-lone but included with an EE plugin.” (emphasis mine)

Since that sounded pretty much exactly what my friend was looking for, I replied to @litzinger, asking him again if he was interested in sharing the chat work.

Just to be clear, he doesn’t know me from a hole in the wall.

Within an hour or so I got a DM saying he would “soon”, which in my book usually means days weeks months or years. Especially because, like I said, who am I to him?

Nonetheless I was very appreciative and got back to him with thanks. An hour later, he tweets:

Releasing the Chat app made for the District202.org site. Was coded in about 5 hours from scratch by Brian Hanson. http://bit.ly/HQBJ0

WOW. I mean wow. I’m not sure if this is touting the power of Twitter, or the devotion of the ExpressionEngine community, but this is the kind of magic I’m encountering more and more, and it really has me speechless.

And infinitely grateful.

I’m putting on my best Used Car Salesman act and convincing a friend to consider ExpressionEngine for an upcoming project. It’s a significant calling based on the spec, will no doubt require at least one custom module, and a strong command of the platform in general. It’s a tall order for any CMS; but I’m confident EE can live up to the challenge.

To help her on her way, I’ve assembled this “Quick Start Guide”: basically a highlight of resources, sites and people that I’ve encountered in my past 2-month crash course in learning EE. I’m only including things in here that I categorically could not live without as I continue to delve into this awesome thing that is EE.

Disclaimer: To date I’ve built two sites with EE, so I’m by no means an expert. But I have a newcomer perspective, which I think will be helpful for her and perhaps others curious about this increasingly popular CMS.

Websites Devoted to ExpressionEngine

• ExpressionEngine’s Online Documentation is an obvious starting point for anyone getting into EE. Also keep close at hand links to the Wiki and Forums.

• Train-ee is a site that has a mix of free and paid-for tutorials. For me it’s most valuable resource was the e-book on building a small business website. I didn’t even hesitate to purchase it.

• Devot-ee is a recent EE site to hit the scene, and it’s made quite a splash already. Built by Ryan Masuga of Masuga Design, it aims to be the go-to resource for EE modules, plugins and extensions. Show your support for the site and contribute by registering as a Devot:ed member for just $39. I just did.

• EE Insider offers everything from bite-sized tips to in-depth how-tos for all things EE.

• Quiglee is a custom Google search that only returns EE results. I keep forgetting to use it, which is just plain silly of me.

ExpressionEngine Screencasts & Podcasts

• Repartee is a brand-spankin’ new podcast being put on by Dan Diemer, and he’s off to a great start. I really hope he keeps it up, his first podcast with Ryan Masuga (previously mentioned) was a good listen.

• EE Screencasts has a few screencast episodes, each for $5. I haven’t actually watched any of these so it’s probably the one thing I’m mentioning here that I can’t really vouch for. But in case you learn better by screencasts, check this out.

People & Companies To Know

• Brandon Kelly is, as far as I can tell, the King of EE module/plugin development. His FieldFrame “Fieldtypes Framework” extension is unquestionably a game-changer, and along with the Playa extension, I simply couldn’t imagine trying to build an EE site without them. (Twitter @brandonkelly )

• Ryan Masuga of Masuga Design has already popped up here, so there’s little more to say. You will not have trouble remembering his name. (Twitter @masugadesign )

• Leevi Graham is, in my mind, the 3rd biggest name in the EE community. Not only does he have a slew of valuable add-ons, but he is all over the community forums. You probably couldn’t count the number of people he’s helped. (Twitter @leevigraham )

• nGen Works has put out 4 EE plugins and I use every single one. I think at least one of them will be come part of EE2.0 core. Need I say more? (Twitter @nGenWorks )

Great Starter Articles

• Structure Is a great tutorial that covers the ins and outs of getting nGen Works’ Structure module running on your EE site. If you need any sort of “tree heirarchy” site, please read.

• Starting Point… is arguably the most comprehensive list of must-have or at least must-know-about plugins. Bonus material discusses a way to keep them organised and ready for an instant new EE deployment.

• Skin an EE Site was also written by the folks at Web Inception, it’s cheeky but spot on.

Parting Words

Like many people before me, I’m merely on the cusp of discovering what ExpressionEngine can do. And while I can’t declare that EE is foolproof or without its quirks, I will say this: it’s the kind of software you can safely bank a career on. Not only will you be able to answer the brief 9 times out of 10, when you hand it off to your clients I can guarantee they’ll love it. And you for it.

A site I’m currently working on requires an age verification check for all site visitors. No, not porn - it’s a website for an alcoholic beverage, so all users must be of legal drinking age. The process is simple: new users to the site must choose “yes” to the question “are you of legal drinking age?”, and if so they are allowed access to the site’s content.

I elected to build this age verification script on the server side, using PHP. The script checks if a cookie is present: if it is, the user is let in; if it isn’t, the user is redirected to the yes/no page.

It then occurred to me that search engine bots will be blocked from accessing the site, since bots do not hold cookies as they crawl. So I borrowed a basic script from the Internets that checks for major search engine bots, and if any of those were detected, they were allowed to skip the age verification question.

However now I’m wondering, should I have simply built the script in Javascript instead? Bots cannot run javascript, so all bots would be allowed to crawl the site, without any ugly hacking.

Of course this means that any user (young or old) who is browsing with Javascript turned off will also have unfettered access to the site.

(…thinking about it…)

I’m sticking with my guns on this one that server side is the better solution for this project, and here’s why: It’s more important to keep underage visitors out of the site than to let every search engine bot in.

Unless you think I’ve missed something?

If you’ve taken the time to learn some of PHP’s best coding practices, you may have come across the technique of omitting the PHP closing tag to avoid unintentional output of white space. For example, the Zend Framework’s coding standard has adopted this, explaining that:

For files that contain only PHP code, the closing tag (“?>”) is never permitted. It is not required by PHP, and omitting it prevents the accidental injection of trailing white space into the response.

Well ExpressionEngine developers have to ignore this advice: where a template file is set to allow PHP processing, the EE template engine needs the closing tag; if omitted, a parse error is thrown by eval():

Parse error: syntax error, unexpected '<' in /ee/core/core.functions.php(637) : eval()'d code on line XX

And schools from Hillsdale, N.J., to Bend, Ore., wary in a litigious era about sexual harassment or improper touching - or citing hallway clogging and late arrivals to class - have banned hugging or imposed a three-second rule.

Source: http://www.nytimes.com/2009/05/28/style/28hugs.html?_r=1&scp=1&sq=hugs&st=cse

Just thought I’d jot down some areas of web projects where I feel there could always be more done:

• cross-browser testing
• useful 404 pages
• search results
• customer training of CMS
• usability / user journey testing
• analytics analysis
• post-launch amends

Of course these areas aren’t neglected out of spite or lack of professionalism; the budgets simply don’t allow for it. By the time we tell a client how much it will cost to design and build her bespoke site, she’ll choke on any more unwanted pounds.

I also reckon that we’re not alone here: we all strive to do some amount of the above, but it’s a rare and special job that explicitly wants those boxes thoroughly ticked; 9 times out of 10 it’s just about putting on a pretty face.

Do I sound cynical?