Thread

Is there any issues I should be aware of using custom fields over categories?

I’m trying to making publishing items for a non-technical end user as smooth as possible - and in the current form I know they are going to forget to assign a category as it is on the second tab.

There is also no requirement to assign a category so this is sure to be missed and content is going to be filed in the wrong area.

As was touched on in this thread http://ellislab.com/forums/viewthread/50368/ are there any issues or constraints that I may have if I have a weblog and a list of ‘categories’ that can be selected via a custom field drop down list?

I can still call entries based on that custom field if I need to in the templates.

I just wanted to make sure this path is safe before I proceed with changing a weblog over to this setup.

Thanks.

You could grab the 1.2.1 publish page extension from our Add-on Library, which puts everything on the front-page, or use a SAEF to show the form how you want, with categories right there.

Many people like categories for their tags - the categories list tag and categories archives tags, which are quick ways to make navigation as well as group posts together.  You can also limit posts viewed to a certain category which you can’t do out of the box in EE, with a custom field - though there is an extension for it.

Ultimately you have to decide what you need, but categories and custom fields serve two fairly different needs, imo.

Thanks for that Lisa - i’ve installed the Publish Page extension and that does indeed bring it all to the front page.

I still like the look and layout of the tabbed publish form however. I had a bit of a poke in the cp.publish and cp.display files to see if I could make a small hack to have those categories be displayed on the front publish page but didn’t have any luck.

If anyone has done this or know of a quick hack or custom extension that might be able to do this that would be brilliant. It’s important for me to have that category selection on that front page to avoid it being missed.

I haven’t gone down the SAEF path yet - but the client will be using the CP quite a bit and I think getting out of it to enter some content for a particular weblog isn’t ideal.

Actually looking at it again - an extension that essentially displays what you see when you click on the category tab is what I’m looking for. You have the category list at the top where you can classify the entry and then continue on to enter the URL/Title/Content etc.

At the moment you get some text saying that “No categories have been assigned to this section.” ideally this would be hidden if there are not categories to be displayed (although I understand that it can be switched off at the weblog level in the admin).

Anyone willing to hack up the cp.publish/cp.display or somehow modify the publishPages extensions to not remove the tabs entirely and have a workflow similar to what I have mentioned?

Note about the Publish Page extension, though, from painful personal experience: none of Mark Huot’s extra field type extensions seem to work with it. Which makes me very sad, since i HATE HATE HATE the tabbed publish interface, but i really can’t live without the Huot extensions for a number of my client projects.

Well you’ve got two issues here -
- The aesthetics for the poster (end user): making it easy for him to select a category, ie: bringing category selection out of the tab.
- And his actual workflow: making sure he doesn’t post an item without categories.

I don’t know how to fix the aesthetics. It doesn’t sound easy. But can’t you just make selecting categories mandatory for posting? A nicely instructive error message would take care of your workflow issue. “I’m sorry you must select at least one category for this article, to do so…” How that would actually be accomplished? Um, I don’t know. Anyone?

Many times I’ve watched my dad go through astoundingly complicated processes to open an excel file or find a photo because he just doesn’t understand windows explorer or the whole file system concept. It would drive me absolutely bonkers, but he doesn’t seem to mind at all. Doesn’t know any better. I guess what I’m trying to say is, will the novice end user really care if it’s all on one “page”? Won’t he just learn fairly quickly to click over to the categories tab and select something every time if it won’t let him post without doing so?

Categories vs. custom fields is a whole other bucket of monkeys. There are a number of pro/cons but I think that’s only tangentially related to the 2 issues you’re trying to solve here.

You can set a default category so one is always selected.  If you wanted to check for a selection you’d need an extension, though.

That would be, methinks, a very useful extension for a great number of EE applications. And Lisa says better in 20 words than what I tried to in 200. Typical.

I only got away with that because it was a response to your post, Kevin.  =)

You can set a default category so one is always selected.  If you wanted to check for a selection you’d need an extension, though.

I know about the default category - but that doesn’t really work. If my site is running different sections and it’s important to file each entry to match the section it’s going to be displayed on then having a default category is only going to lump all the posts you forget to assign into a group that probably wont show online - ie. if you use a default category of unsorted.

The users would then realise that their content isn’t online and then have to go back in and make the change.

The category selection concept however I think is the solution to my problem.

I’m happy with the tabs and like it’s workflow but if we had an extension that could allow you to set any of the default fields (in my instance the category) within the tabs so they are required then that would work really well.

Even though I’m only looking for an extension to alter for the category, i’m sure other users might have a need for making some of the other options required as well.

Time’s like this I really wish I was competent with PHP!

Anyone will to take it on 😊

Another thought that comes to mind reading this thread is possibly using relationships instead of categories.  From a data entry point of view it puts the field on the same tab, and from a code point of view lets you use more out of the box EE functionality.

If multiple categories need to be assigned there’s Huot’s multi-relationship extension.

I admit I’m not up to speed on relationships just yet - although I will look into that tomorrow. But am I correct in thinking that there could be a custom field that using a relationship is linked to the available categories for that weblog/section.

So in effect on the front publish tab the user is presented with a required drop down custom entry that contains the available categories in the list?

The category tab could then in fact be hidden and they are never actually physically set - the content is however placed in that category indirectly via the custom field.

In effect you’d setup a weblog to hold your categories, then create a relationship field in your content weblog that would display the category titles.  When publishing a new entry you’d choose the proper category from the relationship field.

On your templates you’d use either related entries or reverse related entries depending on which end of the tube you were looking through…;)

Just got around to doing this today - I’ve setup a relationship with the other weblog that holds my category titles.

Everything works fine but I was just wondering how I get the category to be displayed within the entry.

My custom field for the relationship is called ‘category’ but if I use {category} within the template it gives the category id (ie. 4) rather than the name.

I don’t think I can use the regular EE Category tags cause i’m not really assigning them into a category.

Any ideas?

Related entries tag.