Thread

With EE1, there was Gypsy that could enable you to work outside the field groups. I could put all my custom fields in 1 field group, assign it to all the channels and filter out the fields I didn’t need. Then for every publish/edit entry, the DB query was limited to only those fields that were assigned to that channel.

In EE2, we have Publish Layouts. I can again, create a master default field group, assign it to all my channels and use the Publish Layouts option to hide the custom fields that aren’t needed for that channel.

My question is, does EE2 Publish Layout simply use jQuery to hide those fields from being used? Or is this info inserted into the database so that the MySQL call will be affected.

I’m asking for performance reasons. If my go to my publish/edit screen and my default field group has 50 custom fields, but this particular channel only needs 10 of those, does EE2 call for all 50 fields in the DB query and use Javascript to hide the other 40? Or is the MySQL query only calling the 10 needed?

Thanks for the clarification!

I just did a test on 2.1.4 and it seems that just some CSS is being used to hide the fields so I’m guessing CSS maybe mixed in with Javascript or the CSS is created before the page renders.

Not totally sure on which it is but the fields that I hid using a publish layout were definitely still available in the source code. Definitely agree that it would be better if they literally weren’t even on the page.

Best wishes,

Mark

haha. Or CSS - an even simpler solution.

Thanks for doing that Mark.

It’d be definitely better to have the fields not ever appear since custom fields can get complicated. Matrix, Playa, Wygwam, etc - ok, maybe just Brandon Kelly’s custom fields.

Gypsy was a nice way to help keep your exp_weblog_data table smaller by eliminating duplicate custom field columns, especially when working on a large MSM install. I’m still looking for that magic solution for EE2.

Yep totally with you here. I’m sure that something will come up rather soon though.

Best wishes,

Mark

Hi Marc,

The actual array for your Publish Layout is saved in the exp_layout_publish table itself

It’d be definitely better to have the fields not ever appear since custom fields can get complicated. Matrix, Playa, Wygwam, etc - ok, maybe just Brandon Kelly’s custom fields.

Nearly all Brandon’s now have their own tables

I really don’t think it is gonna be massive performance hit. This is also the control panel and not the front-end we are talking about.

Have you turned on the Output Profiler and measured this?

System Administration -> Output and Debugging Preferences

What most describes your performance hit, page load speed, blank pages etc?

Even in your cp footer, what does it say there?

Script executed in 0.4734 seconds - 48 SQL queries used

Well, it’s not so much a concern for me just yet. All my 2.x sites so far have been straight forward, single sites. But I have a 1.x MSM install with 14 sites in it that I’m planning on moving to EE2 this year.

It’s a massive undertaking and I have to convert all my Gypsy fields into something more EE2 compatible. So this was more of a curiosity question, trying to get a grasp on how performance may be improved or diminished with large custom field groups.

Thanks John.

Hi, Marc.

It depends on what you’re doing with those 14 sites. As John mentioned Brandon has started using his own tables, so that should help.

Did you get enough of an answer from what John mentioned?

Seems that if there are more tables, then that just means larger queries to join all the tables together. If there’s a Matrix field or Playa field that I’m not using on one particular channel but is in the custom field group, then I’m guessing all that data is still getting called in the Publish page query, but the Publish Layout array is simply adding a CSS style hidden to the rows that I’m not using.

Yes, I know I’m quibbling about milliseconds here and it only affects page admins, but I’m hyper-sensitive about site performance right now, trying to improve every microsecond I can.

You can close this. I’m just trying to understand everything I can about what affects page performance. Thanks!

I can certainly understand your concerns about site performance. If you need more of a speed improvement, try building out SafeCracker forms, when you can put in JUST the fields you want, and none of the additional fields will be placed in there. That might be an answer for you. What do you think?

For the current site I’m doing now that will have several content producers who live in 2nd and 3rd world countries, I was certainly thinking of doing that. Partially for performance reasons (this one is only a single site install) but also because I didn’t want to translate all the admin pages.

As for my MSM site, that seems really too much work to create safecracker forms for all those channels (85 channels and growing, 354 custom fields) But it is nice to know it’s an option.

I’m looking forward to hearing from Emily Lewis at the Engine Summit and talks at the EECI Conference to try to glean more information on how best to handle large MSM sites.

Sounds like that will be a great topic. In that case, closing the thread, but feel free to open a new one as needed.

Now really closing. 😊