I'm new to EE, and have a project with a lot of database relationships. For example, the company offers a "Service", in certain "Zip Codes".

So I see in EE, I can create channel fields, etc, and create the relationship between a Service and the (many) zip codes to which it applies.

In the admin area, the client would be able to CRUD Zip codes, Services, and map the two appropriately. However, some fields that are default in EE, like "URL", don't make any sense for a "Zip code" entry. It can be ignored, and still works, but not ideal for a non-technical client to use. Also things like Expiration dates, and the other tabbed fields don't make sense.

My question is twofold:

  1. Is this appropriate way to use EE, or it is better (though more tedious) to build a custom module to manage "non-content" based entities?

  2. Is there a way to customize the "Channel" screen to hide the unnecessary fields and focus the user a bit on what they need to enter?

I'm just trying to get a sense of how to approach this task and how EE was meant to be used.


2 Answers 2


Welcome to EE... I'll start by saying that in my opinion EE is not "meant to be used" in any particular way and is usually flexible enough to do things whichever way you prefer.

As already mentioned, you can use Publish Layouts to hide the URL Title field and Expiration Date etc. If this is not enough you can go off-piste and create your own standalone entry forms on the front end with Channel Form.

However, by the sound of it, maybe using a mapping fieldtype such as http://devot-ee.com/add-ons/google-maps might be better?

If you think it's more appropriate you might want to consider using EE's categories system instead - adding each Zip Code as a category and then assigning each Service entry to the relevant categories. Bear in mind that this reduces your future flexibility a little bit since categories are less powerful than channel entries.

You could also opt for a third party Tagging solution such as Tagger - again, similar to categories but at a lower level/more free-form kind of organisation.


It seems like you're going to make a channel for zip codes and each entry is a separate zip, so I think what you're looking for is Publish Layouts. Then you can customize the way the entries for that channel display based on member group, hiding fields and tabs that you don't want visible for the client.

  • Thanks - yes we ended up pursuing this route, using Channels, etc. Both answers were helpful.
    – Jim
    Oct 23, 2014 at 18:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.