This is the celebrated journal of Mr. Simon Collison A.K.A Colly

Expression Engine Top Ten Tips - Part One

14th October 2006

Erm, hello… is this thing on? Right. It’s going to be a whirlwind first post, I’m afraid. I politely offered Mr Collison my services at 2.00pm, and less than an hour later I’m clutching login details in my sweaty hand, wondering what topic I should be putting pixel-to-screen about. So, how about the first part of a random rundown of top tips for my favourite web publishing system, Expression Engine? Suits you? Very good!

1. Break it down using templates

If there’s any part of your project that’s going to be repeated, re-used or recycled, you’ll get much more mileage by popping it in a template, and embedding when it’s needed. Same footer on every page? Use {embed=“includes/footer”} and you’ve just saved yourself a bunch of work when the client decides they do want to add a copyright line after all. Sprinkle in some <body id=“home”> magic and you can be embedding a single template to handle your entire site navigation.

2. Weblogs don’t have to be weblogs

This is where Expression Engine’s chameleon-like nature really starts to come in useful. If you’re down with Jeff Croft, but don’t fancy Django, use Custom Weblog Fields to ensure your CMS perfectly fits the structure of your data. Building a recipe site? Simply setup fields for ingredients, method, and tasting-notes. Need a contact management database? Just create a weblog with company name, phone and website fields, then relate it to a second weblog with first name, surname, job title and mobile phone fields.

3. Build a preview using status

The article preview feature in Expression Engine is somewhat, erm, is crude too impolite? And wouldn’t it be great to view your article in-situ before it’s unleashed on the general public? It’s simple. You allow articles to be published with a preview status, then make sure that only you can see them. First, add a Custom Entry Status called “preview”. Then duplicate the weblog tag you want to preview, with the additional parameter of status=“preview”. Now wrap that whole weblog tag with {if username == “your_username”}, and you’re done.

4. Keep with the current version

Are there things you scratched your head about with Expression Engine? Chances are they might now be a whole lot easier. For example, I’ve often hacked and cobbled my way around the single category system, for example creating sub-categories for clients, sectors and disciplines, then struggling to query parent and child categories individually. With EE 1.5 I can now create multiple category systems then assign and use, use and abuse as needed. So keep up-to-date, and make sure you root those gems out of the Change Log.

5. Get with the community

It’s an obvious one really. As more people embrace Expression Engine, there’s more happening on the forums, and more chance for you to get your questions answered (and do some answering, too). If you’re working in a vacuum, the open-ended and blank-canvas nature of EE can sometimes be overwhelming and this is where sharing ideas and techniques can be invaluable. Jambor-EE should be really helpful when it launches.

That’s all, folks

So, that’s the first five. Hope you find them useful, or they tempt you into giving Expression Engine a try. Part Two just added, and feel free to fire me some questions or add your own tips in the comments.


# Andrea responded on 14th October 2006 with...

Regarding point 2 (Weblogs donít have to be weblogs).

With Django and Ruby on Rails different data is stored in different database tables.

With EE, MODx and other powerful CMS when you have heterogeneous data (i.e. news, products, management bios, resellers in a company site) you can create different weblogs (sections) and use custom fields to best fit data structure but in fact all “nodes” are stored (confused) in a unique database table.

What are the drawbacks of this approach in sites with highly heterogeneous data?

# Simon Rudkin responded on 15th October 2006 with...

It’s a good point Andrea. For most day-to-day work with EE, the fact that I’m working with an abstracted view of the data structure (and letting EE worry about the underlying data tables) isn’t a problem. It only really becomes an issue when you need to resort to SQL and you’re querying across tables that don’t neatly correspond to the data structure you’ve setup. Look at the exp_weblog range of tables in EE for more idea.

This is probably a drawback of all systems that do some or all of the hard work for you. The more you let the system do, the harder it is when you want to break away from that. But for me, EE gives me a very good compromise in that I can get my data structure the way I want it - quickly, easily and flexibly - and the downside of cross-table queries isn’t too traumatic.

Hope that helps!

# Simon Collison responded on 15th October 2006 with...

Definitely a good point. I love EE as much as the next man, but some of the database structuring is questionable once you start looking under the hood and attempt to extend the core functionality.

Still, with the EE Query Module there is nothing to stop one selecting a set of information from one table and pumping it into several new tables, and therefore also taking a set of information from several tables and then inserting that back into a one new table.

This reminds me, EE’s admin panel needs to show the database tables in better ways - such as showing only the data you specify from a table, or the ability to search the tables when preparing a query. Creating queries from drop-downs and input fields would be wonderful.

Simon, I agree about the exp_weblogs tables, where weblog data is spread across several tables (same goes for the exp_members group of tables). The way these are structured has prevented me from doing a number of cool things (perhaps due to my limited knowledge of MySQL).

# Dave Sherratt responded on 16th October 2006 with...

Heh just coding my new go3 site and have been continually changing my footer never realised you could that simply include other templates!
Will definitely use this now..
Is it possible to use functions as well?
So i could have a header template but send the variable for the title when requesting the header template?

# Jamie responded on 16th October 2006 with...

In the latest version you can embed variables along with your embedded templates.  Something like:

{embed="site/header" dog_name="Shadow"}

More here in the docs.

# Nik responded on 16th October 2006 with...

Nice one on tip #3.. That’s going to be very useful! Cheers!

# Paul Burdick responded on 18th October 2006 with...

Two little points about #3.  You can also add a username=”” parameter to the weblog tag to show only your entries too, if you have more than one publisher submitting entries.  Also, it would probably be wiser to simply control access to that template with member groups, instead of possibly having a blank template show up.

A definite nod for #4.  Not only because of features but bug fixes and under the hood improvements we are making all of the time.

A pleasant smile for #5.  If you ever have a problem or question about how to do something, use the community.  One should never beat one’s head for five hours when a simple question on the forums could get one there in under an hour.  Frustration is never a good thing and people are (mostly) there to help.


As for the comments…

I think the biggest problem with having so many different types of content is organizing it in a sensical manner on the user side and having it displayable in templates easily.  More and more we have been seeing people creating their own forms on the user side for submitting content, so that the submission form is more unique and tailored to what they want.  We can really only make the Publish form in the Control Panel only so powerful when you have people creating anywhere from one to a hundred weblogs (or data containers, or whatever you want to call it.  We still are debating what would be a better name for all purposes).  When we attempted to redesign it in 1.4 back at the beginning of the year, oh the number of people who had problems with it, even though its approach was far more practical for new abilities and features.

The Simons are spot on about the underlying data structure in the database.  EE’s inherent flexibility has forced us into certain compromises as regards the organization of the data.  It is a pain in the ass to follow, excuse my language.  Even after two and a half years, I still have to jump in there and look around to remember how certain things work.  Underneath it all there are well deliberated reasons for why it is designed this way. 

The Admin cannot be modified to show the tables differently, but what could be done is some panel that assists in writing the query you wish (I will jot that down for 2.0).  I cannot almost guarantee that any manner of data you wish to retrieve can be gotten with one or two queries.  Using MySQL you should be able to JOIN all the data you need for an entry.  Ask in the forums and Derek or I probably can point you in the right direction.


My turn for a feature request.  Could we make this textarea a wee bit bigger?  I tend to get verbose during the twilight hours.

# Will Bolton responded on 18th October 2006 with...

#1 Also consider use of User Defined Global Variables for static content.
#2 This is definitely the key to understanding the power and flexibility of EE. Calling them ‘weblogs’ is confusing. Think of them as data containers.
#3 Nice tip.
#4 and #5 - Good advice.

Good discussion following Andrea’s comment. I think that one just has to accept the inherent compromise in choosing an off-the-peg CMS rather than having a tailor-made solution built using a framework such as RoR or Django.

# Simon Collison responded on 20th October 2006 with...

Paul: regarding the textarea size, I use Cameron’s Resizer to adjust the size of all textareas to suit what I need. It’s a must.

# Paul Burdick responded on 21st October 2006 with...

That is a thing of beauty.  Thank you for pointing it out to me.

Responses are now disabled Your ability to respond is disabled automatically some 30 days after articles are published, or manually much sooner if spamming guttersnipes target a particular article.

Prev 646 Next

Superfluous Aside

Archived in ExpressionEngine, Design & Web

There are 10 responses

External References

Copyright © Mr. Simon Collison 2003-2017. Protected and licensed under a Creative Commons License. Grab the RSS feed

Engineered in Nottingham, scaffolded by ExpressionEngine, steam-pumped by United & kept alive with tea and hugs.