August 3, 2010

Custom Fields and the Death of the Field Group

In my book, Custom Fields are ExpressionEngine’s strongest feature. They’re right at the core of what defines EE. And they’ve been bustling with innovation lately, from the add-on community as well as EllisLab.

But I don’t think we’ve seen their full potential yet, and I think Field Groups are partly to blame.

Where did we come from?

Before we can responsibly discuss the future of EE Custom Fields, we need to to establish how we got to where we are today.

pMachine Pro

The pMachine Pro submission page, with its three entry fields.

In 2002, EllisLab made their first foray into web publishing with a lightweight blogging tool called pMachine Pro. You could set up multiple weblogs, and their entries had the usual assortment of entry submission fields: ‘Blurb’, ‘Body’, and ‘More’.

“At the time it was all about the blogging tools, and all of them (or at least the ones I looked at) seemed to be limited to ‘title’, ‘summary’, ‘body’, and ‘extended’ fields. To have 3 additional ones to play with was heady stuff.”

—Mike Boyink, Train-ee

Despite being more akin to traditional blogging software than general-purpose content management systems, there was a great diversity in the sites being built with it. EllisLab noticed, and decided to foster it. So pMachine 2.0 added three new “Custom Fields” to the submission page, which could be enabled on a per-weblog basis.

For its price point, this was a huge advancement in web publishing, because it enabled web developers to tailor their publish forms to fit their needs. They were no longer stuck with the exact recipe of fields the app’s creator had decided upon.

Sure the feature had its limits, but it gave developers a taste for what was to come.

ExpressionEngine

As users continued to stretch pMachine in new ways, Rick Ellis saw the need for a next-generation publishing system—something new from the ground up. So he began working on ExpressionEngine.

During the pMachine Pro days I was amazed at how far people we're pushing the app in ways I hadn't anticipated, so when I started developing ExpressionEngine I had a much better sense of where I needed to take the app.

ExpressionEngine 1.0 was released in April 2004. With it, EllisLab built upon pMachine Pro’s Custom Fields concept in two key ways:

  1. Custom Fields now had a variety of new Field Types to choose from. One could be a drop-down menu, another could be a date picker, etc..
  2. Custom Fields were no longer assigned directly to weblogs, but rather to Field Groups, which could contain any number of Custom Fields. Each weblog was then assigned one Field Group.

These made for an extremely powerful combination, defining ExpressionEngine as a truly malleable content management system.

Fieldtype Development

ExpressionEngine’s ability to select variant Field Types was nothing short of revolutionary, but it was missing a key ingredient: a supported way for add-on developers to inject custom Field Types into the system.

That’s not to say people didn’t find ways to do it, though. In September 2004, Arnold Jagt published a guide to hacking FCKeditor into ExpressionEngine 1.2. And in July 2005, Chris Jennings described how to hack TinyMCE into ExpressionEngine 1.3.

Things got a little easier in May 2006. EllisLab released ExpressionEngine 1.4.2, which introduced 7 new extension hooks, making it possible for add-on developers to write their own “fieldtype extensions”—extensions which added new Field Types to your arsenal, without requiring you to hack EE’s system files.

“When I first got into EE back in 2006, there was Mark Huot making fieldtypes. Then Leevi, and then Brandon. Then Brandon released FieldFrame, and things went ape shit!”

—Ryan Masuga, Devot:ee

Mark Huot is largely responsible for pioneering early fieldtype development. He made his debut with Multi Drop-down List, and went on to release several others, including the wildly popular File field.

Not long after, Leevi Graham got into the scene with LG TinyMCE, arguably the most popular WYSIWYG field ever released for ExpressionEngine 1. In early 2008, I took a stab at fieldtype extensions with Playa.

While the fieldtype hooks certainly made fieldtypes easier to install, they weren’t very easy to write. Developing extensions in EE tends to get a little messy, and fieldtype extensions were a glaring example of that. So there were only a small handful of other developers that ever joined in the fun. When I set out to write Playa 2, I couldn’t even muster up the stomach to deal with it again. (Roughly half of Playa 1’s code was a jumble of regular expressions that had no relevance on the actual app logic.) So I decided to first write FieldFrame. FieldFrame abstracted all the complexities of fieldtype extension development, lowering the barrier of entry to that of a plugin. And once it was out, fieldtype development finally took serious flight.

Outgrowing Field Groups

Field Groups in ExpressionEngine work well for a specific case: websites which have multiple, identical sections. A shining example of this is blogs.cisco.com, which holds several identically-modeled weblogs, differentiated by subject matter alone.

More often than not, though, different weblogs have different data models. So creating and filling up a Field Group is a process linked directly with creating a new weblog. Most of the time that’s perfectly acceptable, but it’s not uncommon for two weblogs to have almost identical data models. Unfortunately, ExpressionEngine provides no way for two Field Groups to share fields, so you’d be faced with two options: (1) create two near-identical Field Groups, or (2) lump all the fields (both shared and weblog-specific) together in one Field Group, and provide field instructions that remind the author which fields to ignore, depending on which weblog they’re posting in. Either way was frustrating.

In October 2008, EllisLab released a build of ExpressionEngine 1.6.5 that added a new extension hook, “publish_form_field_query”. Essentially, it gave extensions the power to override which fields would appear on the publish page. Two months later I put it to work, with Gypsy. Gypsy gave web developers the option of assigning their Custom Fields directly to one or more weblogs, ignoring their Field Group assignments.

Just days ago, Tim Kelty released Field General, another extension to take advantage of the hook.

It dawned on me that, like categories, there was no architectural reason why you couldn’t have multiple Field Groups assigned to a weblog. The hook was there for the Field Group query, so I ran with it.

I asked Tim what his thoughts were on Gypsy vs. Field General:

I could never get over the management issue. I want to see and edit which fields are assigned to weblogs, but with Gypsy the field is the boss, not the weblog, so it’s hard to see an overview and control display order.

I certainly like the idea of managing fields by weblog rather than weblogs by field. But as Tim pointed out to me, going through Field Groups does tend to require creating a lot of single-field Field Groups.

Where are we now?

On July 12, EllisLab officially released ExpressionEngine 2, bringing ExpressionEngine closer to a general-purpose CMS than ever before. Case in point, “weblogs” were renamed to “channels”, the most nondescript term they could think of.

Two of the most significant additions in the release revolved around Custom Fields.

Fieldtype API

Fieldtypes are finally first-class add-ons in ExpressionEngine 2. To add-on developers, that means writing fieldtypes in EE2 is just as easy as it was to write them with FieldFrame. (In fact, EllisLab intentionally architected the fieldtype API to look familiar to FieldFrame vets.) To end users, it means we should be seeing a lot more third party fieldtypes right off the bat. And according to Derek Jones, that’s exactly what’s happening:

It's still early, but the adoption rate easily surpasses the adoption rate of extensions by developers when we first added them to ExpressionEngine.

Beyond porting the fieldtypes that came with EE1 using this new API, EllisLab also wrote four new ones: Checkboxes, File, Multi Select, Radio Buttons.

Publish Layouts

Publish Layouts are one of ExpressionEngine 2’s most interesting new concepts. They give you complete control over the layout of your Publish page—for tabs as well as fields—on a per-channel basis. You can create, remove, reorder, and rename tabs, choose which fields go in which tabs, and even shrink adjacent fields’ widths a bit to get them to display side-by-side.

According to Derek Jones, this was just another step toward making ExpressionEngine as unassuming as possible:

This came about entirely in response to the demands being made on ExpressionEngine for publishing wider varieties of content. The HTML form that is well suited to publishing articles for a newspaper or online magazine are entirely different from the form that is well suited to entering hundreds of business addresses and phone numbers. Extending on EE’s principle of making no assumptions about your data, we decided to make no assumption about what your client's publish form needs to look like, and let you decide.

To be honest, when I first started using the EE2 Beta, I wasn’t so sure about the concept. It was a lot to take in, coming from a point where we were limited to customizing the display order of the fields alone. It wasn’t until I was building pixelandtonic.com that I realized what a powerful concept it was.

One thing that struck me was that the feature doubled as a way to hide fields from certain channels. For example, I have an ‘EE Add-ons’ channel set up on pixelandtonic.com. It’s assigned an ‘EE Add-ons’ Field Group with the following Custom Fields:

Each of those fields are relevant to my primary add-ons. On the other hand, entries in the Dive Bar’s channel only have a need for Compatibility and Main Content. Back in the EE1 days, I would have either created a new Field Group, duplicating those two fields, or used Gypsy to assign the six unneeded fields directly to the EE Add-ons channel alone. But since pixelandtonic.com runs on EE2, I had a new option: I could simply edit the Dive Bar channel’s Publish Layout, and just hide those unneeded fields.

Module Tabs

Modules learned a new trick in ExpressionEngine 2: they can now create their own tabs in the publish page, and fill them up with a default set of fields. I say “default” because Module Tabs/fields are subject to the same manipulation that all other tabs/fields are via Publish Layouts.

I had a chance to play around with Module Tabs when writing Juniper, my homegrown eCommerce module for Pixel & Tonic. Juniper adds a new tab to the publish page called ‘Juniper’, pre-set with two fields: ‘Price’ and ‘Release Notes’. In my EE Add-ons channel, I customized my Publish Layout, moving the ‘For Sale?’ field into that Juniper tab, and in all other channels I removed the tab entirely.

Where are we headed?

There are two trends that stand out to me in all of this:

  1. Custom Fields have come a hell of a long way from their humble beginnings in pMachine Pro. They’ve benefitted from vibrant innovation by EllisLab and add-on developers alike.
  2. Field Groups, on the other hand, have only become less relevant with time. Add-on developers have spent significant time exploring ways to get around their limitations, and with the additions of Publish Layouts and Module Tabs in ExpressionEngine 2, EllisLab themselves have been playing down their importance.

Looking forward, I think it’s safe to say that Custom Fields will continue to become more versatile, and Field Groups will continue to lose relevance.

There’s still a lot of frustration over Custom Fields in ExpressionEngine, primarily due to their Field Group constraint. I know it (I’m constantly getting requests to port Gypsy to EE2) and EllisLab knows it (they’re constantly getting requests to add the publish_form_field_query hook to EE2). But the hook isn’t coming back, and even if it were, I’m not porting Gypsy.

EllisLab would rather find a way to solve the problem for everyone, without requiring a third party extension, and I’m fully supportive of that.

So how do they solve the problem, exactly? Over the past couple weeks, I’ve been putting a lot of thought into it, and I think I’ve come up with an idea that should work for everyone.

My Proposal

First, channels get a new “Edit Publish Layout” link between “Edit Preferences” and “Edit Group Assignments” in the Channel Management page.

Channel Management

Clicking on a channel’s Edit Publish Layout link takes you to a new page where you can fully customize its Publish Layout. (Note that this would completely replace the right-hand toolbar on Publish pages.)

Edit Publish Layout

My comp’s a little rough around the edges, but you get the idea. Each visible tab is listed on the left, populated with the fields it contains, and unused fields are on the right. Dragging fields/tabs from the right to left selects them; dragging from left to right deselects them. You can also reorder tabs and move individual fields from tab to tab via drag-n-drops.

And here’s the kicker: all fields are available, from every field group. Field Groups still exist, but they’re used for organizational purposes only (like Upload Directories).

Finally, when you’re creating new channels, you’d have the option of duplicating an existing channel’s publish layout.

Create a New Channel

So in summary, fields are assigned directly to channels via their Publish Layouts, and field groups are reduced to organizational constructs.

Far From Perfect

My proposal is an evolutionary step that addresses current pain points. But new ones will surface, as web developers continue to test the limits of ExpressionEngine.

I asked Rick Ellis where he thinks custom fields are headed. He imagines a much more revolutionary future is in store for them, in time:

Bruce Lee said that the ultimate technique is no technique. What he meant is that the goal of a martial artist is to posses such well developed knowledge, awareness, fluidity, timing, and sensitivity, that the specific techniques don't matter anymore; the goal is to go beyond technique into a state of pure effectiveness.

So in a way I have this vague idea that Custom Fields should evolve into a vehicle that is so transparent, intuitive, flexible, and useful, that it allows a pure expression of information, without the constraints of boxes on a page. I don't have a design concept yet, but I do believe we’re far from having perfect tools.

Thanks!

Many thanks to all of you who helped me fill in the blanks and answer my questions while writing this: Mike Boyink, Rick Ellis, Derek Jones, Lisa Wess, Pascal Kriete, Mark Huot, Tim Kelty, and Ryan Masuga. I couldn’t have put all this together without you.

Euan

Great article Brandon - I’ll try to digest more of the finer details tonight. Look forward to your next articles.

Mason Stewart

Intriguing. I’ll wager that this will prove to be one of those definitive, oft-referenced posts that ends up being very influential in the growth of ExpressionEngine. This sort of article is far more valuable than some run-of-the-mill tutorial. Here’s to historically-grounded insight and well-rounded theory! Great work, Brandon.

MediaGirl, Inc.

If the right-hand toolbar on Publish pages doesn’t go away, it should just load empty… then we can build exactly what we need instead of deleting everything we don’t need.

Boyink

It’s nice to read a blog post with some research behind it in this day and age of 140 characters..;)

One small correction - in pMachinePro the 3 custom fields were available to all weblogs.  The only configuration for them was if you wanted them to appear on the Publish page or not - and that setting was system-wide.

Ryan Battles

Glad I took the time to read this, although I have to admit when I saw the first line I thought that you had actually written a book about Custom Fields.

For what it’s worth, I put a hearty vote into seeing EllisLab put some time into implementing your suggestions.  I have been continually searching for a way to hack the Field Group issues you have mentioned, from trying Gypsy to recently taking Levi’s advice at EECI 2010 to just create a separate field group per weblog, even if it is identical to something else, just in case the client later comes along with one more field request. 

Your proposed solution seems to solve a lot of issues, so it would be sweet to see it implemented somehow.

Steve

Great article. I wrestle with Field Groups every time I map data for a new site, and must admit to having a tight chest when considering I would no longer have Gypsy on EE2 builds.

I asked about custom field performance considerations on the EE2 support forum, and I’m hoping for some clarity on the impact of empty and assigned, but hidden custom fields.

Brandon Kelly

@Steve: Right now there is potential for significant performance losses, since EE is including the HTML and JS for all hidden fields (adds up if you’re using Wygwam, etc.). I didn’t cover it in the article, but one of the big benefits of removing the toolbar from the publish page would be that there’s no need to include the disabled fields anymore. You’d only get what you need.

Steve

@Brandon Good Point, I wasn’t considering the publish page. I was actually referring to front-end performance hits when using the channel entries tag.

Derek Jones

+1

Sorry, couldn’t resist.

It’s nice to read a blog post with some research behind it in this day and age of 140 characters..;)

Without a doubt.

Erwin Heiser

One thing I don’t get in the proposal is how you would make the “Edit Publish Layout” editable on a per member-group basis as you can do now.

I agree this part of the CP could do with improvements, I didn’t even realize they were draggable until I read it in the forums.

Nathan Pitman

Great post Brandon. I think your proposed solution is exactly what EE2 needs, it puts field configuration back where developers ‘expect’ it to live and uncouples it from the UI of the publish page, that has to be a good thing surely?

Hope the wonderful folk at EllisLab are listening. :)

Mike Hughes

Hey Brandon -

Thanks for writing this.  It’s always great to read an inspirational post that solidifies the reason I decided to go with EE in the first place.  Great application and an amazing community.  Very interesting stuff indeed and I’m curious to see how the concept of Field Groups evolves in the future.

Brandon Kelly

@Erwin: The comp is incomplete (even lacks buttons to add/remove tabs, etc), but I imagine there would be a drop-down menu at the top where you could choose which member group’s layout you’re editing. At this stage, the UI is less important than the concept itself.

Grover

That last quote from Rick scares me a bit. It sounds like he’s falling into a common trap for very smart people, which is thinking too far into the future. That perfect input is indeed out there, but in the meantime we’ve all got work to do and these evolutionary steps help a lot in the meantime.

Really enjoyed the article Brandon, thanks!

Cem Meric

Great post Brandon. A part from custom fields proposal it should be added to EE wiki as a part of EE history :)

John Faulds

Love the ideas you’ve put forward for future changes Brandon; I reckon you’re right on the money there. On the subject of porting gypsy to EE2, it seems Brian Litzinger has done just that: http://boldminded.com/add-ons/drifter/

Bob Monsour

Brandon, this is great stuff, particularly for those of us relatively new to EE (and starting with EE 2). It really helps to develop the mental models for creating sites with varying IA considerations. And it seems to soundly answer the question of why you would not want to port Gypsy to EE 2.

Many thanks.

Lea

This is why you’re such a huge asset to the EE community, Brandon. Thank you for this thought-provoking post with historical context! I would absolutely love this type of feature, though I would probably still have publish form editing features so we can identify whether a field should be shortened width-wise, or “closed” (different from hidden, just having a sometimes-used but not super important field there to be shown or not by default via the triangle on the side). Yes, yes, I know it’s just a rough concept, but I think EllisLab is going to be reviewing this thread so just throwing my suggestion to the ring. ;-)

Dan Grebb

Brandon you should really write more theoretical EE posts this article is terrific. Great work!

Andy Marshall

Brilliant.

I’ve been pondering this issue since doing an EE2 site the past week or so, and this would have made such a difference.

13 channels and 18 diff fields in total, some general to all channels, others specific to single channels, most somewhere in between.

Just the option, when creating a new field, to set if it appears in every weblog’s Publish page by default or not would have been a big timesaver… being able to duplicate an exact layout from one channel to another and then tweak it further would have too.

Brilliant blog Brandon.

Nevsie

Using groups for organisation rather than restriction is the way forward. Freeing custom fields is a logical step preventing duplicate fields in the database - lightening the load.

But when it comes to custom tabs and fields through modules/extensions - EE need to sort the bugs preventing them from working first and quickly as it is a real pain.

Tony Geer

This is indeed a brilliant way of addressing pretty much all of the issues that currently surround field groups, good job Brandon!

Nathan Pitman

Of course someone could always write a module to provide a better interface for managing custom fields and then write an extension to hide the current sidebar on the publish/edit pages. :)

Brandon Kelly

@Nathan: There’s certainly an opportunity there, if you’re willing to live without the freedom-from-field-groups aspect.

But EE would still be loading all the HTML, CSS, and JS for all the fields, and tabbing/hiding the fields after page load. That itself was just as much an inspiration for writing this piece as the field group aspect.

I didn’t cover the technicalities of implementing my idea, but part of it would be that PHP only grabs the fields that are actually enabled in the Publish Layout, and prepares the Publish page’s HTML so that they’re already divided into tabs, and all but the first tab have display:none; set. The only post-pageload JS that would be needed is handling new tab selections.

Poccuo

We would love to see something like your proposed “Edit Publish Layout” in the future.

Just to throw in one of those kinks of why the idea is still “rough around the edges” ... it would be nice if there were a way to work in unique user instructions, per field, so that they aren’t duplicated across all groups. Just wanted to throw that out there while it was on my mind.

This is a really huge idea, and a must read article.

Brandon Kelly

@Poccuo: I like the idea of overriding field instructions per channel, but it’s a slippery slope. You give people that one feature and they’ll be asking to override the Required setting as well, and so on.

I wonder how far a few field instruction tags would go, though. i.e., allow the use of {channel_name} within the instructions.

Poccuo

@Brandon Kelly

True enough, I suppose I had considered instruction fields to be a easier to add a bit of TLC too but you’re absolutely right, its a slippery slope indeed when it comes to customizing the field settings. I suppose then it would be a good opportunity for a savvy add-on developer to create such a tool. The beauty of EE.

Now the real mystery…how did you get a photo of my cat to post next to my name? You’re creepin’ me out Mr. Kelly.

Shawn Berg

Great article and history Brandon! Very impressed with your new ideas and appreciated the history on pMachine Pro and EE seeing we just started integrating EE ourselves about a year ago. Keep up the good work!

Marcus Neto

This idea sucks. I cant believe you all have fallen for such drivel.

Joking of course but in a chorus of +1s I just wanted to be different ;-)

In all seriousness the functionality that a system like this would bring when building large complex site for churches and organizations with lots and lots of weird data type would be covered in awesomesauce. Perhaps they could just enable a hook and you could build another add-on and rake in additional millions! Great post.

Narration

Highest points go for your diplomacy, Brandon.

9.0 also on the concept. It’s got the directness to purpose that real solutions have.

Regards

Michael C.

While we’re at it, can we push for the ability to have custom fieldtypes for Categories and Member Profiles? I know both can have custom fields added, but they’re restricted to the built-in Text/Teatarea/Dropdown fieldtypes. I mean, seriously, how many of you all have created “People” weblogs/channels, just so you could have better control over the data?

Simon Cox

It’s always bothered me that once a field was in a group you could not use it else where - they are after all little pots of data - Gypsy was the revelation I was looking for in EE1 and I hope Brandon’s great article here pushes this aspect of my fav CMS further- at the moment I don’t think EE2 is quite as mature as it could be - this enhancement would help a lot. Nice one Brandon!

Maleika E. Attawel

This is one heck of an informative and intriguing article. The death of, or the death to the dependencies of custom fields to a group, would make the building of sites so much more efficient in every which way.

Thanks for this, Brandon!

ramonekalsaw

Very educational.

Daniel Veiga

We’ve built a lot of sites in EE2 recently and now were starting to see the limitations of the field group and trying to find a more robust and versatile solution… I think what you proposed to Rick is great and we just need to wait and see where Custom Fields are going to go in the near future - hopefully sooner than next year!

Tim Kelty

It may be worth pointing out that in EE2, rather than porting Gypsy or Field General, you can get a lot more flexibility by just using a single field group for all your fields and turning them on or off and ordering them per channel.

A bit of a hassle to manage, but the end result what you want. For now, thats my approach for EE2, but I hope this article sparks some changes.

I’d also like to see this concept be taken one step further, and allow fields to be shared between MSM sites. Just like freeing fields from field groups, there’s no good reason why not.

John Macpherson

Now there’s a great idea for some EE dev to get going on.
On large or dynamic sites it would be useful to say the least.
Thanks Brandon, great post.

Brennan Sang

I love the idea of freeing fields from the current restrictions of field groups, but the term “Publish Layout” sounds like a presentational term, rather than a structural term. I like how EE implicitly defines the contents of a channel through the fields (really the types of data) that are associated with it.

Why not have fields live by themselves outside of field groups and then have field groups simply be a collection of fields? Then we would still assign field groups to channels, but the fields could be shared across any number of field groups.

The end result is very similar — the difference is really in the approach, but something about defining the contents of a channel through the Publish Layout feels counterintuitive to me.

Timo Häkkinen

I love this idea and keep up the good work, Brandon. You’re a valuable member to EE world. This is exactly how I’d love to see EE evolve.

Michael C.

Posted by Brennan Sang:
Why not have fields live by themselves outside of field groups and then have field groups simply be a collection of fields? Then we would still assign field groups to channels, but the fields could be shared across any number of field groups.

I think Brennan has hit upon a great solution. The only thing I might add would be the ability to assign individual fields directly to channels in addition to field groups.

Tobz

I think this is a brilliant solution to publish layouts.

I’d also like to be able to add custom channel fields(channel description) to a layout - although this might be better placed in a separate plugin?

therooster

Great idea Brandon. 

I miss Pmachine pro! A great little product!!

Christopher Beckwith

Lovely article. Being newer to the ExpressionEngine finding the best way to setup my custom fields and or groups has become a challenge. I assumed it was simply because I did not understand the system well enough but after reading this I see it’s also an issue with limitations of the software.

WYGWAM is great, and sure clients will find it useful who don’t enjoy code as much as I do. I’m also currently researching Playa to see if that will help solve some of my problems with creating a sort of stream on the homepage that pulls in the latest content from different channels.

Twitter is great and clearly helpful as you have mentioned but oh man I miss the days of great blog articles. This one and the one over at The Nerdery have brightened my day.

Vinci

Brilliant! I think your approach could go a long way to making EE2 that much better.

Magzalez

I’m so glad you put this together, Brandon. My co-worker and I have talked about this exact concept many times.

Maybe an article like this is the impetus Ellis Labs needs to make this sort of feature more of a priority.

Good work.

Luke

A typical EE setup for me involves quite a few channels all with a diverse array of fields and matrix driven fields. I build a lot of travel sites and hence my accommodation channel is always going to require totally different fields to my tours channel. And this design pattern is by no means going to be limited to travel sites.

One field group for the entire site is not an option for me and I believe many others. It would be beyond cumbersome and 90% of fields would have to be turned off for every channel.

My point is that Gypsy Fields were extremely useful to me when it came to the few fields that did happen to be common to most of my channels. Things like my gypsy_meta_description, gypsy_tags, gypsy_html_title, gypsy_image_gallery etc. With EE2 this kind of setup is impossible as far as I can gather..

Neil

Good to see these thoughts written out by someone who EE might wish to pay attention to… hope maybe is better choice of words!

Natetronn

Death to the Field Group!!!
Okay, sorry, got a bit carried away there.

Anyhow, this looks great! I hope this gets added to the road map asap.

Todd D.

Can’t believe I missed this article from several months ago. Excellent concepts and it’s good to know that Ellislab might shape EE with this type of functionality in the future. http://expressionengine.com/forums/viewthread/184367/#871917

Kevin Barr

Revisiting this after being reminded of it in this thread: http://expressionengine.com/forums/viewthread/186370/

Ready for this solution to be implemented - and for Ellis Labs to hire Brandon!

Brendan Underwood

Brandon, I’m looking at updating a couple of websites that have deep use of Gypsy in them. Single field group is used for the entry content so around about 30 custom fields. If updating to EE2 on these sites is done, would having the {exp:channel:entries} tag calling up entries cause major performance issues if it’s having to return the 30 custom fields?

Was looking to upgrade to EE2 and then use the Publish Layout’s to hide only display the ones needed per channel as sort of outlined in this post.

Brandon Kelly

@Brendan, your biggest issue is going to be publish page JS performance, since EE simply hides the unused field group fields with a jQuery().hide().

As for template performance, Channel Entries is already parsing every single custom field, regardless of field group, per each entry. That’s why Gypsy worked in the first place. So having a consolidated field group will only help templating performance, since it’s not parsing extra, duplicate fields across multiple field groups.

Brendan Underwood

Hmmm. Interesting. I’ve had a number of people say that template performance would diminish as there’s more fields that the entries tag needs to parse. But that didn’t make sense considering all custom fields are a part of the same table anyway.

Might have to do some performance tests comparing the two ways of doing it…unless you know of some that compares this particular way of working already?

geoge

yp9JT0 http://fnYwlOpd2n9t4Vx6A3lbk.com

Shann

This has always been an issue for me.

You could simplify your solution by just getting rid of field groups altogether. They aren’t needed and your solution renders them as such anyway.

When you go to Admin -> Channel Administration -> Channel Fields you should just see a big list of fields you have created and these are available to any channel.

Then in the Admin -> Channels Administration -> Channels -> Edit Preferences page - you could associate all the fields you want and their order priority.

Your “Duplicate existing channel’s publish layout” would then change to “Duplicate existing channel’s fields”.

PXLated

How did I miss this? Great article!

Post a Comment