Thread

Greetings Expression Engine-ers!

Wednesday saw the first minister of the Scottish Government launch our first Expression Engine powered site. The site’s focused on helping to develop offshore wind power around Scotland.

It’s been a great project and Expression Engine has been a really good fit for what we needed to do. We’ve got a ton of features built on the backend that minimise content editing chores for our client. At the same time the site’s super-configurable and extensible.

So while I’m here I’d like to say a big “thanks” to the EE team for all the work that’s gone into EE over the years - great work.

Nice work. Great looking site and structured the way I like to organize my EE sites. How are you handling the single-column vs. two-column layouts? Is that something the content admin selects? Or is it something “hard-coded” into the system for certain pages?

Thanks - glad you like the site.

Single column/two column layout is really defined at the template level. We’re using Structure, so content editors can just select the template that they want to use to render a piece of content.

We’ve got a standard two column template, a one column template for things like the timeline page, but we’ve also got a kind of hybrid template that they can use as a kind of “Section homepage” (e.g. the Building the Industry page) that’s a mixture of one and two column. Interestingly, all of these templates display the same content type/channel. So when a content ed is creating a piece of content, they define what they want to display around about it - for example, they pick an entry or two to display in the right hand column, or they can elect to display a collection of links, or they can display links to other pages within a given section, etc.

There’s a wee downside to this approach in that some fields for a given piece of content don’t really do anything when that content type is applied with a certain template (e.g. right hand column configuration when they use a single column template). Some mechanism of greying out some of the custom fields when a certain template is selected would be a nice-to-have. But overall I think it’s working well.

Should have guessed you were using Structure.

For some projects I’ve used a single field group for all channels, and using custom publish layouts to hide the irrelevant fields according to the channel you’re publishing to. You might try that. I haven’t experimented with them yet; I’ve heard about some unexpected “gotchas” when using them. So I usually just explain to the client that certain fields’ data will not show up when publishing to certain channels. As long as the site is pretty flat this is usually fine, but generally I just go ahead and create multiple field groups with namespaced field names.

Thanks again for the feedback.

That’s very interesting - I’ve not done much with the custom layout stuff yet.

The idea of having one single field group is also really interesting. We’ve ended up with quite a few very similar includes that do things like getting related articles, and the only thing that’s different in such includes are field names - so having a single field group would solve that one too. As long as you can lock down custom publish layouts for member groups, that could be a go-er.

All good food for thought. Thanks!

Hi there, congratulations on your site.

One question: The interactive map, how did you make it? I’m building a site for a maritime expedition and we’d like to implement a feature like this showing the route and ship positions with links to blog posts.

I haven’t experimented with them yet; I’ve heard about some unexpected “gotchas” when using them.

I’m considering using this approach at the moment for a site with very similar templates and entries with several relationships. Do you remember some of the ‘gotchas’ you’ve heard about?

Thanks!
Kath