Is there a way to force a tag into a topic in a specific category without the user having to add it?

Although I’m probably two weeks away from launching my first Discourse site (a replacement for a mailing list I’ve been running for 30 years), I’m already thinking ahead towards another possible project, which is to move my cooking/baking blog site from Wordpress/BBPress to Discourse.

To do this I need a way to recognize recipes and alter how they are formatted and printed.

It looks like topic tags are the way to go in terms of tagging a new topic as having a recipe in the lead post (followups would be comments, not full recipes), but there doesn’t seem to be a way to force a tag (ie, ‘recipe’) into the tag field. I’m also looking at using the tag field to indicate the type of recipe (bread, dessert, meat, etc) so that a recipe could have multiple tags, such as: recipe dessert.

Printing is a separate issue, I’ve already decided that for this to work I will need to create a plug-in that gives Discourse greater control over printing selected posts from a topic. Formatting a recipe-tagged (lead) post for printing is probably a second task. I’m probably several months away from knowing enough Ruby to even think of tackling this.

But that’s enough wish listing, my question NOW is, can I force a new topic in a category (eg, recipes) to have a tag pre-inserted (eg, recipe) so that the user doesn’t have to select it and can’t delete it?

1 Like

I’m not sure about your specific use case, but it might be redundant to force the same tag on every topic in a category.

While you can’t prepopulate a tag in a category using existing settings, it’s possible to achieve this through a theme component or a plugin.

Without further customization, there are a couple of options that could potentially work for your case:

  1. Set the Minimum number of tags required in a topic: setting in the category and add a required tag group to the category.

    This way, you could set up multiple tags for the category like bread, dessert, meat etc — users wouldn’t be able to post without choosing at least 1 (or more) tags.

  2. Set up automatic tagging based on a word or phrase that commonly appears in recipes. You can do this from admin/customize/watched_words.

    This approach might require some trial and error and may not be perfect. If you’re in the US, this is slightly easier since the imperial system has unique measurements. Most recipes would probably mention tsp or tbsp, for example. Other phrases that come to mind, which would be fairly unique to recipes, might include preheat, mixing bowl, saute and so on.

1 Like

I’d actually rather have a separate field in a post that says ‘this is a recipe, format accordingly’, so that the tags can be used for other more user-facing purposes, as both of us have illustrated, but I’m not sure how to do that yet. I know there are ways to have custom post fields and custom topic fields, but I’m still learning how to access or utilize them.

While I’m thinking that primarily the lead post in a topic would be tagged for recipe formatting, it could conceivably apply elsewhere. Moreover, there may be other use cases for flagging a post for special formatting beyond my cooking blog, where a flagged post is not necessarily the lead post in a topic or in any specific category. And generalizing the approach might have more widespread utility.

The details of recipe formulation are another can of worms, ideally I’d like a structured format so I can isolate fields for the ingredient, the unit of measure being specified and the amount, preferably in a way that would allow me to utilize other databases of ingredient nutrient information, price, inventory, etc. Total yield would also allow a recipe to be scaled up or down. A few other cooking sites do this, but I think they’re missing features that I know I’d like, and so would the baking community. Whether all that can be done in a way that is compatible with the DIscourse data structure is a separate issue. (But my first impression is that it may be easier to do it in Discourse than in WordPress or as a from-scratch standalone system, you’ve already built a lot of the supporting structures.)

You could use a TopicCustomField in a plugin, but a staff-only tag set, or one enforced for all users would be easier to maintain. Also, could you just make a set of categories be recipes, so you could just apply that formatting to the whole category? That seems like the easiest solution to “which topics are recipes”.

That would work for my specific use case, but I’m trying to think ahead here towards a plug-in that would have more general value. Which makes more sense:

I want this category to have separate special formatting
I want this topic to have separate special formatting
I want this post to have separate special formatting
Some combination of the above, eg, this category can utilize special formatting in some of its topics and/or posts, or this topic can utilize special formatting in some of its posts

I’m sure I don’t know enough about Discourse/Ruby to do much of anything yet, much less doing it the RIGHT way, so maybe working on my specific use case would be a good groundbreaker for me. But historically on the projects I’ve worked on over the last 40 years, once someone has a simplified way to do something they’re less interested in a more generalized approach.

That’s not quite the one I was looking for, but I think that you’ll be better off solving your actual problem than ones that you imagine.

That one will be tough, though you could make a plugin that added a PostCustomField and added it to the serializer.

Just deciding that you’ll have categories that contain only recipes/need special formatting pretty much solves the vast majority of use cases. Enforcing a set of tags is another way that’s a bit more fussy, but also involves virtually no code to maintain.

1 Like

I appreciate your suggestions and guidance. Noobies are a pain, aren’t we? (As I said in another post in another topic, I don’t know yet what I don’t know.)

My approach to systems analysis over the years has been to try to anticipate as many things as I can when starting the wish list and then see how many of them I decide I either don’t need or don’t know how to do. That approach has worked well for me.

The one issue I came up with using tags for this is that someone might apply that tag to a topic where it doesn’t belong. Of course if I say “the formatting tag only applies when this tag is in a topic in category X” that might suffice for me.

And it has occurred to me that if the formatting tag is optional, users could create topics in that category that don’t get special formatting. I just haven’t decided if that’s a good thing or a bad thing yet.

1 Like

I think that issue applies to every possible solution. :slight_smile: